Introduction to OWASP

For an enlightening session on day 2 of Chaos Carnival 2021, we had Gunnard Engebreth, OWASP, join us to speak about "Introduction to OWASP".

Gunnard starts off by giving a brief introduction about OWASP, "The OWASP's (Open Web Application Security Project) foundation was launched in 2001, and became incorporated as a USA not-for-profit charity in 2004."

OWASP is very culture-oriented and the principles are as following:

1. Open: Everything at OWASP is radically transparent from the finances to the code. 

2. Global: Anyone around the world is encouraged to participate in the OWASP Community.

3. Innovative: OWASP encourages and supports innovation and experiments for solutions to software security challenges.

4. Integrity: The community is respectful, supportive, truthful, and vendor-neutral.

OWASP TOP 10

The OWASP Top 10 is a standard awareness document for developers and web application security. It represents a broad consensus about the most critical security risks to web applications. So, every five years, they come together with 400 different companies and the people in the community, to look at all the bugs, cves, and exploits and to categorize them into a list. This gives them a rough idea of what's going on, what's been happening, and predicts what will happen in the future. All the things which are discussed here are ideologies and concepts. They are platform-agnostic and help in promoting multi-departmental impact through these solutions and reputable sources in the community.

DESCRIPTION:

1. Injection:
   Injection flaws such as SQL, NoSQL, OS, and LDAP injection occur when untrusted data is sent to an interpreter as part of a command or query.

• Threat Agent/Attack Vector:
  Almost any source of data can be an injection vector, environment variables, parameters, external and internal web services, and all types of users. Injection flaws occur when an attacker can send hostile data to an interpreter.

• Security Weakness:
  Injection flaws are very prevalent, particularly in legacy code. Injection vulnerabilities are often found in SQL, LAPD, XPath, or NoSQL, queries, OS Commands, XML Parsers, SMTP headers, expressions, and ORM queries. Injection flaws are easy to discover when examining code. Scanners and fuzzers can help attackers find injection flaws. 

• Injection Example:

  http://example.com/accountView?id=xxx or 1'='1

  The variable in the URL is run in a MySQL query in the database to check the existence of the username, password and the privileges of the user. The user ID then can equal xxx and return 0 or true (boolean interpretation of 1=1) and return some data which can be useful to the hacker.

  This changes the meaning of the query to return all the records from the accounts table. More dangerous attacks could be modified or delete data, or even stored procedures.

2. Insufficient Logging and Monitoring:
   Exploitation of insufficient logging and monitoring is the bedrock of nearly early major incidents. Attackers rely on the lack of monitoring and timely response to achieve their goals without being detected.
   One strategy for determining if you have sufficient monitoring is to examine the logs following penetration testing. The tester's  actions should be recorded sufficiently to understand what damages they may have inflicted.

Most successful attacks start with vulnerability probing. Allowing such probes to continue can raise the likelihood of a successful exploit to nearly 100%. In 2016, identifying a breach took an average of 191 days - plenty of the time for damage to be inflicted.

3. Using Components with known vulnerabilities:
   While it is easy to find already-written exploits for many known vulnerabilities, other vulnerabilities require concentrated effort to develop a custom exploit.
   Prevalence of this issue is very widespread. Component-heavy development patterns can lead to development teams not even understanding which components they use in their application or API, much less keeping them up to date. Some scanners help in detection, but determining exploitability requires additional effort.
   While some known vulnerabilities lead to only minor impacts, some of the largest breaches to date have relied on exploiting known vulnerabilities in components. Depending on the assets you are protecting, perhaps this risk should be at the top of the list.

4. Cross-Site Scripting (XSS):
   Automated tools can detect and exploit all three forms of XSS, and there are freely available exploitation frameworks.

   XSS is the second most prevalent issue in the OWASP Top 10, and Is found in around two thirds of all applications. Automated tools can find some XSS problems automatically, particularly in mature technologies such as PHP, J2EE /JSP, and ASP.NET. The impact of XSS can be severe with remote code execution on the victim's browser, such as stealing credentials, sessions, or delivering malware to the victim.

