Translate page Now !!

Wednesday, 22 May 2013

A Basic Guide to understand Cross Site Hacking ( XSS)

Every day we listen that website is vulnerable to XSS or Cross Site Scripting because hackers are constantly targeting websites using this vulnerability. Even the Top Tech Web sites are vulnerable to XSS. So question comes to mind What is XSS? What can be its disadvantages? We will try to answer these question in todays post. Some top Web sites offer Bug Bounty Program to prevent from these kinds of Bugs. As this is a basic guide, We will just give introduction of XSS, Its Types, How it can be used in Attack and some of its examples with code.

Cross Site Scripting (also known as XSS or CSS) is generally believed to be one of the most common application layer hacking techniques. It is the 3rd Vulnerability listed in Top 10 Owasp Vulnerability 2013.

Cross-site scripting is a hacking technique that leverages vulnerabilities in the code of a web application to allow an attacker to send malicious content from an end-user and collect some type of data from the victim.When an attacker introduces a malicious script to a dynamic form submitted by the user, a cross-site scripting (XSS) attack then occurs. An XSS attack leads to undesirable effects. For example, the attacker gains the ability to capture the session information, peer into private user details such as ID, passwords, credit card information, home address and telephone number, social security/tax IDs, and so on. If the targeted Web site doesn’t check for this type of malicious code, misuse of the user is probable.

Types of XSS:

XSS attacks generally categorized into two categories:

Stored XSS ( Persistent):
Reflected XSS ( Non Persistent ):
There is a third type of XSS attack called DOM Based XSS which is not very well known.

Stored XSS:
Stored XSS also called Persistent XSS. Stored XSS attack is the most dangerous types of XSS Attack. Stored attacks are those where the injected(malicious) code is not properly filtered & permanently stored on the target servers, such as in a database, in a message forum, visitor log, comment field, etc. The victim then retrieves the malicious script from the server when it requests the stored information. Since this vulnerability typically involves at least two requests to the application, this may also call Second-order XSS.

Stored XSS can be used to conduct a number of browser-based attacks including:
  • Hijacking another user’s browser
  • Capturing sensitive information viewed by application users
  • Pseudo defacement of the application
  • Directed delivery of browser-based exploits
  • Other malicious activities

Reflected XSS:
Reflected XSS ( also known as Non-Persistent XSS) vulnerability is by far the most common type. Reflected attacks are those where the injected code is reflected off the web server, such as in an error message, search result, or any other response that includes some or all of the input sent to the server as part of the request. Reflected attacks are delivered to victims via another route, such as in an e-mail message, or on some other web server. When a user is tricked into clicking on a malicious link or submitting a specially crafted form, the injected code travels to the vulnerable web server, which reflects the attack back to the user’s browser. The browser then executes the code because it came from a “trusted” server.

Some examples of XSS with currently focus on the tags that can be vulnerable to XSS.

The <SCRIPT> tag is the most popular way and sometimes easiest to detect. It can arrive to your page in the following forms:


The <BODY> tag can contain an embedded script by using the ONLOAD event, as shown below:
<BODY ONLOAD=alert(“XSS”)>


Some browsers will execute a script when found in the <IMG> tag as shown here:
<IMG SRC=”javascript:alert(‘XSS’);”>

There are some variations of this that work in some browsers:
<IMG DYNSRC=”javascript:alert(‘XSS’)”><IMG LOWSRC=”javascript:alert(‘XSS’)”>


If the TYPE attribute of the< INPUT> tag is set to “IMAGE”, it can be manipulated to embed a script:
<INPUT TYPE=”IMAGE” SRC=”javascript:alert(‘XSS’);”>

The <LINK> tag, which is often used to link to external style sheets could contain a script:
<LINK REL=”stylesheet” HREF=”javascript:alert(‘XSS’);”>

Sunday, 5 May 2013

DNS Poisoning Attack

First to understand DNS Poisoning we first must have an understanding on how DNS works. DNS stands for Domain Name System; it’s used to resolve URL and company name queries on the internet to IP Addresses. So a user types in the DNS sees the query and translates to Then the browser connects you to and all you see in the URL is An authoritative DNS server is assigned to be responsible for their particular domains. Companies have multiple DNS servers to handle the amount of internal queries from their users shown in Figure 1. Now that we have a quick understanding on how DNS works we can now go over the DNS poisoning attack.

dns posioning
(Figure 1)
DNS poisoning is accomplished by the hacker gaining control over the desired authoritative DNS server. The hacker mainly needs to change or add records in the resolver cache so the DNS query from a user or a server can be translated to an IP address that is to be the hacker’s domain instead of the intended domain (Olzak, March 2006). Once the hacker has poisoned the DNS cache, the main risks is identity theft, distribution of malware, dissemination of false information, and man-in-the-middle attacks which will be covered later in this paper (March 2013).

History of DNS Poisoning use in real world attacks

