Friday, January 29, 2016

Nowadays we use Wi-Fi every now and
then - in home, office or even in public places. But, how safe is it
?

Evil Twin is one very common recent
threat that we need to consider before we use Wi-Fi, especially in
public places.

What is Evil Twin

Evil Twin is basically a rogue Wi-Fi
access point. It may look very similar to a legitimate one. But, it
actually is a Wi-Fi access point controlled by attackers. Most of the
time, it contains an SSID or Service Set Identifier of the access
point very much similar to the legitimate one. Sometimes, it even
provides signal stronger than the legitimate ones so that it can
attract attention easily. But, it is actually controlled by the
attackers. So, any data traveled through that Evil Twin Wi-Fi access
point can be intercepted by attackers.

Purpose of Evil Twin

Attackers make Evil Twin mainly for
stealing sensitive data or for other Phishing attacks. If a victim
connects to an Evil Twin, any non-HTTPS data can be easily
intercepted, as it travels through the attackers' equipment. So, if
the user logs in to unprotected bank or email account, the attacker
will have access to the entire transaction.

The victim may even be tricked with a
login prompt of attacker's server, tempting him to provide sensitive
information like usernames and password and resulting in a Phishing
attack.

How is Evil Twin created

An Evil Twin can easily be created by
an attacker with a smartphone or computer and with some easily
available software. The attacker first places himself near a
legitimate Wi-Fi hotspot and finds out the SSID or Service Set
Identifier and signal strength of the access point. Now, he sends his
radio signal using the same or very similar SSID. The attacker may
even position himself near the potential victims so that his signal
can lure the victims. Some attackers even use some software to
deauthenticate the victims from legitimate Wi-Fi access point, so
that when they connect back they would connect to the Evil Twin, as
it provides stronger signal.

Mitigation

It is always a good idea to use
VPN. It creates an encrypted tunnel before transmitting data. As a
result, it is hard for the attacker to intercept that data.

Some software like EvilAP_Defender
can be used by network administrator to detect Evil Twin. They try
to find out :

Wi-Fi access points with
similar SSID, but different BSSID or MAC address of wireless
access point.

same BSSID as the legitimate
one, but with different attributes like channel, cipher, privacy
protocol, authentication etc.

Even with same BSSID and
attributes as the legitimate access point, but with different
tagged parameter like OUI or Organizationally Unique Identifier
which is assigned by the IEEE registration authority.

Before connecting to a Wi-Fi do
not just rely on the name of the wireless access point, instead
verify whether it is a legitimate one.

It is always better to restrict
browsing only to websites that do not require any sensitive data
like login credentials while using a public Wi-Fi.

Avoid providing any sensitive
information even any website or login screen asks for that while
using public Wi-Fi.

So, beware of all the security
vulnerabilities and recent threats and stay safe, stay secured.

Wednesday, January 27, 2016

Sometimes web applications do not take
proper cautions in processing user inputs and use them in the server
without sanitizing it properly. And, attackers take advantage of that
for perpetrating attacks. LDAP Injection Attack is one such attack,
in which the attackers exploit web applications that construct LDAP
statements using unsafe user inputs without taking proper
precautions.

Let's understand what this attack
basically is.

What is LDAP

Suppose, we are using an email client
and want to look for an email address before sending out an email. We
can do that easily if the person is present in the addressbook.

But, think of a big organization where
thousands of employees are present and we want to look for an email
address of someone whom we never sent an email before. This problem
can be resolved efficiently using LDAP or Lightweight Directory
Access Protocol.

In LDAP, an LDAP server is maintained
and an LDAP client, can use LDAP APIs to contact the LDAP Server and
access information. For example, if we want to search for email
address of a person named 'John' who lives in San Francisco, we would
type in the information in the LDAP Client program. The LDAP Client
will then contact the LDAP Server using LDAP APIs and information
will be retrieved.

LDAP is used for looking up not only
contact information, but also encryption certificate, pointers to
printers and other services on network like single sign-on, where a
single password is used to login to all services in the organization.

LDAP basically is an application
protocol and is used to maintain distributed directory information
services over an IP network. It indexes all the data related to some
distributed internet directory in a simple tree hierarchy and
retrieves them efficiently when required.

How is LDAP Injection Attack perpetrated

Suppose, a web application of a company authenticates an employee with his username and password and gives access to sensitive applications.

Now, the login page typically will have two boxes, for username and password. And, taking inputs from an employee, it will authenticate the employee.

