BlackHat Europe 2014 Wrap-Up Day #2

Yesterday evening, I had a nice dinner with awesome infosec folks. We faced a massive “Deny of Sushi” attack but we survived! So, I’m just back from Amsterdam and here is my small wrap-up for the second BlackHat day.

My first choice was to attend a talk about IPv6. Antonio Atlasis, Enno Rey and Rafael Schaefer presented “Evasion of high-end IDPS devices at the IPv6 era”. They are regular speakers at BlackHat and always present interesting researches. Belgium is facing a massive trend in IPv6 usage since the major telco enabled this protocol for more and more of their residential users. Please don’t think “But I don’t use it in my environment!”. IPv6 is at your door!

They started the research by building a lab to play with IPv6 and IDPS and, guess what, they found interesting stuff. They made an introduction about IPv6 extension headers. An IPv6 datagrams looks like a train… A train is composed of wagons. IPv6 packets can have multiple extension headers. They are not vey used today but each IPv6 stack have to support them. Examples of extensions:

• Hop-by-hop options
• Routing
• Fragmentation
• Authentication

There is a recommended order. All should occur at most once. So, how a device should react if this is not the case? Interesting: RFC 7045 says: it SHOULD NOT discard packets contains unrecognised extension headers. What are the common problems that IDS are facing?

1. Too many things are variable:types, sizes, order and number of occurrences of each one. Also the fields are variable. We can define IPv6 as a function with many parameters: f(v,w,x,y,z).
2. Fragmentation! Both fragmentable and unfragmentable parts may contain any IPv6 extension headers, this makes the problem number one more complicated to handle.
3. How extension headers are chained? (using the Next Header field)

Based on these problem, you can now imagine how difficult it is for an IDPS to inspect properly IPv6 packets! What can go wrong? Chiron, an IPv6 penetration testing framework, has been used to test IPv6 extension headers.  They tested fours IPS: 2 open sources and 2 well-known commercial solutions. Each solution was tested agains 12 different evasion techniques. All of them have been reported to the vendors/developers. Some were patched quickly, for others if took longer time and, guest what, others still remain open. To demonstrate this, the speakers performed several live demos:

• on Suricata – version 2.0.1, 20.2, 2.0.3 were evaded. Simple IPv6 ping not seen. Was fixed quickly (2.0.4)
• on TippingPoint – Vendor reacted but slowly. After the first patching, they found a new way to evade it.
• on Sourcefire / Snort -the commercial version suffers of a 0-day while the free version has been fixed! Bad contacts with Cisco. The message was simply a “please contact the technical support”. So, enough played… time for disclosure…

What could be done? If you are using an IDPS…

• RFC’s should strictly define the exact legitimate usage (key point!) Developers must follow them
• Make fully-compliant IPv6 products and test them thoroughly…

Technical mitigations: Implementation of RFC 7112. Configure your devices to drop IPv6 extension headers not used in your network. Sanitize packets before they reach your devices. A very interesting, well prepared with demos working out of the box!

The next talk was chosen purely by curiosity: “Gyrophone – Recognizing speech from gyroscope signals” by Yan Michalevsky, Gabi Nakibly and Dan Boneh.

How to record speech without using the built-in microphone? All smart phones have a small device called a gyroscope. To record speech on a mobile device, the main problem for an attacher is how to access the microphone because the access must be approved by the user. But sensors can be freely accessed by apps like… the gyroscope! Why? Because it is not considered as a security or privacy threat. The gyroscope can be accessed from browsers using a simple JavaScript piece of code. They are two major vendors on the market but they both work in the same way. Gyroscopes are very sensible to acoustic noise. To resume: Our voice makes waves which generate vibration. They impact the gyroscope!

Based on this fact, gyroscopes are (lousy but still) microphones! Sample rate to the gyroscope is limited by the OS (max 200Hz). To give you an idea, a male speech is around 85-180Hz and a woman speech around 165-244Hz. Listening to a map at 200Hz is not efficient but algorithms can be used to perform a deeper analyse for us. That’s what explained the speaker during the rest of the talk. They described the lab they put in place to record enough samples and the different techniques used to:

• Make gender identification (male/female)
• Speaker identification in a conversation
• Isolate some word recognition

Depending on the samples and techniques, the results varied  but they also demonstrated how the detection rate could be improved by using multiple devices sampling at the same time. Some other attacks:

• Source separation and use different algorithms to analyse the different sources
• Ambient source recognition (in the street, in a meeting room, etc)

After a first coffee break, let’s continue with “Revisiting XSS sanitisation” by Ashar Javed. More precisely, the talk focused on WYSIWYG editors like we can find in thousands of websites such as  forums, CMS (blogs) but also more corporate applications like ticketing systems. They allow you generate nice content by inserting pictures, bold, italic texts, links etc. Froala is a very common editor using my many websites. Imagine a major vulnerability is this editor, you have a very broad surface attack! And developers of such editors are proud to claim they have thousands of customers! Another example if TinyMCE used by WordPress (that I’m using right now to write this post). What to say about XSS? As said Ashar: “They were there, they are and they will be!“

Ashar reviewed some example of XSS vulnerabilities a found in text editors. He received some money from bug bounty programs for this but he was also banned or his account disabled from some sites. Ashar explained step by step in a very didactic way how he successfully abuse so many websites which rely on third party libraries or code. He started with an XSS based on width:expression on IE7 and switched also to other browsers. What are the common injection points in WYSIWYG editors:

• Insert/Edit images
• Insert/edit URL
• Set attributes
• Insert/upload a file
• Insert/upload a video

Ashar reviewed all of them, always with good examples. He also provided some nice slides which explain how to quickly found XSS using common browsers. The presentation ended with a question: “Why all WYSIWYG editors are vulnerables?”. According to Ashar, the answer is based on two components: Transfert of responsibility and laziness. Developers think that it’s up to the site owner to take care of data received by the client and webmeisters rely on 3rd party code that should block all such kind of attacks.  Finally, some tips were given to efficiently block XSS attacks. To prove this, Ashar started a project and asked people to break into his application. As of today, 82K (!) attacks were executed against the webpage and none succeeded. A last message to developers: if XSS attacks are bad to block, don’t forget to use httpOnly cookies to prevent them of being stolen!

The last half-day started with Erik Peterson who presented “Bringing a machete to the Amazon”.

Forget all the *AAS abbreviations! From a single perspective: “Cloud like AWS is an operating system”. It has memory, disk and allows you to run applications. Cloud infrastructure is code. Traditional applications are a small part of the whole system (Java, .Net, etc) and the majority of the system is provided by AWS. And like any application, after a few months, it can become a mess if not properly managed. Forklifting is also dangerous. Forklifting is the process of taking legacy data centre application and loading them into the cloud. This can be expensive and dangerous:

• IDS and NAC are not aware of AWS API activity
• Some ignore vulnerabilities can become critical
• The meaning of availability changes

Emergent security: An individual component can be secure but once placed in the cloud, the system becomes insecure. Example: Internet weather – some datacenters can be subject to unpredictable, non-persistent or network latency issues. This is very similar to the DevOps concept. “In the cloud, the king of the jungle is the API”. API keys are the key of your security. Impact?

• Bitcoin mining (cpu)
• Alter apps and spread malwares
• Download sensitive data
• Destroy your virtual DC!