Before one of the largest synchronized fix to the internet’s infrastructure of all time back in 2008 security researcher Dan Kaminsky helped work on the patch. There was a major problem with the current DNS systems. The transaction ID field which is one of the key pieces of information that a hacker needs to successfully poison a company’s DNS cache; the transaction ID field was updated to 16 bits (Dougherty, 2008).
The attack would require at least 32,728 attempts to successfully predict the ID. The previous versions used smaller number of bits for the transaction ID meaning fewer attempts by the hacker (Dougherty, 2008).  With this major security vulnerability over 98% of the internet was affected and just to name a few, “Apple Computer, Inc.Vulnerable 2008-05-05, AT&T Unknown 2008-04-21 Belkin, Inc.Unknown 2008-07-13, and Cisco Systems, Inc. Vulnerable2008-05-01” (Dougherty, 2008).

DNS Poisoning Dissected

Now we are going to take a look in depth on how DNS poisoning works. The first step in the attack is the hacker checks the resolver cache in the workstation to see if a resolution request to the DNS server is there. If there is no entry in the resolver cache then the hacker sends a resolution request to the DNS server (Olzak, March 2006). Now the DNS server receives the request and first checks to see if it’s the authoritative DNS server. If the DNS server is not authoritative the next procedure it will perform is to check its local cache and see if there is an entry for the authoritative DNS server (Olzak, March 2006). Now the server begins the process of interactively querying external DNS servers until it either resolves the domain name or reaches a point where it’s clear the domain entry does not exist (Olzak, March 2006).
The request is sent to internet root servers then the root server returns the address of the authoritative for the .com internet. Another request is then sent from the authoritative for .com and the address of the DNS server authoritative for the company domain is returned ( March 2013).
Another request is sent to the authoritative server for the company. This is the same query process with one exception; the hacker now wants to poison the DNS server’s cache. In order for the hacker to intercept a query and return malicious information, the hacker must know the 16 bit transaction ID (Olzak, March 2006). If the DNS server is running an out of date version of BIND, then the transaction ID becomes very predictable. But in newer DNS systems have built in safe guards, for instance the transaction ID for each query instance is randomized. To slow the response of the real authoritative server, the hacker uses a botnet to begin a DOS (Denial of Service) attack (Olzak, March 2006). Now the authoritative DNS server is trying to deal with the attack, the hackers DNS server has time to figure out the transaction ID. Once the ID is determined a query is sent to the internal DNS server but from the IP address of the hackers server ( March 2013).
The response is placed into the server’s cache, the rogue IP address from the hackers server is returned to the client resolver and any entry is made and a session is initiated with the attackers site. Now any workstation on the internal network requesting resolution to the company’s site will receive the rogue address listed in the DNS server’s cache. Now taking users to the hacker’s fake website so the hacker can steal information and distribute malware to the unsuspecting users ( March 2013). This scenario is depicted in Figure 2 with arbitrary names.

(Figure 2)dns poisoning

Review Risk and Mitigation for DNS Poising

The main risk if a company’s DNS server’s cache gets poisoned is unwanted distribution of malware, user information, identity theft, man in the middle attacks. Also any user on the internet that searches for their website will be redirected to the rogue DNS server resulting further damages. There is a very high risk of malware infections spreading to potentially infect a majority of a company’s computers. If a CEO logged into the rogue DNS server and did not realize it, then the hacker has executive rights to any data in the organization and can steal his identity. Companies need to have DNS; it’s too difficult for everyone to remember the IP address for every domain server and every website on the internet that also uses DNS.
To help mitigate this attack is to use the latest version of DNS. DNS based on BIND 9.8.x is far more secure than previous early versions of DNS. Physically separate external and internal DNS servers, restrict zone transfers to authorized devices, and use TSIG to digitally sign zone transfers and updates, restrict dynamic DNS updates, and hide the version of BIND being used on the DNS server.

Saturday, 4 May 2013

Traces of malware activity detected in App Store game

A suspicious iframe link has been detected in an App Store program. Here's why you shouldn't worry.


MacWorld is reporting that a program on the iOS App Store may be detected as containing malware, but in analysis the program is not considered to be malicious.
After its readers wrote in about the potential of malware in a game called Simply Find It that is available on the iTunes App Store, MacWorld confirmed traces of nonfunctional Trojan horse malware embedded in an MP3 file used by the program, which shows an HTML iframe reference to a potentially malicious (but currently unresponsive) Web page.
This is not the first time that malwarelike activity has been found in programs in the iTunes store. In July 2012, Windows-based malware was found embedded in the iOS store, likely from the developers' systems being exposed to the malware during testing.
This latest finding shows Trojan-like behavior in the program; however, it's really not currently a threat to Mac or iOS users. The malware activity is so far identified by a single HTML string in a file that points to a potentially malicious Web page. The program does not appear to make any use of this string, suggesting the program or this file was simply affected by malware at some time during development, as opposed to containing an active threat.

Is this Apple's fault? In its testing, MacWorld found the program is not flagged by several other anti-malware tools. Apple tests the App Store programs thoroughly to see how they behave when run by consumers, but given that this iframe link is a benign and nonfunctional appendage to the program, it could have been overlooked like any other piece of nonfunctional metadata.
Ultimately, this threat can be more accurately described as a suspicious but nonfunctional embedded link from traces of prior malware activity that might cause some malware-scanning tools to flag the program, but as security expert Rich Mogul mentioned to MacWorld, "A malware link that never runs isn't a threat," so overall iOS users should have nothing to worry about.