/
Common Vulnerabilities

Common Vulnerabilities

Owned by Roger Cruz
Last updated: Dec 26, 2019

Intro

Describes common vulnerabilities to look out for.

Threat Classification


The following are the type of threats.

  • Information disclosure (e.g. reading sensitive data)
  • Tampering (e.g. modifying data).
  • Privilege escalation (e.g. command execution)
  • Denial of Service (e.g. app constantly crashes due to bug)
  • Spoofing/Repudiation


Vulnerability Scanners


Some vulnerability scanners:

  • Aqua Security
  • BlackDuck Hub
  • JFrog XRay
  • WhiteSource



Test Techniques

To identify threads, use:

  • Static code analysis
  • Vulnerability scanning
  • Fuzz testing
  • Penetration testing.


OWASP Top 10 Vulnerabilities


OWASP maintains a list of the top 10 web application security risks.


Checkout the OWASP extensive cheatsheet lists: https://github.com/OWASP/CheatSheetSeries

They also provide open source libraries, such as Enterprise Security API (ESAPI) that helps with web security, including CSRFGuard is a library that implements a variant of the synchronizer token pattern to mitigate the risk of Cross-Site Request Forgery (CSRF) attacks.


Common Weakness Enumeration (CWE)


Mitre maintains a list of the top 25 CWEs: https://www.sans.org/top25-software-errors


Some good ones to know:

  • CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
  • CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
  • CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
  • CWE-190: Integer Overflow or Wraparound


Buffer Overflows

To help prevent buffer overflows use: Address Space Layout Randomization, the /GS compiler flag, and Data Execution Prevention. Note that /GS does not insert the security cookie in all functions calls.  If you want that extra security, use #pragma strict_gs_check 

Avoid banned C/C++ library calls: Microsoft's List of Banned Functions


To attack, try sending bad data to any place the application receives input:


CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')


SQL Injection

SQL injection allows bad actors to dynamically construct SQL database queries which the database engine dutifully executes.  This can lead to exposure of all the data in the DB or modification of said data.

Ways to avoid SQL injection:

  • Stored procedures:  canned SQL statements are stored in the database.
  • Parameterized/prepared statements: data is bound to parameters at execution using placeholders.  DB engine then knows that the data specified in the parameters should be treated just as a value and not interpreted as a SQL command.
  • Use secure frameworks provided by the language libraries


To identify areas where SQL injection can take place, look at your application for places where user input is sent to the database.  For example:

  • Authentication forms
  • Search boxes
  • Item listings
  • Content submission

The information from above can be sent to your application via URLs, HTML forms, cookie values, etc, all of which can be compromised.


Look for SQL injection cheatsheets on the web for SQL statements that cause injection: https://www.netsparker.com/blog/web-security/sql-injection-cheat-sheet/


Malicious Files

Files with (bad) names, size, streams or content which can cause an application to misbehave.


Look in your application for all places that handle files.  For example:

  • FTP uploads
  • Command line or URL
  • Email attachments 
  • Predetermined file locations


Ways to attack:

  • Use an HTTP proxy tool to monitor a file upload to a website.  You can then use the tool to change the name of the file being uploaded to a script that executes.
  • Make the filename the same as other applications in the webserver and place them in directories contained in the $PATH variable.
  • Use fuzzing tools to generate thousands of files that are fed to the application.  Look for crashes or hangs via process monitoring.
  • Try to upload multiple large files to the application to see if it runs out of space and how it behaves.
  • NTFS files with multiple streams can be used to trick systems which only check file sizes on the default stream.  You can create file with multiple streams, the default having a small size and others having a very large size.


XML Injection


SOAP messages are formatted using XML.  They contain tags and data values which can attacker-in-the-middle can modify to insert their own tags + values.  This is known as XML injection.


XML External Entities (XXE) Attack


XML allows you to dynamically include (inline) an external file via the syntax <!ENTITY name SYSTEM "uri"> (eg <!ENTITY xxe SYSTEM "fie:///etc/passwd">).   This can allow a hacker to exfiltrate a file from the system.


XPath Injection Attack

XPath (XML Path Language) is used to query the notes in an XML document.  It follows standard file path syntax with a "/" delimiting nodes.  Attackers can construct a path query that returns more data from the document than expected 



