Security+ Course – 1.4 Application Attacks

1.4.1 Application Security

Our increasing dependence on software makes it essential that we use software that is known to be secure and reliable.

In one example of an application attack, a computer security expert hacked into a planes control system via the entertainment system by connecting his laptop to the device in his seat. He then used default username and passwords to connect to the planes IFE system using default ID’s and passwords. He overwrote code for the planes thrust management system which allowed him to make the plan climb on his command.
https://www.usatoday.com/story/tech/2015/05/16/chris-roberts-fbi-plane-hack-one-world-labs/27448335/

Whether a company purchases or develops the software they use, they have security responsibilities in both cases.

Application Hardening

Applications must:

• Use proper authentication
• Encrypt sensitive data so that if an attacker gains access to the data in a system they can not read the sensitive data
• Validate user in put to ensure it does not contain any dangerous code that can effect the system
• Ensure that applications are not vulnerable to any known exploits, and when exploit are they discovered they are promptly corrected

Prompt patching is critical! Attackers can sickly exploit new vulnerabilities.

Application Configuring

Organisations have responsibility for the configuration of their applications to ensure they are secure. This includes:

• type and scope of encryption on the data
• which users have access to the application
• what access these users are granted
• security in the underlying infrastructure that the databases or other systems run on

Configuration baselines allow quick identification and remediation of security gaps

1.4.2 SQL Injection Attacks

SQL Injection (SQLi) attacks use web applications as a mechanism to illegitimately access database servers that the web applications are using. The attacker uses user inputs on the web page to inject the code to the database. Using SQLi the attacker could:

• Access sensitive data
• Access users login credentials (then use these to login to the system to gain higher access)
• Alter data in the database
• Delete data
• In some systems it might be possible to access the Operating System. the attacker could then potentially access other systems on the network

Example of SQLi Attack

Take the example of an online furniture store. If you enter in the word ‘chair’ in the product search field, in the back end this is used to generate an SQL such as the following:

SELECT ItemName, ItemDescription
FROM Item
WHERE Item = ‘chair’

This would return all the chairs from the database and list them for you. An attacker could add some code to the search field box that would make the database return some extra information. An example of this would be using the ‘UNION Select’ statement as this combines the results of the search query’s. EG: if an attacker put the following in the search field:

‘chair’  UNION SELECT Username, Password FROM Users;

This would build the query:

SELECT ItemName, ItemDescription
FROM Item
WHERE Item = ‘chair’ UNION SELECT Username, Password FROM Users;

Which could in theory return all the usernames and passwords from the users table

Defending Against SQLi

• Use character filtering. Most SQLi attacks use single quotes. Filtering out these characters will partially protect the system
• Limit Record Lengths. If it is not necessary to input long lines of text, don’t allow long strings in the input fields. EG limit to 10 characters
• Restrict access to the database. The web user should only have limited access to certain columns or tables in the database
• Use a Database Firewall. Something like GreenSQL provides security that prevents against SQLi attacks 

1.4.3 Cross Site Scripting Attacks (XSS)

These attacks occur when an attacker embeds some malicious code in a third-party trusted website, that runs within the web browser of visitors to that site. This often happens on sites where a user can input some information that gets displayed to visitors of that site. An example of this could be an auction listing site. On these sites the seller can enter data to be displayed to visitors, and they may also allow you to add HTML code to format the page and jazz it up. An attacker may be able to insert some malicious code into the HTML, then when a visitor goes to this page the code will run in their web browser in the background as the browser thinks this is a trusted site. 

Defending Against XSS

• Validating Input. Prevent the user from entering special characters which may be part of the malicious code (EG: characters like:)
• Escaping. This means taking the inputted data and ensuring its secure before executing it. You can choose which HTML entities you will escape, and which you won’t. This means you could still allow things like adding rich text but block other HTML tags

1.4.4 Cross Site Request Forgery 

Exam tip: Cross Site request Forgery goes by all of the following:

• CSRF (sea surf)
• XSRF

CSRF preys on the fact that users may have multiple tabs open with different sites, and may be authenticated with some of these sites. These authentication sessions cross over between tabs using authentication cookie. CRSF attacks leverage this by using one site to trick a users browser into sending illegitimate requests to another site without the users knowledge.

There are two main parts to a CSRF Attack:

1. The attacker tricks the user into clicking a link (usually through social engineering) to go to a malicious site
2. This malicious site sends legitimate looking requests from the victims authenticated browser session to another website