Suppose, the web application creates an LDAP query string from the user inputs and makes corresponding LDAP query to the server to get response. And suppose, the web application is vulnerable to LDAP Injection Attacks, as it does not sanitize the user inputs properly before making the LDAP query string.

At this point, suppose an attacker gives 'johns)(&)' as username and any random value as password.

That would make an LDAP query something like this :

(&(USERNAME=johns)(&)(PASSWORD=somerandomvalue))

This query string would be sent to the LDAP server, but the server would process only the first part of the query :

&(USERNAME=johns)(&)

As a result, if johns is a valid username, the attacker can now impersonate the user to the web application and exploit it for malicious purposes.

This is a simple example of LDAP Injection Attack. Attackers can perpetrate even more complex attacks depending on the actual vulnerabilities.

Mitigation

User supplied data must be sanitized properly so that it does not contain any string or character that can be used maliciously. Inputs containing only some allowable characters should be used and regular expressions should be avoided.

Before an output is returned to the user, it should be verified that it contains only the specific information. Amount of data returned by a query can be restricted.

LDAP should be configured cautiously, so that there is proper access control on the LDAP directiory. Access level used by the web application should be minimal.

This article was meant to give information on another security vulnerability of web applications. Hope it solved its purpose.

Tuesday, January 26, 2016

A web application becomes vulnerable to
attack when it does not sanitize user-supplied data properly and use
it unsafely to access other data from the server. XPath Injection
Attack is one such attack. Many web applications become vulnerable to
XPath Injection when they use user-supplied data unsafely to
construct a XPath query for XML data.

Let's understand in detail what
actually it is.

What is XPath

Many web applications use XML or
EXtensible Markup Language to store and
transport data in both human readable and machine readable format. It
is often used to separate data from presentation.

To give an example, a web server may
store data in separate XML files and write a small JavaScript code to
read the XML files and update the contents of HTML pages.

XSLT or EXtensible
Stylesheet Language Transformations is a
recommended stylesheet language for XML, which is used to transform
an XML document into HTML.

XPath is a major element in
XSLT. It is used in XSLT to navigate through an XML document to find
out required information.

So,
an attacker can send a malicious username and password in the web
application to select XML nodes without knowing any actual username
and password.

Username: blah' or
1=1 or 'a'='a

Password: blah

So,
logically FindUserXPath becomes equivalent to :

//User[(UserName/text()='blah'
or 1=1) or

('a'='a' and
Password/text()='blah')]

As
the first part of the XPath is always true, the password part becomes
irrelevant and the UserName part matches the admin. And thus, it can now reveal sensitive information from the server to the attacker, which the attacker can exploit for malicious purposes. And, the web
application becomes vulnerable to XPath Injection Attack.

