Mitre Top 25 Software Weaknesses

In addition to OWASP finally updating the Top 10 Web Application Risks, this year Mitre also updated their Top 25 Most Dangerous Software Bugs, also known as the CWE Top 25.  One of the interesting things to note about the updated list, is that common vulnerabilities still feature prominently, an indication that we’ve made little progress in improving the security of our web applications, as has been indicated by other recent studies.

Common Vulnerabilities Are Still On the List

In this blog article we’ll review some of the common security vulnerabilities that have been found in web applications for decades. Based on this latest and most recent lists, it looks like they are not leaving the Mitre list anytime soon.  They allow old but reliable attacks for a broad range of attackers worldwide, who frequently succeed in breaking into systems and organizations using them.

Cross-Site Scripting (XSS) 

Attackers can use web-based features in order to plant and insert bits of code that are malicious scripts. In the XSS case, attackers can upload these scripts into unprotected client-side web pages, to be executed when others open that page. At K2, we’ve written about XSS in the past and here’s a quote from a prior blog article:

XSS was first found in the year 2000, so we’re past the 20th anniversary of the discovery of this exploit. By the year 2007 XSS became the most common exploit of web applications. Today it’s still one of the most attacked vulnerabilities, and still ranks as one of the OWASP top 10 web application security risks.

Writing secure code against XSS attacks involves prohibiting web applications from downloading files, and many developers neglect to add this restriction. Many development teams continue to let attackers download scripts onto third-party web sites, and most testers have a difficult time identifying this type of attack, because it’s not clear where the malicious scripts are coming from. The result is that those users innocently visiting those web pages may inadvertently and unknowingly download malware onto their systems.

Buffer/Memory Overruns

Manipulating memory remains one of the most popular ways of attacking a vulnerable system. If an attacker has possession of a specific memory address within an executable application, s/he can use it to enter values or commands that exceed the size of that memory space. Once outside of the memory space, attackers can insert executable software, making it possible to take over a computer or elevate permission levels.

Many methods exist to take advantage of buffer and memory overruns for attacks. If a software developer hasn’t limited variable lengths, an overrun can allow an attacker to write malicious code directly into application memory. At the very least, it’s possible to use this technique to interfere with application execution, causing it to crash or return incorrect results.

SQL/Command Injection

SQL and command injection are another subset of vulnerabilities that have been around forever, and one that developers continue to have a tough time combatting.  Most developers focus on making sure their application returns the desired result above all else. In some applications, one common and easy way of doing this is to give all user queries administrative access to the database. While that often works, it has serious consequences for application security.

We’ve also written about SQL Injection in prior blog posts:

Like XSS, SQL Injection has been on the OWASP Top 10 list of web application risks since the initial publication of the list in 2003.  The most recent incarnation of the OWASP Top 10 has SQL Injection included in a broader category labeled,  “Injection” and is number one on the Top 10 list of risks. For a threat that’s been around since the inception of the OWASP Top 10 list, it should be troubling that 26 percent of all small businesses have suffered from a SQL Injection attack in the last year.  And according to a recent article it remains one of the least-talked about threats to organizations.

The first problem with using administrative access is that it opens up database access to any application user. The result is that anyone who uses the application can use SQL commands to modify the database. Using SQL escape characters, attackers can enter SQL commands into the web interface and have them executed by the database.

Another problem, is that it typically keeps the database connection open for all. It’s never logged out after each individual use. That means that you don’t have to be an authorized user to find an open database. That makes the integrity of your data questionable on an ongoing basis.

Other Cyberattacks Fill the Plate

The Mitre list contains other common attacks, including missing or improper authentication, incorrect permissions and unprotected credentials. However, the most popular attacks still remain those that have been around almost since the dawn of the public internet. Until development and testing teams are able to internalize some of the most significant vulnerabilities over the last two decades and develop strategies to reliably counter them, they rely instead on security measures like web application firewalls to protect against attacks on software vulnerabilities.  Unfortunately as we’ve discussed in other blog articles, in recent years, WAFs are failing to protect applications.

RASP and IAST added to Security Framework

The continued prevalence of serious application vulnerabilities and the failure of typical security tools like WAFs to protect applications is one of the reasons that NIST has updated their Security and Privacy Framework outlined in NIST SP800-53.

The big change for application security in Revision 5 of the security and privacy framework was the addition of RASP (Runtime Application Self-Protection) and IAST (Interactive Application Security Testing). It was a first in recognizing these two advancements in application security by now requiring them as part of the NIST security framework.

While it’s been a year since the standard has been finalized it’s probably too soon to be able to say the new requirements are a success.  We do know that in the last year breaches and attacks have increased. The increase in attacks and breaches should convince any organization that it’s time to re-evaluate their security and the NIST framework offers a template for organizations to adopt the same level of security used by federal agencies.

---

 

Here at K2 Cyber Security, we’d like to help out with your RASP and IAST requirements.  K2 offers an ideal runtime protection security solution that detects true zero-day attacks, while at the same time generates the least false positives and alerts.  Rather than rely on technologies like signatures, heuristics, fuzzy logic, machine learning or AI, we use a deterministic approach to detect true zero-day attacks, without being limited to detecting attacks based on prior attack knowledge.  Deterministic security uses application execution validation, and verifies the API calls are functioning the way the code intended.  There is no use of any prior knowledge about an attack or the underlying vulnerability, which gives our approach the true ability to detect new zero-day attacks. Our technology has 8 patents granted/pending, and has no false alerts.

We’ve also recently published a video, The Need for Deterministic Security.  The video explains why the technologies used in today’s security tools, including web application firewalls (WAFs) fail to prevent zero day attacks and how deterministic security fills the need for detecting zero day attacks.  The video covers why technologies like artificial intelligence, machine learning, heuristics, fuzzy logic, pattern and signature matching fail to detect true zero day attacks, giving very specific examples of attacks where these technologies work, and where  they fail to detect an attack.

The video also explains why deterministic security works against true zero day attacks and how K2 uses deterministic security.  Watch the video now.

Change how you protect your applications, include RASP and check out K2’s application workload security.

Find out more about K2 today by requesting a demo, or get your free trial.