CRSF Example

This is a good example which I have pinched from: https://www.acunetix.com/websitesecurity/csrf-attacks/

Let’s imagine that www.example.com processes fund transfers using a GET request that includes two parameters: the amount that is to be transferred and the identifier of the person to receive the money transfer. The below example shows a legitimate URL, which will request that the web app transfers 100,000 units of the appropriate currency to Fred’s account.

http://example.com/transfer?amount=1000000&account=Fred

The request includes a cookie that represents the authenticated user so there is no need to define the source account for the transfer. If a normal user accesses this URL, they need to authenticate so that the application knows the account from which funds are to be withdrawn. Using CSRF, we can trick a victim into sending the request that the attacker wants while authenticated as the victim.

If the exploited application expects a GET request, the attacker can include a malicious <img> tag on their own website. Instead of linking to an image, this tag sends a request to the bank’s web app:

<img data-fr-src=”http://example.com/transfer?amount=1000000&account=Fred” />

Under normal circumstances, the user’s browser automatically sends cookies that are related to that website. This causes the victim to perform a state change on behalf of the attacker. In this case, the state change is a transfer of funds.

Defending Against CSRF Attacks

If you are a developer you can:

• Instead of using cookies that store session tracking, use dynamically generated session tokens
• Prevent the use of HTTP GET requests

If you are an end user you should:

• Make sure anti-virus is up to date to block any malicious scripts
• Immediately log off banking sites etc… when you are finished
• Never save login detail in the browser
• Disable scripting in your browser

1.4.5 Clickjacking & Cursorjacking

Clickjacking

Clickjacking is a form of CRSF attack. An attacker may hide some HTML code behind another HTML element on the web page.

Clickjacking Example

you want to subscribe to a mailing list and click on the “subscribe” button on a web page. But behind that button is code to follow the attackers twitter account. If you are already logged into twitter in that browser session this could be successful and you would now be following the attackers twitter account. This is a fairly innocent example but you as can imagine it could be used a lot more malicious ways.

Cursorjacking

This is where the attacker either hides the users cursor, or puts a fake cursor on the screen to make the user think that they are pointing.

1.4.6 Directory Traversal Attacks

This attack allows an attacker to manipulate the file system structure on a web server. It is an HTTP attack that allows attackers access to restricted directories and execute commands outside of the web servers root directory.

Root Directory

The root directory is a specific directory on the server file system in which the users are confined. Users are not able to access anything above this folder. On a Windows IIS server the default root directory is: C:\Inetpub\wwwroot
Depending on the ACLs, the user can have access to everything in this directory including subfolders, but nothing outside of this directory. EG: C:\Windows.
An attacker can use directory traversal to step out of the root directory and access other parts of the file system.

How Directory Traversal Works

This following is an example of Directory Traversal using HTTP GET request from: https://www.acunetix.com/websitesecurity/directory-traversal/

Here is an example of an HTTP GET request URL:
GET http://test.webarticles.com/show.asp?view=oldarchive.html HTTP/1.1 Host: test.webarticles.com

With this URL, the browser requests the dynamic page show.asp from the server and with it also sends the parameter view with the value of oldarchive.html. When this request is executed on the web server, show.asp retrieves the file oldarchive.html from the server’s file system, renders it and then sends it back to the browser which displays it to the user. The attacker would assume that show.asp can retrieve files from the file system and sends the following custom URL.
GET http://test.webarticles.com/show.asp?view=../../../../../Windows/system.ini HTTP/1.1 Host: test.webarticles.com
This will cause the dynamic page to retrieve the file system.ini from the file system and display it to the user. The expression ../ instructs the system to go one directory up which is commonly used as an operating system directive. The attacker has to guess how many directories he has to go up to find the Windows folder on the system, but this is easily done by trial and error.

Defending Against Directory Traversal

• Ensure all web servers are up to date and fully patched
• Filter user input to remove some special characters

1.4.7 Buffer Overflow Attacks

What is a Buffer Overflow?

A buffer is a temporary area for data storage. A buffer overflow occurs when more data is put into the buffer than the buffer can hold. This data has to go somewhere and it overflows into the adjacent memory space, which can corrupt or overwrite the data already stored in this space. This can either cause the system to crash or the extra data can have some malicious code which could damage files or unveil private information.

Buffer Overflow Attack Example

The following example is from: https://www.veracode.com/security/buffer-overflow