Coercive Parsing Attack

Attacker sends a deeply nested XML SOAP message, which causes the parser to allocate memory for each node, thereby exhausting all memory and causing a DOS 


Oversized SOAP Attack

Similar to the Coercive parsing attack, the goal is to cause an DOS by sending such a large message (either SOAP header or body) that it exhausts all system resources.


SOAP Array Attack

Similar to the oversized SOAP attack looking to overwhelm the server.  It contains an "array" declaration with a huge number of elements


SOAP Parameter Tampering

Attacker adds extra parameters to a SOAP message, which can lead to buffer overflows, SQL injection, etc.


Insecure direct object reference (IDOR)

When an application provides direct access to web pages or data based on user-supplied input.

Example:

http://somewebsite.com/invoices?id=22220 ← what happens if you change the invoice ID to a different number?  Will you get another person's invoice?  

Failure of access control



Source: Web Security: User Authentication and Access Control

Cross-Site Scripting (XSS)

XSS vulnerabilities allow an attacker to insert javascripts into the victim's computer.

Look for XSS cheat sheets to learn how to cause XSS and combat them:


During code review, look for any input (whether from user or database) that is used in constructing a user's webpage.   For example, in handling an error message, the user's input is echo'ed back.  If the input is not properly encoded, script code passed in as input can be executed.


Sample script that can be passed in as user input
<script>alert(document.cookie)</script>


Use commonly-provided encoding functions to thwart the attack


HTML encoding function
using System.Web
string encodedString = HttpUtility.HtmlEncode(userinput);


A better encoding library is the Anti-XSS library: 

Microsoft.Security.Application.AntiXSSLibrary.HtmlEncode(userinput);


You can prevent a XSS script from stealing cookies by having the web application declare that cookies are HTTP-only.


CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')


Integer Overflow


For testing, exploit boundary conditions of the input integers (MIN INT , MAX INT (+1), zero, Microsoft's list of magic numbers) 

CWE-190: Integer Overflow or Wraparound


Format String Attack


Attacks usually come from:

  • UI input, URL/API parameters, network data, file contents


Strings that can cause unexpected behavior:

  • %s%s%s - print the contents of the stack as a string.  Adding extra %s helps stop a 0 in the stack from terminating the "string"
  • %999999s - allocate and attempt to print 999,999 bytes as a string.  Likely will crash application.
  • %1024d - similar to above but allocates 1024 bytes and tries to interpret as an integer.
  • %n - %n is supposed to write the number of characters already printed to an integer variable.  The hack can be used to write to memory (ie that integer variable).


Some other useful patterns


Forced Browsing


Crawling through web pages you are not allowed to see.   



Access Spoofing


Getting access by pretending to be someone else.


Common spoof-able items are:

  • IP Address
  • MAC Address
  • Process Name
  • Registry/Config values
  • HTTP Referer
  • Pipes
  • Emails


To test for pipe vulnerabilities, use Process Explorer to examine your application for named pipes.  Then create a test application which tries to read/write to those pipes.  You can also introduce race conditions by creating the named pipe before the application has done it. You may need to name your hacking tool with the same process name as the application.


Ways To Defend Against Attacks


Input Validation

Badly formatted input from untrusted sources (e.g. bad actors or other software components) can be used to exploit software.  To avoid, use input validation code, known as whitelisting, which checks for expected format (input type, length, format and range).

Encrypted Communications

To avoid snooping of data, use encrypted communications (TLS 1.2 minimum) between all components.

Network Access Controls

Prevent users from accessing resources directly, for example, a DB.  Use firewall rules to limit access to specific applications.

DB Errors

A bad actor can gain meaningful information (such as the DB schema) by causing an error in a DB command.  DB errors to the users should be suppressed.


Reduce Attack Surface

Disable unused features or set role base access to certain features to decrease possible attack points.


Least  Privilege

Run the application with the least set of permissions needed to function.  For example, instead of using the SYSTEM account in Windows, use the NETWORK SERVICE account.


Defense In Depth

Add multiple layers of defense to reduce possibility of intrusion. For example, add multiple defenses like input validation, parameterized SQL statements, least privilege, DB encryption, etc.


Static Code Analysis