API can bypass classic security controls: You have an IPS, FW? API can snapshot your VM, mouth snapshot on another VM and extract info. How to get access to API? Via Github of course! Search for “SECRET_ACCESS_KEY“. What about an API honeypot? Your keys will be stolen in less than 60 mins! 🙂 What about cloud metadata? They contain useful info like startup script and AWS access credentials. Not only AWS but all cloud providers have it (except Azure ;-).  There is nothing wrong with metadata … as long as you are aware of them and protect them. Old vulnerabilities, new life thanks to the AWS cloud. Ex: CVE-77 (command injection). Control access to the API and restrict access based on IP but it does not solve the problem! Your bill is not an IDS : “Wow, I got a big bill, something wrong must happen” 😉 Implement API logging, by default it’s off! Turn on CloudTrail and use Logstash (as example).  DevOps culture tends to “fail open”. Developers are new to the cloud. Their goal is “just to make it work”.  Leaking taks! Tags are very nice to keep information (ex: owner of the machine, contacts, …) but please don’t put your password or API key inside tags! Back to the title of the presentation: Machete is a tool to:

• Analyse IAM users and permissions
• Record all services and objects in use
• Crack open AMI and EBS snapshots
• … more to come!

Other tools that could be interesting:

• Netflix security monkey,
• AWS trusted advisor
• NimboStratus

Very nice presentation but the introduction to AWS cloud and the associated risks was a bit long (IMHO). I’d expect some nice demos of Erik’s tool.

The next presentation was dedicated to the new OS X version. Version 10.10 called “Yosemite”. Good synchronisation, it was just released yesterday. This versions was already available to developers (and security researchers). It was reviewed, from a security point of view by Ming-chieh Pan and Sung-ting Tsai

They analysed the changes implemented by Apple in its new version of their operating system and found some findings. They started with a review of the rubilyn root-kit publicly released 2 years ago. Then they reviewed how to installed (offensive) and detect (defensive) a root-kit on the new version of OS X. A good idea was to present all the examples (system calls) with their Windows version (most people have more knowledge of the Microsoft environment). The talk was very technical and above my knowledge, very difficult to follow but, according to a friend, it was good. Finally, they presented their tool called SSV-X (“System Virginity Verifier”), especially adapted to OS X.

And the second day finished for me with “Reflected file download – A new web attack vector” by Oren Hafif. After a funny introduction about himself, Oren explained in details what is RFD and what is behind this attack. The presentation focused on the objectives of RFD, understanding how it works. Both defenders and attackers are impacted: how to detect and report but how to prevent. calc;exe:

The attack is quite straight forward: A user clicks on a valid link, a malicious file got downloaded from google.com, the file executes immediately once clicked. The key in this attack is: how do we trust downloads and how do we trust websites? As example, we trust online banks websites because that have a lot of locks on the page, they use HTTPS, the url bar is green, etc… Four out of five people will trust a download based on the domain! Based on the Google autocomplete feature, Oren explained step by step how this attack works. Starting from a simple ‘rfd‘ search string up to a ‘s;.setup.bat/?q=rfd”||calc||‘. This attack also abuse of stupid browsers behaviour which allows files containing “install”, “setup” or “update” in the filename! An advanced attack could be to use Powershell to download the rest of the payload. It will ask for admin rights but using the standard dialog box that people trust of course! Finally, Oren reviewed some ways to fix this issue:

• Use exact URL mapping – no wildcards!
• Do not escape! Encode! \u0022 or \x22
• Add a Content-disposition field with a filename attribute (ex: Content-Disposition: attachment; filename=foo.txt)
• Remove support from Path Parameters

In the mean time, Google fixed the issue but, according to Oren, there are tons of vulnerable websites online! Very nice presentation which, I’m sure, gave lot of ideas to the pentesters present in the room!

Next to the classic briefings, there was also an Arsenal session organized by Netpeas and Toolswatch with very interesting tools. Don’t hesitate to have a look at them:

• NAFT – To perform Cisco forensics investigations
• Lynis – To scan UNIX systems for malicious code
• PEstudio – To analyze (malicious) Windows executables
• ZAP – The intercepting web proxy from OWASP

That’s it for this edition of BlackHat! I only attached 25% of the scheduled talks and, in my selection, some were excellent, other less but a broad scope was covered. Two remarks about the organization: change your WiFi and catering providers 😉