Consider a program that requests a user password in order to grant the user access to the system. In the code below, the correct password grants the user root privileges. If the password is incorrect, the program will not grant the user privileges.

printf (“\n Correct Password \n”);
pass = 1;
}
if(pass)
{
/* Now Give root or admin rights to user*/
printf (“\n Root privileges given to the user \n”);
}
return 0;

However, there is a possibility of buffer overflow in this program because the gets() function does not check the array bounds. Here is an example of what an attacker could do with this coding error:

$ ./bfrovrflw
Enter the password :
hhhhhhhhhhhhhhhhhhhh
Wrong Password
Root privileges given to the user

In the above example, the program gives the user root privileges, even though the user entered an incorrect password. In this case, the attacker supplied an input with a length greater than the buffer can hold, creating buffer overflow, which overwrote the memory of integer “pass.” Therefore, despite the incorrect password, the value of “pass” became non zero, and the attacker receives root privileges.

Defending Against Buffer Overflow Attacks

• User input validation will help, EG: making sure there are restrictions preventing the user from inputting to many characters in the input field
• Error and exception handling will prevent buffer overflow
• Bounds checking at run time, this prevents overflow by automatically checking that data written to a buffer is within acceptable boundaries

1.4.8 Session Hijacking Attacks

Session hijacking is the exploitation of  valid web session (authentication cookie or token) to gain unauthorised access to a system.

What is a cookie?

An HTTP Cookie is a small piece of data sent from a website, then stored in the users web browser, while the user is browsing the internet. Cookies are used by websites to remember information such as:

• items added to a shopping cart
• which pages were visited
• usernames
• passwords
• addresses

Authentication cookies are used by web servers to know whether a user is logged in or not, and which account they are logged in with.

Session Sniffing/Session side jacking

The attacker uses packet sniffing to read network traffic between the two parties and steal the session cookie. The attack then uses this cookie to gain unauthorised access.

Session Prediction

This attack focuses on predicting session ID values by analysing, and eventually understanding, the session ID generation process. The attacker can then create a valid session ID value and bypass the authentication process to get access to an application.

Man in the middle attack

See this section: Man in the middle attacks

Cross-Site Scripting Attacks

See this section: XSS Attacks

1.4.9 Malicious Add-ons

Browser add-ons can add some useful functionality, but they can also be dangerous.

What are browser add-ons?

These are add-ons written by third party developers and add functionality to the users browsing experience. They add functionality such as:

• email reminders
• managing passwords
• translate web pages
• grammar checking
• etc…

Security Risks

• You don’t know who wrote the code. Someone could embed some malicious code in the add-on
• Permissions – the add-on may grant third parties access to your personal information

Staying Safe

• Always check the add-ons page to see if it comes from a reputable source
• check the permissions to view exactly what it has access to in your browsing environment
• Check the reviews
• Security administrators should limit the use to trusted add-ons with limited permission to access data

1.4.10 Code Execution Attacks

Code Execution Attacks are a special type of attack where an attacker exploits a vulnerability in a system that allows them to run commands on that system. This is normally done through a resource that is exposed to the world, EG: a public facing web server that has ports 80/443 open to the world. Once the attacker has access to the system they can run commands of their choice. This is known as Arbitrary Code Execution. When the attack takes place remotely it is known as Remote Code Execution. If they process or software they have exploited id running as an administrator, they then have full access to the system/network depending on the account. They can then install malicious code, access sensitive information, join the system to a botnet, create accounts for backdoor use etc…

Preventing Code Execution Attacks

• Make sure OS and applications are fully patched and up to date. Code execution attacks almost always exploit vulnerabilities in the OS or apps. Many of these vulnerabilities are known and have existing patches
• Run application services with restricted accounts that follow the principle of least privilege. This will limit the damage caused by a successful code execution attack

1.4.11 Driver Manipulation

What are Device Drivers?

A device driver is the software interface between the hardware device and the operating system. This software is written by the hardware manufacturer, not Microsoft, and requires low level access to the operating system to run. Therefore it runs with administrator privileges.

If an attacker can convince a user to install a malicious driver on their computer, that malware can gain complete control of the system

Refactoring Drivers

This is the process of modifying a driver to carry out malicious activities. If the attacker has access to the source code of the driver they can manipulate it to contain malicious code. In practice this quite difficult as it is not easy to get access to the source code.

Shimming Drivers

