BlackHat is back in Europe and, this year, they moved back to Amsterdam! This edition also introduced a new format: A three-days conference with three simultaneous tracks. Three trainings are organized, one per day. From my personal point of view, it does not impact me. But people attending a training could miss interesting presentations. But let’s focus on this first day…
As usual, the conference started with a keynote. A time-slot was assigned to Fortinet (diamond sponsor) who made a review of the security landscape and their products since 2000. Purely commercial, let’s skip directly to the true keynote performed by a great guest: Withfield Diffie, the well-known pioneer of public-key cryptography. He gave some big facts about information security, always linked to situations from our real life. Example, moving to big cities changed our behavior, we don’t control the environment anymore: traffic lights, public transports, we depend on them. That’s the same for computers and networks. They are not secure but we use them. Their goal is to let “friends” exchange information with “friends“. Cryptography prevent us to care about the path used by our data but it just moves the problem further: security don’t stop once the data successfully reached their destination. The security of computers is based on three facts for software development:
- Know what you are to do
- Write good code
- Recognize that writing good code is expensive (testing, hiring good developers).
But in some organizations, they don’t care about loosing data or introducing bugs, they always make revenue ($$$ is the key). Also, offensive security is more profitable than defensive one. Another security problem is the scale of “things” to protect. Example: Patches published by Microsoft can sometimes be installed months after they were released! What will be the upcoming challenges:
- Need to learn to program
- We need to fix human interfaces (to protect against the “click-mania”)
- We need to fix the rules of liability
The first talk that I followed was about “War Texting” by Don Andrew Bailey. He started his presentation with the bad story of the “Moss Landing” problem when boats loosed GPS signals due to some models of TV amplifiers which jammed the satellite signals. GPS is definitively not reliable, big differences of temperature can affect signals which are, by default, already weak. This introduced the problem with M2M communications (“Machine 2 Machine“). More and more devices have GPS chipsets and SIM cards to communicate with central servers. One of the security problems is that nobody takes care of the devices spread in wild environments. According to Don, they should be considered as regular computers (patched, logs monitored, …). He explained how easy it is to make a device loose its connectivity from a 3G network and force it to switch to 2G. 2G networks can be easily spoofed using tools like OpenBTS. Embedded devices have usually a poor level of security mainly due to the hardware limitation of their hardware. Most security features are simply disabled due to lack of CPU cycles or storage capacity. But they have TCP/IP stacks which makes them vulnerable to common attacks. And, another common issues, developers don’t care about security and trusted radio networks. In demos, Don proved that some devices sent IP addresses in SMS messages. Followed a nice demo where Don unlocked a car and started the engine remotely via the embedded system… Another research was based on Zoombak tracking devices (very popular in this US). Devices sent the following information to Don: GPS coords, phone number and own IP addresses. Fun!
Then, the best talk of this first day! Jeff Jarmoc talked about “SSL Intercepting Proxies“. Often this kind of tools are used to conduct MitM attack but sometimes that are officially installed by organizations for multiple good reasons (Interception, Filteting or inspection). Many products includes SSL proxies like DLP solutions, IDS, Next-Generation firewalls, web proxies, etc). Jeff’s research was based on those products. How do they perform their job? He started by a brief history of SSL and how it works. If you use such proxies, don’t forget that they could introduce legal problems. Users must be aware of their presence! Due to the high-value content stored on them, they could be very valuable for attackers. The biggest question is “How to handle failure modes?” (when a SSL issue is detected):
- Fail close (secure but not user-friendly)
- Friendly error (less secure)
- Pass-thru (worse case)
Each of these modes has side effects! Another attack vector is introduced by the way the “key pair caching” is handled by the proxies. The proxy has to establish two sessions: client-proxy and proxy-server. For performance reasons, a cache in used but it can be abused. Jeff reviewed some well-know commercial solutions. Cisco Iron Port is very bad at handling SSL (self signed certs are accepted, unknown root CA are accepted, lack of OSCP/CRL, basic constraints not validated and… You have to trust Cisco which trusts roots for you! But Cisco is not alone, others have also weaknesses like Astaro Security Gateway.
How to protect yourself? First, Jeff developed a small online tool which checks how your proxy handles SSL connections. The tools is available here: ssltest.offenseindepth.com. Just visit an URL from a host behind a SSL proxy. And from a proxy administrator point of view? Consider using failure mode, patch and update your products. If you are developing SSL proxies, a golden rule: give control to administrators! They must be able to manage trusts, revocation by themselve. Jeff is busy to test other solutions and will update his list. Follow him on Twitter for news.
After the lunch, I attended the workshop about the Zeus worm. The goal was to learn how to configure, install and control the worm in a safe environment. The description was really nice on the conference brochure and the room was even too small to accept all the participants. The first part was more theoretical about the Zeus worm (history, how it works, what is steal, …). Nothing very new as everything is available online for a while. I expected the practical part to be more funny. But I was disappointed. The demo was too quick, impossible to follow the actions to perform, small fonts unreadable… At least, I’ve the worm in a Windows guest now! (Note to myself: do not forget to deleted the VM snapshot)
To end the day, my second preferred choice: “Hacking XPath 2.0” by Sumit ‘Sid’ Siddharth and Tom Forbes.They started by a review of the XPath specifications. Basically it’s a query language to select nodes in a XML document. Think about “SQL for XML“. There exists two versions (1.0 & 2.0) which have been covered during the talk. After each method of injection, a small video was prepared to demonstrate how is work. Simple & efficient! What can we do with XPath injections?
- Authentication bypass
- Business logic bypass
- Extraction of arbitrary data
Like SQL injections, those attacks can be achieved due to a lack of user input validation. Blind XPath injection are also available (just return TRUE or FALSE). By using the functions present in the XPath specifications (count(), name(), string-length() or substring()), it’s possible to read data directly from a local file! It’s even possible to read comments present in a XML file (Comments often contain valuable information). Performing XPath injection is really a pain and very slow. That’s why Sid & Tom developed a free tool called XCat which will do the job for you.
After some demos, they switches to XPath 2.0 which introduces move funny functions like doc(). If allows reading XML files on the filesystem as well as remote files. More funny, doc() can be used to send data directly to an attacker webserver via GET requests (exfiltration). It can also use DNS queries. Finally, the talked about XQuery which is a superset of XPath and introduces more query languages specific stuff like loop (for, while), order by, return, etc. To conclude their presentation, they briefly introduced how to protect against those attacks: Sanitize user inputs (again and again), use parameterized queries and limit the access to the doc() function. Great talk.
That’s all for the first day, now it’s beer time!