50 Shades of WAF – Exemplified at Barracuda & Sucuri
Ashar Javed (Hyundai AutoEver Europe GmbH)

This talk will present 50 (25*2) bypasses of Barracuda and Sucuri’s WAF default signatures that deal with Cross-Site Scripting (XSS). 150,000 organizations worldwide including Fortune 1000 companies are using Barracuda while around 10,000 web applications are behind Sucuri’s cloud-based WAF. The XSS bypasses we will present in this talk are also applicable to other WAFs. All bypasses were responsibly reported to the vendors and most of them were fixed. Further, we will show XSS in Barracuda’s admin interface and in their web application. Finally, we will present one unfixed bypass of Barracuda and Sucuri and will see how quickly vendors will react to fix it, given it will make thousands of sites vulnerable.

 Barracuda

150,000 organizations use Barracuda Networks technology.

Over 10 months during 2014/2015 Barracuda had 7 updates of their ruleset, none of which included XSS. 6 months after that, they released 5 updates and 1 firmware patch that included fixes for XSS issues. Updating is hard, meaning there are a lot of WAFs out there that are letting XSS attacks through.

How to detect Barracuda… if you see this message, then you’re looking at Barracuda:

The specified URL cannot be found

After testing the regular expressions used to detect XSS, their was a number of XSS discovered.

Event Handlers

4 separate regexes handling event handlers.

Large number of event handlers missing, and the ones in the regex are hard-coded (for logging and tracking purposes).

• ontoggle
• onsearch
• onlaungaugechange
• oncuechange
• ondragexit
• …

Moving to a more generic event handler detection e.g. on(.*) would catch these.

