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
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?
- 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).
- Fragmentation! Both fragmentable and unfragmentable parts may contain any IPv6 extension headers, this makes the problem number one more complicated to handle.
- 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.
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
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 😉