Cатсн²² (in)sесuяitу / ChrisJohnRiley

Mastodon

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