What is Evil Twin in Wireless Networks ?

If not redirected, please click here https://www.thesecuritybuddy.com/phishing/how-to-prevent-evil-twin-attack/

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.

What is a XPath Injection Attack ?

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

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.

To give an example, let's consider this XML document :

<?xml version="1.0" encoding="UTF-8"?>

<bookstore>

<book category="PROGRAMMING">
<title lang="en">Learn Programming</title>
<author>Adam Smith</author>
<year>2050</year>
<price>50.00</price>
</book>

</bookstore>

In a modern browser, you can load the XML document using :

var xmlhttprequest=new XMLHttpRequest()

And, the following XPath query will select the title of the book from the XML document :

xpath="/bookstore/book/title";

xmlDoc.evaluate(xpath, xmlDoc, null, XPathResult.ANY_TYPE, null);

What is XPath Injection Attack

Let's understand this with an example.

Suppose, we have an authentication system on a webpage which takes inputs of username and password from the user and uses XPath to look up the following XML document to find out the proper user.

<?xml version="1.0" encoding="utf-8"?>

<Users>

<User ID=”1”>

<FirstName>John</FirstName>

<LastName>Baker</LastName>

<UserName>JBaker</UserName>

<Password>SecretForJohn</Password>
<Type>Admin</Type>

</User>

<User ID=”2”>

<FirstName>Arnold</FirstName>

<LastName>Cook</LastName>

<UserName>ACook</UserName>

<Password>SecretForArnold</Password>
<Type>User</Type>

</User>

</Users>

Let's consider it uses the following XPath to look for the user :

FindUserXPath = "//User[UserName/text()='" & Request("Username") & "' and Password/text()='" & Request("Password") & "']"

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.

Mitigation

• Use a parameterized XPath interface whenever possible.
• Construct the XPath query dynamically and escape the user inputs properly.
• 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.

What is a Server Side Include Injection Attack or SSI Injection Attack ?

If not redirected, please click here https://www.thesecuritybuddy.com/vulnerabilities/what-is-ssi-injection-attack-or-server-side-includes-injection-attack/

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.shtml


If 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.

Blind SQL Injection Attack

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

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.

DNS Hijacking Attack in Email Transport

If not redirected, please click here https://www.thesecuritybuddy.com/email-security/dns-hijacking-attack-in-email-transport/

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.

You can find more information on DNS Hijacking in DNS Hijacking.

How can attackers perpetrate DNS Hijacking Attack to steal sensitive data transferred over emails ?

Let's understand first, how emails are transported from one mail server to another mail server.

Suppose, Alice with email address alice@source.com wants to send an email to Bob, who has the email address bob@destination.com.

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 STS or SMTP Strict 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.





Read More

Infographic : How to sign and encrypt emails using PGP ?

What is PGP or Pretty Good Privacy ?

How are S/MIME and PGP different from each other in encrypting emails ?

How can Bitmessage be used to send encrypted messages ?

What is SMTP Strict Transport Security ? 

How can attackers perpetrate TLS Downgrade Attack to steal sensitive data transferred over emails ?