In
a dynamically constructed XPath query, if you are using quotes to
terminate untrusted input, then make sure to escape that quote in
the untrusted input, so that the untrusted input cannot try to break
out of the quoted part. For example, if single quote (') is used to
terminate the input username, then replace any single quote (')
character in the XPath query with XML encoded version of that
character, for example “&apos;”

Using
precompiled XPath query is always good. With this, the user inputs
get escaped properly without missing any character that should have
been escaped.

Monday, January 25, 2016

Many a times attackers exploit security
vulnerabilities in web applications and inject their malicious codes
into the server to steal sensitive data, spread malware or do other
malicious activities. Server Side Includes Injection Attack or
SSI Injection Attack is one such attack.

In SSI Injection Attack, the attacker
takes advantage of security vulnerabilities of web applications to
inject their malicious code using Server Side Includes directives and
perpetrate the attacks.

Let's discuss in details how it is
actually done.

What is Server Side Includes or SSI
?

Nowadays, most of the web servers
handle dynamic pages. It takes input from the user in the form of
text box, radio buttons, pictures etc and the information is passed
to a program in the web server, which then processes the information
and generates output. The output is sent back to our browser and our
browser finally displays the HTML page.

But, at times dynamically generating
the whole page becomes inefficient and it is not needed too. Instead,
a part of the page content can be dynamically generated and it can be
added to an existing HTML page. Server Side Includes are
directives that are used for that purpose. Using these directives,
dynamic contents can be embedded to an existing HTML page and then
displayed.

For example, a webpage may display
local date and time to a visitor. Dynamically generating the page
every time using some program or dynamic technology may prove to be
inefficient. Instead, one can put the following SSI directive to an
existing HTML page :

<!--#echo
var=”DATE_LOCAL” -->

As a result, whenever the page will be
served to the client, this particular fragment will be evaluated and
replaced with the current local date and time :

Sunday,
25-Jan-2016 12:00:00 EST

The
decision of whether to use SSI directives to dynamically generate a
particular fragment of the page or to dynamically generate the whole
page using some dynamic technology, often depends on how much of the
page is to be dynamically generated. If a major part of the page
content is to be dynamically generated, then SSI may not be a good
solution.

Server
Side Includes Injection Attack or SSI Injection Attack

In
SSI
Injection Attack,
the attacker first finds out whether a web application is vulnerable
to Server Side Includes Injection or SSI Injection. Normally, a web
application is vulnerable to SSI Injection through manipulation of
existing SSI directives in use or through lacking in proper
validation of user inputs.

If
a web application has pages with extension .stm, .shtm, .shtml, then
that would indicate to the attackers that the web application is
using SSI directives to dynamically generate page contents. At this
point, if the web server permits SSI execution without proper
validation, then the attacker can trick the webserver to execute SSI
directives to manipulate filesystem of the web server and thus, to
add, modify and delete files or to display content of sensitive files
like /etc/passwd.

On
the other hand, the attacker can type the following characters in the
user input field to find out whether the web application properly
validates the user inputs :

< ! # = / . " - > and [a-zA-Z0-9]

As
these are the characters often used by SSI directives, the web
application will become vulnerable to SSI Injection if it cannot
properly validate the user inputs and allow these characters to be
present in the input when they are not expected. The attacker can
take advantage of that and access sensitive information or execute
shell commands for nefarious purposes.

As
the SSI directives are executed before supplying the page content to
the client, the data intended for the attack will be displayed the
next time the webpage is loaded.

Example

Suppose,
a web application is vulnerable to SSI Injection. At this point, the
attacker can trick the web server to execute the following SSI
directive and display current document filename :

<!--#echo
var=”DOCUMENT_NAME” -->

The
attacker can create a file attack.shtml with the following content :

attack.shtml

<!--#include
file=”AAAA....AAAA” -->

with
number of A's more than 2049.

At
this point, suppose the web application loads a legitimate URL like :

vulnerable.com/index.asp?page=about.asp

Now,
the attacker can include his own file attack.shtml in the web
application like :

vulnerable.com/index.asp?page=attacker.com/index.asp?page=attack.shtmlIf the web server returns a blank page, that would indicate an overflow has occurred. So, the attacker can now get enough information to trick the web application to execute malicious code.

Mitigation

- User inputs should be properly validated so that it does not contain characters like <, !, #, =, /, ., ", -, > and [a-zA-Z0-9] if they are not needed.- Make sure the web server only executes SSI directives needed for a particular web page.- HTML entity encode user inputs before passing it to a page that executes SSI directives.- Make sure a page is executed with the permission of the file owner, instead of that of the web server user.Being informed about various web application security vulnerabilities is the very first step towards safeguarding a web application. Hope this article served its purpose.

Saturday, January 23, 2016

Many web applications use SQL to store
and retrieve sensitive data required by the users. It may be user
credentials, transaction details or it may be other data useful to
the web application.

For example, let's suppose a user wants
to search for the availability of a book in a ecommerce website. To
do that, he will first enter the author or title of the book in the
search bar. At that time, the web application will receive the user
input, process it and make appropriate SQL query to the database. It
will then process the output returned by the database and display
that to the user nicely formatting it.

But, sometimes a web application can
have security vulnerabilities and the attackers can exploit those to
update, delete or steal sensitive data stored in the database. A
Blind SQL Injection Attack, which is a type of SQL
Injection Attack, is one such attack widely perpetrated by the
attackers.

What is a Blind SQL Injection Attack

Suppose, in a web application
ecommerce.com, a user can search for a particular book with the name
of the author or title or description of the book. When the user
inputs “John” in the search bar, the following URL is loaded :

ecommerce.com/books.php?author=john

This
results in execution of the following SQL query to the database :

SELECT
* FROM bookinfo WHERE author = 'john';

And,
the output is nicely formatted and shown to the user.

But,
suppose an attacker loads the URL :

ecommerce.com/books.php?author=john
OR 1=1

If the web application embeds the user
input to SQL query directly, it would result in the following SQL
query in the database :

SELECT
* FROM bookinfo WHERE author = 'john' OR 1 = 1;

And, in that case, the web application
will list all the books in their database in the webpage shown to the
attacker.

Now, the attacker can load the
following URL next :

ecommerce.com/books.php?author=john
AND 1=2

And,
if the web application has Blind SQL Injection vulnerabilities, this
will result in execution of the following SQL query :

SELECT
* FROM bookinfo WHERE author = 'john' AND 1 = 2;

Clearly,
the database will return 'false'. And, if the web application shows
generic error messages or shows error messages from the database, it
will reveal enough information to the attacker. By executing these
two queries, the attacker will be confirm that the web application
has Blind SQL Injection vulnerabilities and now he can execute even
more queries to extract more information like version of SQL used
etc. These type of attacks which test the database with various
queries, like true and false queries and extract information so that
the attacker can plan for even more attacks, are called Blind SQL
Injection attacks.

How is Blind SQL Injection
Attack different from SQL Injection Attack

Blind
SQL Injection Attack is a particular type of SQL Injection Attacks.
Normally, in SQL Injection Attacks, the attacker exploits the
security vulnerabilities of the web application to trick it to
execute malicious SQL queries, that can update the database, delete
sensitive data or reveal sensitive data like username, password or
credit card numbers to the attacker. In Blind SQL Injection Attack,
the attacker may not directly update or delete the database, but it
can make several queries to the database and deduce information from
it so that he can now make even more attacks.

Both
SQL Injection Attacks and Blind SQL Injection Attacks are difficult
to catch, but with some precautions it can be mitigated.

Mitigation

There
are couple of precautions we can take to mitigate this attack.

User
input should not be embedded in the query directly. Instead,
parameterized statements that work with parameters should be used.

Type
constraints of variables should be properly checked before executing
the query.

For
parameterized statements, parameters should be escaped properly. For
example, in PHP mysqli_real_escape_string() can be used to escape
parameters.

Certain
characters can even be forbidden to be used in the query.

Database
permissions should be limited appropriately. Some tables can be
restricted to be fetched without appropriate permissions.

Bin2hex()
and unhex() can be used to convert the parameters to/from hex
values. The advantage of this is, the output of unhex() function is
returned as a string and not interpreted.

Thursday, January 21, 2016

DNS Hijacking is one of the most
common recent threats, in which the attackers subvert the resolution
of Domain Name System or DNS queries and redirects a
victim machine to malicious websites for nefarious activities.

Study says, attackers can perpetrate
DNS Hijacking while transporting emails from one mail server to
another and thus, steal sensitive data transferred through the
emails.

Let's understand in detail how it is
possible.

What is DNS Hijacking Attack ?

When we type a URL in the address bar
of the browser, the computer sends DNS query to appropriate DNS
Servers and resolves the IP address of the required website.

In DNS Hijacking, the attacker
infects the computer with malware and changes the DNS settings of the
computer, such that when a DNS query is made, a rogue DNS Server
controlled by the attacker is contacted instead of an authenticated
one. As a result, whenever any URL is typed, the victim computer
ends up sending the DNS query to the DNS Server controlled by the
attacker and a malicious IP address is returned. And thus, the victim
computer ends up visiting a malicious website controlled by the
attacker.

Now, the attacker can spread malware
through the website or steal sensitive data from the user to
perpetrate Phishing attack later.

When Alice will send the email, mail
server of Alice' mail provider will try to find out the IP address of
the mail server of Bob's mail provider.

To do that, the source mail server ask
the DNS Server for the DNS MX Record for the domain destination.com.
An MX Record is a specific form of DNS Record that allows us to know
the IP address of the domain where the email should be sent to.

The DNS Server at this point will
respond with the IP address of the domain destination.com and the
source mail server will send the email using that IP address.

In DNS MX Record Hijacking, the
attacker compromises the DNS Server that is used by the source mail
server. And IP address of a server controlled by the attacker is
returned, instead of that of the domain destination.com.

The source mail server cannot realize
the trick and it ends up sending the email to the attacker's server.

The attacker can now read the email and
steal sensitive information transferred through the email. And, to
make the attack invisible, after stealing the information the
attacker sends the email to the mail server of Bob's mail provider.

How can we safeguard ourselves ?

SMTP STS is a recent technology which can be effectively used to prevent this attack. SMTP STSor SMTPStrict Transport Security is a policy that ensures secure SMTP sessions over TLS. You will find more information on this policy here : SMTP STS

Using DNSSEC or Domain Name
System Security Extension is also one possible option to mitigate this
attack.

In
DNSSEC, responses
from DNS Servers are validated with digital signatures and
cryptographic keys. As it will not be possible for attackers to
duplicate cryptographic keys, it will be very difficult for attackers
to do DNS MX Record Hijacking, thus preventing the attack altogether.