Home » Press Releases » Top 10 Application Vulnerabilities of 2019

Top 10 Application Vulnerabilities of 2019

by Deb Schalm on March 31, 2020

In application security, so often the cause of vulnerabilities can be traced to the development process. It’s the nature of application development and a consequence of moving faster with shorter deadlines. It’s no wonder it translates to coding errors in code deployments. This is why it’s important to use application security tools and patch vulnerabilities as soon as they are found.

Ensuring that software teams build their applications securely is one way to prevent code vulnerabilities and ultimately, data leaks. Not only do these mistakes damage a brand’s reputation, but they also hurt the privacy of users. As long as applications continue to be the linchpins that drive revenue and success for businesses, they will remain a top target for digital adversaries. The proof is in the headlines.

However, there are valuable lessons we can take from some of the events of the past year. For example, one is that all personal information should be treated with the highest levels of concern. In a perfect world, there would not be any circumstance where private information storage is exposed publicly, because there really is no margin for error – once a leak of this information happens, there is no way to ‘put the genie back in the bottle.’

As we do each year, the WhiteHat Threat Research Center looked at the top vulnerabilities of 2019 – those caused by application-based attacks, coding bugs and errors – and then, we explored the steps organizations can take to protect applications and code in 2020.

Here are some of the highpoints we want to share with you, our customers and partners:

Sponsorships Available

Google Search XSS ^[1]

Being the most popular search in the world makes you a target…which is why nearly every security researcher dreams of finding a vulnerability on Google.

This case highlights years of knowledge and persistence, and more importantly, collaboration to find a vulnerability that was at least partially well-known and executed. We chose this for its cleverness, and also to highlight the importance of performing continuous testing on items that people may feel are already secure. There is always another way, and the best way to protect yourself and your assets is to continuously test.

Cross-site Leaks ^[2]

This is another attack that is not new but gaining momentum with HTTP caching being attacked from all fronts. While there are decent preventions against this attack, most of the internet is still prone to it.
Here, we see the importance of revisiting old techniques with new ideas. Because cross-site leaks are used in various ways, make sure to always check for old attacks when deploying new code.

Web Caching en Masse ^[3]

This attack debuted in 2017. The ease of use was staggering, and it appeared again in 2019 thanks to this white paper by Sajjad Arshad. Two years later, this vuln is still in the wild. WCD is really difficult to deal with. The study found that just having cache headers is not a solid indicator of whether or not something was cached. Again, this highlights the need to re-examine techniques to combat attacks.

Null Byte Buffer Overflow ^[4]

This attack shows the importance of continuous testing as an application matures and grows. Researcher Sam Curry was able to get RSA private keys, internal HTTP requests, the DOMs of users, plaintext usernames and passwords and much, much more.

Edge (Chromium) -> RCE ^[5]

This attack opened the door to trick a user into accessing local files, editing top sites in the NTP, updating NTP preferences, tracking user activity, etc. It was a real top-notch bug that kept developers quite busy.
This is another example of a top-layer component being too accessible to users, and creative minds will always find a way through. Having persistent testing across an app can help do a lot of the heavy lifting.

Padding Oracles with Fixed IVs ^[6]

In an outstanding display of patience and creativity, Teddy Katz walks you through how Static IVs (Initialization Vectors), padding oracles, concatenation and moving random junk can lead to escalated privileges. This was a great example in stringing together several attacks to get to the ultimate goal. Most of which are well known and documented.

DOM Clobbering Gmail ^[7]

Using a well-known technique known as “DOM Clobbering,” researcher Michał Bentkowski, shows how to perform XSS in AMP4Email (a feature in Gmail that makes it possible for emails to include dynamic HTML content).
At Whitehat, we still find plenty of websites that do not include CSP headers. CSP is a small step towards building a secure environment that can net powerful returns.

Cache Poisoned Denial of Service ^[8]

Here, cache poisoning made its presence felt again, this time in the denial of service (DoS) fashion. Researchers found three ways to target content delivery networks with cache poisoning that lead to distributed denial of service (DDoS).

HTTP Header Oversize (HHO)
HTTP Meta Character (HMC)
HTTP Method Override (HMO)

The attack was fairly grand scale and merited responses from Akamai, Microsoft and Amazon Web Services, to name a few.
Ensuring that caching is secure can be difficult for companies. Not using the correct error codes seemed to help the researchers a lot. Cache-control: no store header could have also helped.

In other words, you must be hacking yourself first to ensure the smallest measures are taken into consideration.
Reusing Cookies ^[9]

This vuln illustrates the struggles of bringing good information to people of interest in the bug bounty world. Thankfully for WhiteHat, our researcher has great patience and resolve to persistently stick to the research and expand it every time new information is uncovered.
Here, we learned that cookies could be reused, not only on different subdomains, but from the same application. This was an intended feature at one point, but it was being removed.
Sub-domains are commonplace, and research shows that it can be tough to manage, when something as simple as cookie usage tied to a unique user/session/domain can be easily overlooked. The penalties can be great.

QR Code Scan XSS ^[10]

QR codes are used in many places. For example, Amazon Prime members can scan QR codes in Whole Foods stores to get a Prime membership discount. What happens when the wrong hands start handing them out? What security is out there for them?

In reading this research, it’s clear the frontier was open when the researcher stumbled across various types of XSS. By creating a QR code to include malicious JavaScript URL, the browser was happy to run it. The researcher was even able to bypass CSP headers with ease.
Simple testing could’ve gone a long way here, as there was no filter evasion or any encoding that was even needed. Firefox has since fixed this issue, but Opera mini for iOS has yet to respond.

Summary

These problems, seen throughout 2019, should serve as a reminder for organizations to practice reducing risk by securing DevOps to secure application delivery. In particular, security and development teams must be up to date on the latest vulnerabilities and exploits.

Of course, continuously monitoring code is the best way to find problems, and enterprises should be vigilant about anything that has changed in the threat landscape that might require new preventative measures.

Following best practices such as utilizing the ‘least privilege’ model, consistently patching applications when available, and making security part of developer processes are just a few examples of how to prevent these kinds of leaks from occurring.

References