This is where the attacker takes a legitimate driver and wraps a malicious driver around it. The malicious driver, known as the shim, receives the requests from the operating system and passes them on to the legitimate driver so that the device appears to function as normal. However, the driver can also carry out its payload in the background.

Preventing Driver Manipulation

Modern operating systems contain protection against malicious drivers. this is in the form of code signing. The device manufacturers  write drivers and then apply digital signatures to them so that the operating system can verify the driver’s authenticity. If the driver is not digitally signed, or the digital signature is incorrect, the operating system may warn the user of the suspicious driver to prevent the drivers installation altogether.

1.4.12 Social Engineering Attacks

Social Engineering uses psychological manipulation to trick users into making security mistakes or giving away sensitive information.

Social Engineering Life Cycle

1. Investigation: the attacker investigates the victim to get background information, find weak security protocols etc…
2. Hook: the attacker engages the victim and gains their trust, spins a story, takes control of the interaction.
3. Play: the attacker executes the attack
4. Exit: the attacker brings the attack to a natural end and removes all traces of the attack

How are social engineering attacks successful?

There are 6 reasons these attacks are successful:

1. Authority: signs of authority creates trust. This can be as simple as wearing a suit or acting confidently
2. Intimidation: this is scaring or threatening someone that something bad will happen, that way they will hand over their personal information to resolve the fake bad situation. This could be someone claiming to be an IT helpdesk administrator and telling the assistant the bosses email account will be shutdown if they don’t reset their password
3. Consensus and social proof: this is the herd mentality. When we don’t know how to act, we look to others. This is happens when someone gets attacked in the street and no calls the emergency services.
4. Scarcity: this where the attacker makes the victim believe that if they don’t act quickly they will miss out. The kids call this FOMO.
5. Urgency: the attacker pressures the victim to work quickly as time is running out. EG: they tell staff the network will go down if they don’t get access to the comms room.
6. Familiarity or charming: the attacker charms the victim uses flattery and compliments to get on their good side and influence their actions

Defending Against Social Engineering Attacks

User education is the best defense for these attacks. Users must be aware of these tactics and wary of outsiders using thee tactics to gain trust.

Impersonation Attacks

SPAM is also knownn as Unsolicited Commerical Email (UCE).

Phishing
This is a subcategory of spam. The attacker sends emails trying to tick users into revealing passwords to sensitive accounts. EG: an attacker sends email to thousands of users warning them that there email account is a bout to run out space, it guides them to a form where it asks them to enter their credentials. The attacker then gets the credentials.

Credential reuse is a danger with phishing attacks. Many people use the same username and password across many sites. If they a tricked into giving their password during a phishing attack on a low risk site, the attacker may then try this username and password on more sensitive sites.

Spear Phishing
These are highly targeted phishing attacks. They target an audience such as employees in a small business or certain department. They use jargon and reference staff names to make their messages look more authentic.

Whaling
This is phishing attacks aimed at senior executives. One common attack is to send fake court documents saying the company is going to be sued, the executive clicks on the attacked link which has the paperwork, but also has some nasty malware.

Pharming Attacks
These often begin with a phishing message, then it might redirect the user to go a fake site, which looks like a legitimate site. The attacker might use typosquatting to make the URL seem familiar to users.
Pharming attacks might also use DNS poisoning to redirect victims to the fake site.

Vishing
This is a Voice Phishing attack. EG: the attacker pretends to be an IT helpdesk employee and calls the user and tells them they need to reset their password over the phone.

SPIM
This is spam via IM. It can be sent via Instant Messenger, SMS or iMessage. The attackers often use spoofing which means they can fake the identity of someone when sending the message.

Defending Against Impersonation Attacks
User training is the best defense against impersonation attacks.

Physical Social Engineering

This is an offline attack, where the attacker goes into the real world and engages in a physical attack.

Shoulder Surfing
This is where the attacker looks over the shoulder of a user while they do something sensitive on their computer. This may be an employee doing some work on a train, and an attacker monitors their activity.

Dumpster Diving
The attacker goes through the organisations rubbish trying to find some useful information. It is unlikely they will find any passwords, but they may find information they can use in a phishing attack. This may be organisation structure charts, changes happening, events etc…
The best way to defend against this is to shred everything.

Tailgating
In this case the attacker tails someone into a restricted building without having to swipe an access pass. They pretend they forgot their pass, are visiting someone (they could have a real staff members name), are delivering something, or have their hands full so someone holds the door for them.