5. Security Misconfiguration:
   Attackers will often attempt to exploit unpatched flaws or access default accounts, unused pages, unprotected files and directories, etc to gain unauthorized access or knowledge of the system.

   Security misconfiguration can happen at any level of an application stack, including the network services, platform, web server, application server, database, frameworks, custom code, and pre-installed virtual machines, containers, or storage. Automated scanners are useful for detecting misconfigurations, use of default accounts or configurations, unnecessary services, legacy options, etc.
   Such flaws frequently give attackers unauthorized access to some system data or functionality. Occasionally, such flaws result in a complete system compromise.

6. Broken Access Control:
   Access control is detectable using manual means, or possibly through automation for the absence of access controls in certain frameworks.
   Access control weaknesses are common due to the lack of automated detection, and lack of effective functional testing by application developers.
   The technical impact is attackers acting as users or administrators, or users using privileged functions, or creating, accessing, updating or deleting every record.

7. Broken Authentication:
   Attackers have access to hundreds of millions of valid username and password combinations for credential stuffing, default administrative account lists, automated brute force, and dictionary attack tools. Session management attacks are well understood, particularly in relation to unexpired session tokens.

   Session management is the bedrock of authentication and access controls, and is present in all stateful applications. Attackers can detect broken authentication using manual means and exploit them using automated tools with password lists and dictionary attacks.
   Gunnard proceeds to give an example of a data breach case in the past with a  company called RockYou, "In December 2009, the company experienced a data breach resulting in the exposure of over 32 million user accounts. The company used an unencrypted database to store user account data, including plaintext passwords (as opposed to password hashes) for its service, as well as passwords to connected accounts at partner sites (including Facebook, Myspace, and webmail services). RockYou would also email the password unencrypted to the user during account recovery. They also did not allow using special characters in the passwords. The hackers used a 10-year-old SQL vulnerability to gain access to the database. The company took days to notify users after the incident, and initially incorrectly reported that the breach only affected older applications then it actually affected all RockYou users."

8. XML External Entities (XXE)
   Attackers can exploit vulnerable XML processors if they can upload KML or include hostile content in an XML document, exploiting vulnerable code, dependencies or integrations.

   By default, many older XML processors allow specification of an external entity, a URI that is dereferenced and evaluated during XML processing. These flaws can be used to extract data, execute a remote request from the server, scan internal systems, perform a denial-of-service attack, as well as execute other attacks.
   Gunnard here arises a question upon the vulnerability of the application, to which he answers, "The application accepts XML directly or XML uploads, especially 1 from untrusted sources, or inserts untrusted data into XML documents, which is then parsed by an XML processor. Any of the XML processors in the application or SOAP based web services has document type definitions (DTDs) enabled. If the application uses SAML for identity processing within federated security or single sign on (SSO) purposes. SAML uses XML for identity assertions, and may be vulnerable. Being vulnerable to XXE attacks likely means that the application is vulnerable to denial of service attacks including the Billion Laughs attack."
   Gunnard defines The Billion Laughs Attack as, "It is a denial-of-service attack that targets the XML parsers. It is an exponential entity expansion attack and is also called an XML bomb." Post this, he goes on to explain the attack through an easy-to-understand demonstration.

THE MIND OF AN ATTACKER

Hacking is unethical but in order to protect your systems and infrastructure from hackers, we need to think like one. By this method, we can draw a projection and protect ourselves beforehand. OWASP has created OWASP Juice Shop. This is a purposely insecure web app that utilizes game theory to entice you to break in.

The Juice Shop is linked to a scoreboard that helps you keep track of your progress and leads you through the different challenges. There is no link to the scoreboard, it is one of the challenges. The first Item in the tutorial tells us to look at the jS code within DevTools by hitting F12 or to Just start guessing the URL of the scoreboard.

OWASP ZAP is another flagship project that can help you automatically find security vulnerabilities in your web applications whilst developing and testing them.

In conclusion to the whole session, Gunnard recapped, "All developers should be aware at all times. Internal pen-testing should be a part of CI/CD through ZAP, Linpeas, and NMAP. Security policy template from OWASP 10 can be put in use."