However, even if the event handler was detected it was bypassable. However the logic didn’t allow for backtick (`) which is supported in some browsers. It was also possible to bypass by injecting a newline between the equals and quotes (onclick=%0A”stuff”). This was due to the use of “.” in the regex, which matches anything except a newline.

meta tags where also treated differently, resulting in a number of ways of bypassing the filters. The same issues existed in a number of html tags.

Some other issues that cause bypasses:

• Tags < 10 chars
• Tags alphanumeric
• Tags are closed properly
• Data URI JS injection (resulted in multiple issues)
• expression

All these Regexes work together to detect issues. However these are not always turned on. They need to activated, and whitelisting specific checks may have a knock-on effect in other areas where mutliple regexes are needed for detection.

Constant tweaks to the payload and complexity of the regexes results in false positives. The knock-on effect of this is disabling of protections, which lowers overall the level of security.

Some of the bypasses effected the BarracudaNetworks.com login page and stored XSS in their main admin interface.

Takeaway: Updated to 1.102 version and apply the firmware patch 8.0.1

Sucuri

Cloud-based WAF… priced cheaper than a takeaway pizza.

Sucuri offers a bug bounty (through HackerOne) on bypasses.

A large number of bypasses using encoding, backticks, unclosed tags, VBscript…

Blocked all onmouse*, onkey*, and many many more. Blacklists are a zero sum game.

Blocking of script tags appeared work well, however <script%2fsrc was a workable bypass technique. There’s always new bypasses, and almost an endless way to bypass the protections given enough time.

Conclusion

WAFs are not the only protection layer. It can be an extra layer, but not the only defense.

Links:

• Presentation Abstract
• Ashar Javed Twitter

File Format Fuzzing in Android – Giving a Stagefright to the Android Installer
Alexandru Blanda (Intel Corporation)

 The presentation focuses on revealing a fuzzing approach that can be used to uncover different types of vulnerabilities inside multiple core system components of the Android OS. The session will be targeted on exposing the general idea behind this approach and how it applies to several real-life targets from the Android OS, with examples of actual discovered vulnerabilities. These vulnerabilities affect critical components of the Android OS and the audience will have the opportunity to learn about the way they were discovered and possible exploit scenarios. The most important targets that will be included in the talk: the Android APK installer and the Stagefright media framework.

An approach that can be used for file-format fuzzing on Android

File Format Fuzzing

First steps in file format fuzzing:

• Data Generation
• Log process (Execute Tests)
• Triage mechanism
• Analyze and Debug crashes

If the fuzzing is successful, triage and categorization of the issues is an important step to avoid being overwhelmed by responses.

Data Generation

Mutational vs. generational Fuzzing

Maintain the structural validity of the file being processed. The target needs to accept that the file is valid otherwise it won’t run.

Tools use for test-case generation:

• Basic Fuzzing Framework (BFF)
• FuzzBox
• Radamsa
• American Fuzzy Lop (AFL)

Log Process

To find out what’s happening with the test-cases we send to the Android device, we need to check the logs. This can be read out using the logcat on the device. This can be done by looking for Fatal messages and seeding the logcat before and after the run to identify the test case details and information required to reproduce.

adb shell logcat -v time *:F

Triage Mechanism

Each time a crash occurs a tombstone file is created under /data/tombstones and /data/system/dropbox. This data is important to have for triaging the issues and tracking the various crashes.

By looking at the value where the crash occurs you can collect a unique list of crashes without duplicates.

1. Parse logcat for input that causes crashes
2. Execute input to cause the crash again
3. Grab the Tombstone data to check against existing know issues

Analyze and Debug Crashes

After triage maybe you have 2 or 3 interesting crashes to investigate. Using the Tombstone data can give a good indication of the severity and location of where the crash occurs. Dmesg also gives a good source of information.

Using gdbserver you can debug crashes on the device. gdb can then be used to start a remote debugging session (make sure you set the Android debugging symbols).

addr2line can be useful in getting the information on where the call took place (example: where libstagefright called libc.so)

Fuzzing the Stagefright Media Framework

Media files are interesting attack vectors as the contain complex data and result in a large attack surface (audio, video, images, etc…). Media files are also seen as innocuous to users, and can be played through various sources without the users consent (MMS etc..).

Easiest way to test was the build the stagefright CLI tool (frameworks/av/cmds/stagefright) and calling it from the Android command line for testing.

Initially started fuzzing in early 2014… thousands of crashes (needed a triage mechanism to cope). First severe issues reported to Google in September 2014.

Fuzzing the Android application installer

The application installer is an attractive target (runs with high system privileges). If an attacker can exploit this, the impact will be high. The installer also allows for unprivileged users to send input to system components.

The process of application installation differs between ART and Dalvik (Lollipop and KitKat respectively).

Extract the APK, fuzz the components to be tested, repack

ART is easier as alterations can be made without extraction.

Modifications to the APK will result in an application signature mismatch. This means that the APK will need to be re-signed before testing.

Fuzzing with AFL in Android

Android port of the tool developed by Adrian Denkiewicz of Intel

Using alongside MFFA to discover issues. In some cases, AFL reported crashes that could not be confirmed when running the test case singularly.

This method of testing showed some results that were not seen in other tests (1 high RCE issue, and several low severity issues).

Links:

• Presentation Abstract
• Presentation Paper
• Alexandru Blanda Twitter

How to Break XML Encryption – Automatically
Juraj Somorovsky (Ruhr University Bochum)

In recent years, XML Encryption became a target of several new attacks. These attacks belong to the family of adaptive chosen-ciphertext attacks, and allow an adversary to decrypt symmetric and asymmetric XML ciphertexts, without knowing the secret keys. In order toprotect XML Encryption implementations, the World Wide Web Consortium (W3C) published an updated version of the standard.

Unfortunately, most of the current XML Encryption implementations do not support the newest standard and offer different XML Security configurations to protect confidentiality of the exchanged messages. Resulting from the attack and specification complexity, evaluation of the security configuration correctness becomes tedious and error prone.
In this talk, we will first give an overview on Web Service specific attacks. Afterwards, we present attacks on XML Encryption and how to evaluate security of XML Encryption interfaces automatically. Our algorithm can detect a vulnerability and exploit it to retrieve a plaintext from an encrypted message. To assess practicability of our approach, we implemented an open source attack plugin for Web Service attacking tool called WS-Attacker. With the plugin, we discovered new security problems in four out of five analyzed Web Service implementations, including IBM Datapower or Apache CXF.

What is a WebService and XML Security

SOAP WebService are a standard that allows you to execute a function on the server and receive a response (remote procedure calls). This range from simple to very complex requests.

There are many ways to secure this communication. SSL/TLS can be used to secure the tunnel between the client and server (transport communication). The broker however (the server in this case) can see the data. To stops this from happening, you need to encrypt the data within the SOAP request using something like XML Security.

XML Security consists of 2 standards (XML Signature and XML Encryption). This can be used to protect to the entire document, or sections individually.

XML Signature Wrapping

One of the problems of XML Security is XML Signature wrapping. As the XML signature should protect against alteration to the document, by allowing validation of specific elements.

An attacker can however relocate the signed element, maintaining the valid signature. Then an attacker can add additional data to the request that are understood by the application layer. As the verification and application logic are separate, the verification will pass due to the presence of a valid signature. The application will then accept the attackers data as validated when it hasn’t been confirmed at the validation layer.

This problem was seen in 2011 in Amazon Web Services by bypassing signed SOAP requests. This resulted in the ability for an active attacker to alter the SOAP data and start instances without permission.

Further attacks against SAML were performed, where <10 out of 22 systems tested were vulnerable to signature wrapping attacks.

Attacks on XML encryption

In most cases XML Encryption uses a hybrid encryption scheme (Asymmetric and symmetric keys). Published attacks (2011/2012) exist for both portions of the encryption (adapted chosen-ciphertext attacks) using the server as an oracle.

XML is a text-based data format. Therefore it must be parsed to be understood (usually ASCII encoded). Certain ASCII characters are not parseable or can be excluded. This reduces the understood character set and makes the attack easier.

Validity oracle

1. Content Decryption
2. XML parsing
3. XML Evaluation

Be using this oracle and checking the error type returned, it’s possible to see if the failure occurs at the decryption of parsing phase.

This attack is made possible as an attacker can flip bits in the request. Cipher Block Chaining Mode has been discussed previously in several padding oracle attacks.

Performance (against Symmetric encryption): 14 queries / pain-text byte

How to analyze WebServices Automatically

WS-Attacker tool – https://github.com/RUB-NDS/WS-Attacker

Automated tool to validate attacks against WebServices, implementing XML Signature wrapping and sending requests to the oracle to validate if the system is vulnerable.

If the oracle can be identified, the attack is performed.

Examples of vulnerable systems discovered in testing:

• Apache Axis2
• Apache CXF
• Axway Gateway
• IBM DataPower
• Microsoft WCF

Countermeasures that were in place for Apache CXF were found to be incorrectly implemented, resulting it being vulnerable to attack.

Conclusion

XML is very complicated, so application of XML Encryption should be validated using tools like WS-Attacker to ensure that it’s not vulnerable.

This attack is also applies to other scenarios like SAML, JSON, Web Crypto

Prefer authentication encryption (AES-GCM instead of AES-CBC)

Links:

• Presentation Abstract
• Juraj Somorovsky Twitter
• WS-Attacker – Github – Blogpost
• How to Break XML Encryption – Automatically Paper

Hacking Cookies in Modern Web Applications and Browsers
Dawid Czagan (Silesia Security Lab)

Since cookies store sensitive data (session ID, CSRF token, etc.) they are interesting from an attacker’s point of view. As it turns out, quite many web applications (including sensitive ones like bitcoin platforms) have cookie related vulnerabilities, that lead, for example, to user impersonation, remote cookie tampering, XSS and more.

Developers tend to forget that multi-factor authentication does not help if cookies are insecurely processed. Security evaluators underestimate cookie related problems. Moreover, there are problems with the secure processing of cookies in modern browsers. And browser dependent exploitation can be used to launch more powerful attacks.

That’s why secure cookie processing (from the perspective of web application and browser) is a subject worth discussing. The following topics will be presented:

– cookie related vulnerabilities in web applications
– insecure processing of secure flag in modern browsers
– bypassing HttpOnly flag in Safari
– problems with Domain attribute in Internet Explorer
– cookie tampering in Safari
– underestimated XSS via cookie
– HTTP Strict Transport Security (HSTS)
– importance of regeneration
– and more

Why are we interested in Cookies…

Even when an application enforced 2 Factor Authentication, an attacker can gain access by getting the cookies. Security is always measured at the least protected part. If Cookies aren’t correctly protected, then even a 2FA system can be bypassed.

Many testers underestimate the security issues caused by mis-configured Cookie protections. Exploitation of Cookie related issues is not limited to local attacks.

Browsers also have issues dealing with secure Cookie processing. These kind of issues can be combined with application issues to make attacks on cookies more impactful.

What are the consequences of insecure Cookie processing?

• SQL injection
• XSS
• User impersonation
• …

Web Application

Secure flag and HSTS

Setting “Secure” on Cookies protects the confidentiality of the cookies by making sure that they are only send over secure connections.

RFC6265 prevents this cookie being sent over unencrypted HTTP, however it specifically allows an attacker to overwrite a cookie in the browser. This allows an attacker to inject a cookie (new or overwriting an existing cookie) that will be used in the HTTPS protected sessions.

HSTS to the rescue… even if a Cookie is not marked as “Secure” an HSTS header will tell the browser to only communicate over HTTPS. Therefore it’s not required to set “Secure” right… wrong!

Although HSTS works fine, as long as it’s supported by all major browsers. This is not the case with HSTS, as Internet Explorer 10 doesn’t support it.

Setting both “Secure” and HSTS is the safest mechanism here… to ensure maximum security.

Importance of regeneration

If session IDs are regenerated after a session change (logon, logout, etc…) then this may allow an attacker access (session fixation).

An attacker who can learn the value of the Cookie prior to the user authenticating, can re-use this knowledge once the Cookie is authenticated.

All Cookies with sensitive data or used within the application should be regenerated on a state change (include CSRF tokens etc…)

Server-side invalidation

Just because the session cookie is deleted by the users browser, doesn’t mean that it’s invalidated on the server. This can lead to issues where the session remains open, however the server still has a valid session.

HttpOnly Flag

Assigning this flag prevents a non-HTTP API (e.g JavaScript) from reading out the session Cookie… the theory being, that it can be used to protect against XSS attacks stealing the session Cookies.

Problems here are that RFC6265 talks about “reading” the cookie. However non-HTTP API can still write or overwrite depending on how the RFC is understood and implemented.

Specific browsers (e.g. Safari 9) will allow you to overwrite the cookie. This means that an XSS vulnerability can overwrite the Cookie and switch the user into an attacker controlled account. If the user can then be prompted to enter private data into this session, it is exposed to the attacker.

Combining this with the previously seen session fixation issue (Cookie value not changed after state change). This would allow an attacker to set a known Cookie and use it to gain access to a user’s session once they authenticate.

Domain Attribute

RFC6265 says – When a domain attribute is not specified, then it should only be sent to the domain where it originated.

However Internet Explorer 11 sends this Cookie to all subdomains of this domain.

This can be a real issue where a cookie is set on example.com where a sensitive application lives under example.com/wallet. The cookie is set without the domain attribute, according to the RFC. In Internet Explorer 11 this means that the user will also send this Cookie to sub-domains that are less sensitive, meaning an XSS in test.example.com can read out the Cookie value.

This kind of leakage can happen to externally hosted domains. As the rules only take effect on the Domain name, the fact that the site is hosted externally is incidental, however may expose sensitive data to a 3rd party vendor.

Cookie Tampering

Safari 9 allows comma-separated lists of Cookies (taken from the obsoleted RFC2109)

Example:

/index.php?lang=de,%20PHPSESSID=abc

As this is taken from the request and put into the Set-Cookie header, it allows an attacker fully remotely to tamper with the Cookie jar of the user. This allows changing the users account, as discussed previously.

It’s also possible to perform XSS via Cookie without locally setting a Cookie.

Underestimated XS via Cookie

Commonly this issue has a low assigned risk as the Cookie value has to be set locally. However if you can gain access to a low sensitive website on a subdomain like x.example.com, you can set a Cookie for y.example.com in order to exploit the user without local access to the browser.

Response splitting also allows exploitation of this issue, by allowing an attacker to set a Cookie by injecting a Set-Cookie header to place the XSS into the browser’s Cookie Jar.

Conclusions

• Educate development teams about the risks of Cookies
• Discuss/improve RFC 6265
• Cooperate with Browser vendors

Links:

• Presentation Abstract
• Dawid Czagan Twitter
• RFC 6265

Can societies manage the SIGINT monster?
Duncan Campbell (IPTV Ltd)

Behind closed doors, ubiquitous surveillance systems have evolved in parallel to and hidden within the global communications infrastructure. Developments in signals intelligence (Sigint) technology and tradecraft have shadowed all new telecommunications developments. Sigint agencies have covertly sought to lead, change, and subvert arrangements that IT practitioners make for security and privacy.

Everybody with an open data connection is being monitored and recorded at all time.

We can do privacy and security. The fallacy that we can’t have both needs to be disproven.

Even though there’s no wall of sheep here, there is an embassy only meters from the hotel were this conference takes place. On the rooftop of the British embassy there is massive surveillance and recording equipment. Phased arrays trying to scan and record anything within range.

This kind of system was exposed in the Snowden document leaks, and boasts a range of collection types (WiFi, CDMA, GSM, Satellite, WiMAX, Microwave, …).

To the other side of the Danube, sitting atop the United Nations tower is an almost identical tower (part of a project called STATEROOM). These are covert special collection sites.

Other collection points exist at the US embassy in Vienna… and are listed in the Snowden leaks.

Outside of Vienna, there are obviously other monitoring stations, including the famous event in Athens were GSM networks were monitored resulting in the death of a telecom employee.

Austria has a history of being central to monitoring within europe dating back many years. These capabilities have only expanded under the RAMPART program, accessing international communications from around the world. These 3rd party relationships are key to the US monitoring plans.

Access to communications data and monitoring is traded for access to advanced techniques and technologies.

Austria is only one part of the process… with data flowing through Germany and back to Washington for further analysis.

Without knowing the language used to describe things, the Snowden documents (and others) are hard to decipher. The word hacking isn’t used, instead being replaced with words such as “touch” and “implant” to describe malware.

A brief history of sessionizers

• 1998 First optical fibre rate sessionizers
• 2000 Grandmaster
• 2002 WEALTHCLUSTER (known publicly as DPI)
• 2006 TURMOIL (also known as TULLURIAN)
• 2010 Increased to 10 Gbps
• 2013 100 Gbps (post Snowden information)

This data is all then fed into projects like XKeystore… however this is a broken system as the recent attacks in Paris show.

Extraordinary mis-purposing of systems designed for one use, but resulting in the large-scale collection of data from civilians.

Massive amounts of information, incompetent tools, coupled with wide reaching monitoring.

XKeystore runs on MySQL, relies on Crontab, and uses CADENCE, an ancient and inefficiently designed system (scaled up from the days of telegraphy).

Little intelligence value…

You give them big data, and they screw up badly”

Anything that they can’t get is their biggest target. Access to mobile communications, leading to attacks on Belgacom to get insight into their network and communications.

Even with all that access however, they still don’t do their job. Stealing data, but not stopping the attacks that they are meant to detect by invading this privacy.

Recent Wikeleaks data shows that US monitoring stations in the EU are targeting politicians and business talks… and not attempting to try and find the bad guys.

Going for data at scale, exposes their overreach and inability to gain meaningful insight from the data.

Privacy and Security do not trade-off against each other… it’s not a zero sum game!

Links:

• Presentation Abstract
• Presentation Blogpost
• Duncan Campbell Bio

Chris sits down with Mika and René from the DeepSec conference to talk a little bit about what the upcoming conference and how embedded dependencies are causing such headaches in security.

Enjoy

[Download MP3]

A While ago the crew decided that we weren’t having enough time to record and edit the way we wanted to… as you can see, the number of episodes in 2014 was down on the previous years, because of lack of time and so many other projects. So, something had to give. We hope you’ve had a fun journey with us over the years, and it’s been a pleasure to do.

So, thank you Ben, Craig, Dale, Wim… thank you to the guests over the years for putting up with our silly questions… and most of all, thank YOU the listeners for making us want to do this thing again and again until our hands bled from the editing, and our families were starving on the streets*

So, this Christmas time, don’t cry for us! Light a candle (or a cigarette), and raise a glass (or a bottle of vodka) to the Eurotrash Security Podcast… gone but not forgotten! Episode 50: The Final One… evar

“Doesn’t Ben look hawt in his new work outfit!”

Note: Past episodes will remain available on http://eurotrashsecurity.eu until such time as  Craig gets so drunk that he forgets to renew the domain… or he pawns it to buy cheap aftershave! So probably a few months at least

* Not actually starving

Back in 2008 (when I was still young and almost had hair) I joined a small team (actually it was just 1 person if I remember rightly) at an Austrian company called Raiffeisen Informatik (I think that’s the first time I’ve written that on the blog… for obvious reasons). It was my first job since moving to Austria, and despite my lack of German skills (I could just about say “hello” and “goodbye” at the time) they took the chance on me. I’d like to think it paid off… but who am I to say.

It’s been more than 6 years since that day, and the team at what became R-IT CERT has expanded from it’s early days considerably. As the title suggests, today was my last day at R-IT CERT… and it’s a bitter sweat ending. I’ve enjoyed my time working with the great members of the team, and had a lot of great challenges. Working at R-IT CERT has given me a lot of freedom to do interesting and unique projects… but I’m really looking forward to the new challenges that are ahead of me. More details on that as and when!

Advanced Powershell Threat: Lethal Client Side Attacks using Powershell – Nikhil Mittal

APT – A buzzword which refuses to die. Lets have some fun with it, lets move it to powershell. This talk would focus on using powershell for Client Side Attacks.

Powershell is an ideal platform for client side attacks as it is available on all the Windows machines. We would see how easy and effective it is to use powershell for various client side attacks like drive-by-downloads, malicious attachments, Java applets, Human Interface Devices etc.

The payloads which would be used with these attacks include in-memory code execeution, dump passwords and system secretsin plain text, backdoors, keyloggers, moving to other systems, reverse shells etc.

The code used in the above talk will be released as open source. The talk would be full of live demonsrations.

Client-side Attacks

Why Client-side attacks

• Server-side is being locked down, so attacks are moving more to the client-side
• Often client-side is less secured and not prioritized for patching compared to the server-side systems
• The perimeter-ized network is still the norm
• Less chance of being discovered when the attack begins from the inside of the network
• Users are too familiar with their systems, and tend to feel over-confident about their security

To avoid detection it’s best to not use exploitation or memory corruption attacks to avoid being detected by possible host-based IDS/IPS or Anti-virus.

What is Powershell / Why Powershell

Tasked-based command line shell and scripting language designed for system administrators

Powershell is already present on the majority of your target systems and is a powerful method to reside in the system. It also provides easy access to things such as the .Net classes, WMI, Windows API, WinRM, Registry, etc…

Anything we can do to reduce our dependance on Metasploit and possibly detectable tools is a good thing.

Tools to create malicious client-side files

Out-Word.ps1

Used to create “armed” or “infected” MS Word documents

Out-Excel.ps1

Same as Out-Word, but for Excel files.

Out-HTA.ps1

Creates an executable HTML application to send to the user that triggers Powershell

Out-Java.ps1

Creates an executable JAR file to launch Powershell

Out-Shortcut.ps1

Creates a malicious .lnk file that points to the Powershell on the users machine to trigger specific actions. Can also set a hotkey on the shortcut so the link is triggered whenever the user clicks a specific key combination.

Out-CHM.ps1

Creates compiled HTML Help Files to execute Powershell commands. Can be customized to include real help information to fool a user.

Defense

• Don’t click stuff! Teach your users to not trust content from external sources
• Removal of VBA from MS Office would help specific attacks
• Active monitoring of users machines may help detect such attacks
• Remove powershell access to users who don’t need it (block/limit the user)

Links:

• Presentation Abstract
• Presentation blogpost
• Nikhil Mittal Twitter
• Nikhil Mittal Homepage
• Nishang tool (github)