Symposium sur la sécurité des technologies de l'information et des communications is a 2 day con about security. Entrance is 260€ or 60€ if you're a student, still quite expensive, there seems to be a way of getting a free pass: analyzing a usb trace and extracting a mail from it.
Here's the trace.
here's a usb trace I got from plugging my brand new android to my personnal air-gapped computer.
I'm suspecting that a malware is on my phone. Could you check?
So where do I start...
The Lundum Dare is starting in a bit less than 10 hours.
Ludum Dare is an Online Game Jam event where people from around the world create a game in a weekend.
You have 48 hours to produce something good! In what language? I used to watch notch do it in java, but apparently you can do it in whatever language you like.
To reach more participants, web entries are best (Flash, Unity, Flixel, Flashpunk, HTML, etc). They’re quick to start playing, and cross platform.
I need to get into Unity a lot more to get into that kind of contest. Every year I'm telling myself "next year I'll do the lundum dare"....
posted April 2014
So, the team behind OpenBSD has forked OpenSSL to create LibreSSL. They're rewriting code, they already found several bugs.
You can check what they do with some awesome journalism here.
I remember a time where people would advise to just hash the password with md5 before storing it into a database.
Then md5 became a bad choice because of the rainbow tables (precomputed tables of md5). The concept of salt helped (adding a secret value to passwords before hashing them).
But hash were never meant for encrypting passwords. As KDF. But KDF seems to be better a fit for that kind of task.
See Ty's blog post "please stop hashing passwords". He makes good points and advise using those following KDFs for the job:
Scrypt is the one used in Litecoin by the way.
A few hours after the start of the Heartbleed challenge, actually, just 3 hours after the start of the Heartbleed challenge. Fedor Indutny seems to have cracked it.
So now, chaos begins. If you own a certificate, you not only have to change it, but you also have to revoke it. I wonder how many will change, and how many will revoke.
You can check that he indeed did it by doing this:
Just to confirm it: put this into your /etc/hosts “184.108.40.206 http://www.cloudflarechallenge.com ” and visit “https://www.cloudflarechallenge.com/ “.
here why it works:
Putting that mapping in /etc/hosts lets your machine skip DNS lookup for that hostname, and just use his IP for that domain name.
Then, your browser checks the received certificate against the authenticated TLS connection, and sees that all is well, allowing you to connect without a warning.
Since the browser does not warn of a certificate mismatch, he must have a valid certificate for 'cloudflarechallenge.com'. QED.
The Cloudflare team reviewing the attack:
NSA is not happy. NSA is tweeting, tumblring (is this a verb?) and shouting loud and for all of who wants to hear it : they didn't know about the Heartbleed bug.
by the way they're talking about a "zero day" vulnerability, and now is a good time to learn what it is:
a so-called “Zero day” vulnerability because the developers of the vulnerable software have had zero days to fix it
I'm akin to trust them since... well. So many US websites were using OpenSSL and... it's not really nice if someone else eavesdrop on american citizen...
Anyway, this shows that the NSA has a long way to build trust again.
Cloudflare's engineers have set up a server vulnerable to Heartbleed, if you find the secret SSL keys and publish your solution you'll get 10,000$. The challenge is here and there's a blog post here.
an attacker can get up to 64kB of the server’s working memory. This is the result of a classic implementation bug known as a Buffer over-read
Apparently it is not known if it is possible or not to find those keys. If it appears to be possible the results would be catastrophic as every single website that has used OpenSSL would have to revoke and ask for a new certificate. And as Cloudflare says:
the certificate revocation process is far from perfect and was never built for revocation at mass scale.
So it would then be very easy for any server to pretend they're someone else.
A heartbeat is a message that is sent to the server just so the server can send it back. This lets a client know that the server is still connected and listening. The heartbleed bug was a mistake in the implementation of the response to a heartbeat message.
This is the code in question:
p = &s->s3->rrec.data
hbtype = *p++;
pl = p;
buffer = OPENSSL_malloc(1 + 2 + payload + padding);
bp = buffer;
memcpy(bp, pl, payload);
The team at Detectify found a way to access files on one of google's production server. Thanks to an old google product (google toolbar) that was using a poorly secured XML parser.
They just used a simple XXE attack where they uploaded a poisoned xml files and saw what the application printed back
a xxe looks like this:
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///etc/passwd" >]><foo>&xxe;</foo>
More on their blog