Overview of the MITRE ATT&CK
The MITRE ATT&CK is a publicly-accessible knowledge base of adversary tactics and techniques based on real-world observations. It is used as a foundation for the development of specific threat models and methodologies in the private sector, government and the cybersecurity product and service community. The aim of the MITRE ATT&CK is to solve problems for a safer world by bringing communities together to develop more effective cybersecurity. ATT&CK is open and available to any person or organization for use at no charge.
What are internet/public-facing applications?
Internet/public-facing applications are programs or systems that are not only accessible from within the internal network but are also accessible from the internet. These applications are responsible for either providing services to the public or allowing access into the internal network. Quite often, these applications are connected to databases (such as MySQL), standard services (such as SMB or SSH) and other applications with internet-accessible open sockets (such as web servers).
What are some examples of vulnerabilities affecting internet/public-facing applications?
Each year, there are some vulnerabilities that are considered the most prevalent and are thus documented in the OWASP Top 10. OWASP is the abbreviation for Open Web Application Security Project, an online community that shares information concerning web application security. The community is keen on providing methodologies, articles, documentation, tools and technologies on web application security. The following are the latest top 10 vulnerabilities as per OWASP Top 10 – 2017:
A1:2017 – Injection: Here the application suffers from injection vulnerabilities such as LDAP, SQL, NoSQL and OS. The attacker sends input containing malicious characters to the application, and that input that get injected into the database or the operating system, causing the execution of unwanted commands/actions (against the developer’s wish). A2:2017 – Broken Authentication: Here the application handles authentication and session management incorrectly. Attackers become able to manipulate and steal tokens, passwords and sessions. They are also able to impersonate legitimate users using other accounts. A3:2017 – Sensitive Data Exposure: The application here may allow the attacker to access unauthorized information such as usernames, passwords and healthcare and financial information. Attackers are then able to use this information to conduct different types of fraud. A4:2017 – XML External Entities (XXE): When the application contains poorly configured XML processors, it may be manipulated by attackers into referencing internal files using the URI handler instead of external entities. This ends up allowing attackers to perform activities such as port scans, remote code execution and denial-of-service attacks. A5:2017 – Broken Access Control: Applications that do not properly restrict what authenticated and non-authenticated users are able to do may allow attackers to access other user accounts, view sensitive files belonging to other users, modify other users’ data and so on. A6:2017 – Security Misconfiguration: Here, the application is improperly configured, allowing attackers to take advantage of default configurations such as default passwords, verbose error messages with sensitive information disclosure, or even open cloud storages. A7:2017 – Cross-Site Scripting (XSS): When the application does not properly sanitize input, attackers can include untrusted data that manipulates XSS. This allows attackers to be able to steal user cookies (sessions), deface websites or even redirect users to malicious sites. A8:2017 – Insecure Deserialization: On a vulnerable application, this will often lead to remote code execution. Deserialization flaws can also lead to replay attacks, injection attacks and even privilege escalations. A9:2017 – Using Components with Known Vulnerabilities: Applications allow for components such as libraries, plugins and frameworks to run with the same privileges as the application. Considering a vulnerable application, attackers can be able to perform account takeovers and other attacks if these vulnerabilities remain unpatched. A10:2017 – Insecure Logging and Monitoring: When applications do not support audit trails, attackers can perform malicious activities which can largely go undiscovered.
Even though these vulnerabilities are pretty potent, OWASP each year lists the most prevalent vulnerabilities attacking web applications. It is important to be aware of the various other vulnerabilities that can place web applications at risk, such as the CWE/SANS top 25.
What are some of the tools that exist today that can compromise public-facing applications?
From time to time, hackers will rely on the use of automated tools to attack vulnerable internet facing applications. This is so because some vulnerabilities are well hidden within the web application and are not obviously identifiable unless using a tool. Tools also make it easier to exploit vulnerabilities because they are not prone to errors, unlike manually exploiting vulnerabilities. The following are some good tools that are used to attack public facing applications:
Sqlmap: This tool is one of those heavily relied on by hackers performing SQL injection attacks on public-facing applications. Malicious hacker groups that have used this tool before include Magic Hound (an Iranian-sponsored threat actor). Havij: This tool allows hackers and pentesters to perform SQLi automation. Magic Hound is also known to have made use of this tool. Hikit: This malware has been used by the Axiom threat group for late-stage persistence and exfiltration of data from compromised targets.
There are various other open-source and commercial tools (such as BurpSuite) that have been widely used for attacks against public-facing applications. These are mostly found within Kali Linux, an open-source Linux hacking operating system.
How are exploits against public-facing applications detected?
In order for one to detect exploits against public-facing applications, it’s important to understand how the application and network traffic work. The following are some key concepts that will help in identifying attacks:
Packet inspection: The ability to perform packet inspection allows for the dissection of network traffic in order to distinguish malicious traffic from acceptable traffic. By assessing inbound and outbound traffic, it is possible to determine whether the application has been compromised to, for instance, exfiltrate data or act as part of a botnet. Log inspection: There are some tools available that provide log inspection capabilities. This functionality allows for the identification of malicious attempts at the exploitation of the application. For instance, attacks that attempt to inject malicious scripts, will be blocked and logged. Malicious injections may target web application templates, application input fields for SQL injection vulnerabilities, search fields and text fields and parameters for cross-site scripting and SQL injection vulnerabilities.
Some exploits become successful since the vulnerabilities exploited are previously unknown (zero-days) and therefore have no defense against yet. However, intelligent solutions exist that are capable of performing heuristics. This allows them to identify attacks by analyzing exploit patterns.
What mitigations are in place against exploits targeting public-facing applications?
There are quite a large number of measures that can be put in place to prevent attacks against public-facing applications. As a result of this, we decided to list the most common:
Application isolation and sandboxing: This tends to limit the level of access that an attacker will get on a compromised system once an attack is successful. This is normally achieved by setting up virtual machines and application sandboxes. Attacks are effectively thwarted through this method, since attackers are unable to pivot from one compromised system to the other. Exploit protection: Solutions such as Web Application Firewalls are able to limit the exposure of applications from exploits. They work by blocking exploit traffic from getting through. Such traffic may include injections (XML, XSS, SQLi and so on) that may end up compromising the entire application. Network segmentation: This works by having a DMZ that separates external-facing servers from the internal network. The external-facing servers may also be hosted on separate hosting infrastructure to prevent malware or an attack from getting to the internal network. Privileged account management: Most attacks are successful due to the level of access that attackers achieve once they successfully compromise an application. It is best to use the least privileges for service accounts. Update software: Public-facing applications are mostly exploited due to vulnerable software running within them. It is best to frequently update software to the latest versions in order to prevent attacks against vulnerable web components. Software updates not only patch known vulnerabilities, but also introduce more stable and optimized code that prevents system malfunctions. Vulnerability scanning: Public-facing applications should be regularly scanned for known vulnerabilities and misconfigurations that could lead to an attack. Vulnerability scanners will scan for known vulnerabilities and generate a report with recommendations on best practices and how to patch the discovered issues.
It is worth noting that there are many more measures that can be put in place, and the list above is not by any means exhaustive. For instance, one extra measure not mentioned above involves the encryption of data in transit and at rest to prevent man-in-the-middle attacks.
Conclusion
Public-facing applications are some of the most targeted online today due to the huge number of web applications on the internet. As the number of web applications continue to rise, attacks against them will most certainly be more prevalent.
Sources
Top 10 OWASP Vulnerabilities, haltDos OWASP Top 10 – 2017, OWASP 2019 CWE Top 25 Most Dangerous Software Errors, CWE
