27/09/15 - 09:34pm
This challenge was one of the 25 (minus a few canceled ones) written and organized by TrendMicro for their TMCTF 2015. I played with the Swiss team “On est pas contents” and I won’t disclose how badly we ranked Some challenges were really boring (a crossword where half the solutions come from the commercial product aisle? Not for me). Some were frustrating, and one was really great: Poison Ivy network capture.
TrendMicro was very fast in shutting down the whole CTF website, so I can’t get an hand on the original challenge text. From memory:
A hacker was caught using Poison Ivy on a real system. Please understand what he was doing to get the flag. (ps: password is admin).
With that exciting information I start downloading the pcap. Opening in wireshark, it appears it’s a single TCP connection on the 443 port. This doesn’t look like https and the wireshark dissector doesn’t want to parse it. Right click on a packet, “Decode as…” and check “do not decode” makes us see the raw exchange.
Read the rest of this entry »
23/07/14 - 11:55am
In July, a blog post from Andrew Ayer described the new, unsafe behaviour of portable LibreSSL 2.0.1. While it is right to say that it’s unsafe, it is still safer than baseline’s OpenSSL and portable LibreSSL 2.0.2. That’s what I’ll explain in this blog post.
During March 2014, I released two CVE on OpenSSL consumers, stunnel (CVE-2014-0016) and libssh (CVE-2014-0017). I also wrote a paper about it in the french magazine MISC mag 74. Unfortunately the paper is in french and not yet released in CC-BY-NC, so here are the major points:
- OpenSSL RAND_bytes() pool can be shared by two processes that are related, e.g. with a fork().
- OpenSSL mitigates that problem by adding the result of getpid() in the entropy pool during a RAND_bytes() call. That means that two processes that share the same entropy pool and end up with the same PID will generate the same pseudorandom numbers.
- That’s what happens in stunnel in fork mode: a master process initializes the entropy pool and spawns children. As children die, PID are recycled until a PID is reused and starts generating the same sequences of pseudorandom numbers.
- Hopefuly OpenSSL uses RAND_seed() with the current unix time (time(NULL)) on every SSL handshake, so there’s only a one-second time spot to exploit that weakness, before having to start from scratch again. OSes with sequential PID generation are then less vulnerable than OSes with random PID (AFAIK only OpenBSD). This is because open OpenBSD it’s likely to have two different children have the same PID reused in the same second.
- In the end, the exploit I wrote for it didn’t work, because the OpenSSL ECDSA_sign() function calls RAND_seed() with the content of the message to be signed, and the secret number k is different every time, mitigating the exploit:
Read the rest of this entry »
31/12/13 - 01:51pm
Dual_EC_DRBG backdoor: a proof of concept
What’s this ?
Dual_EC_DRBG is an pseudo-random number generator promoted by NIST in NIST SP 800-90A and created by NSA. This algorithm is problematic because it has been made mandatory by the FIPS norm (and should be implemented in every FIPS approved software) and some vendors even promoted this algorithm as first source of randomness in their applications. edit: I’ve been told it’s not the case anymore in FIPS-140-2 but the cat is already out of the bag
If you still believe Dual_EC_DRBG was not backdoored on purpose, please keep reading.
In 2007 already, Dan Shumow and Niels Ferguson from Microsoft showed that Dual_EC_DRBG algorithm could be backdoored. Twitter also uncovered recently that this algorithm was even patented in 2004 by Dan Brown (Not the Da Vinci guy, the Certicom one) as a “key escrow mechanism” (government jargon/lingo for trapdoor/backdoor).
I will go a little bit further in explaining how it works and give a proof-of-concept code, based on OpenSSL FIPS. This is in the best of my knowledge the only public proof of concept published today. (correct me if I’m wrong).
Dual_EC_DRBG in a nutshell
The PRNG works as following: it takes a seed that goes through a hashing algorithm. This data is then “fed” into two Elliptic Curve points, P and Q, before being slightly transformed and output.
In order to understand how the algorithm (and the backdoor) works, let’s see the relevant maths from Elliptic Curves: Read the rest of this entry »
04/07/13 - 02:11pm
I noticed a while ago that many security professionals advise their customers to use ‘autocomplete=off’ in the password fields of login screens. It also started to scratch an itch on me when my password manager never stored passwords for a few websites. And I started to look for opinions before forging my own.
Websites advising to disable autocomplete
A few blogs, forum posts and even stackoverflow advise to disable autocomplete on password fields. Owasp.org itself advises to prevent web browsers from caching sensitive data in the client side.
What are the advantages of disabling autocomplete
The two main advantages for the security are the following:
- Avoid caching sensitive data on client site (CC numbers)
- Avoid storing the password in an insecure and hackable client-site database
The first bullet is in my opinion completely legitimate. Some information, like credit card numbers, should not be remembered in the web forms, because there is nothing that can let the browser understand that this field is sensitive, that its content should not be stored unencrypted on the hard drive and shown in plaintext at the first occasion when the user types a few digits in a text box (and be victim of shoulder eavesdropping). However passwords are different. They have their own class of input box and browsers know how to manage them. I will come to this later.
The second advantage of that policy is that passwords won’t be remembered in the case the user’s computer has been hacked. That’s true in a few occasions, like when the user has malware on his computer or his laptop gets lost/stolen. I would respond that no software password management solution can really help when the end user computer cannot be trusted. In many case, malware can just wait for the user to type his password to steal it. To efficiently protect against malware, users should be provided a physical device to be used to authenticate and sign any sensitive operation. That’s the only working mitigation in my opinion, we use these in Belgium for e-banking and it’s working pretty well. Read the rest of this entry »