I decided to play around with Spike fuzzer and encountered some weird errors during installation. I was using gcc 4.1.2.

gcc -ggdb -o generic_listen_tcp generic_listen_tcp.o dlrpc.o 
dlargs.o spike.o listener.o hdebug.o tcpstuff.o 
spike_dcerpc.o base64.o udpstuff.o spike_oncrpc.o -ldl -L. -ldlrpc
/usr/bin/ld: generic_listen_tcp: hidden symbol `__stack_chk_fail_local' in
/usr/lib/libc_nonshared.a(stack_chk_fail_local.oS) is referenced by DSO
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status
make: *** [generic_listen_tcp] Error 1

If you are also getting the same error, I would recommend that you do the following

SPIKE/SPIKE/src$ ./configure

Now open the Makefile in your favorite editor and edit the CFLAGS line to include the following option:

-fno-stack-protector

This is how my CFLAGS line looks like in the Makefile:

CFLAGS = -Wall -funsigned-char -c -fPIC -ggdb -fno-stack-protector

This should make it build fine (I do get a few warnings but that’s cool…it still does not result in a no-build.

Just started blogging…actually getting pretty late into the blogging culture! Studying and doing projects to complete graduation at USC. My homepage is at http://www-scf.usc.edu/~swarup/.

A simple way to install Backtrack 4 on a USB stick is to use UNetBootin. UNetbootin can be used to create live (i.e., bootable images with a fully functional OS on it) USB images. This is the first time I tried this route and it seems to work alright.
Otherwise, if you are the linux fans, our good old friend dd does a great job.

dd if=bt4-final.iso of=/dev/sda bs=4096 conv=noerror,sync

Having been in application security for more than 2 decades now and officially completing my 18th year now of being meaningfully employed in that space there is just a lot of crud that I have gathered in my brain. Most of that is history of how things came about to be. That stuff is likely not interesting to most but I find it intriguing as to how some seemingly minor decisions of one software vendor can have massive impact to the web application security industry.

Oh the dreaded IE…
Internet Explorer 4, 5 and 6 that started in the Windows XP days (or even earlier, can’t recall) had a setting – the cookie jar was not shared – i.e., if you opened a new window to a site, you would have to log in again unless you used “Ctrl+N” key to open a new window from an existing session. Each new process would have its own cookie jar. For the uninitiated, the “cookie jar” is the internal browser storage of cookies. Cookies are random looking strings that indicate a “trust token” that a web server places in the browser. Since HTTP is a connectionless protocol, this cookie is what preserves the “state” and this is exactly what authorization decisions in HTTP context are typically based on. These cookies are stored in a web browser data storage called cookie jar where each cookie gets stored with the name, value, domain, path (and today, there are few other attributes but that wasn’t the case back in 2004-2005). The browser gets all these parameters from the HTTP response header Set-Cookie. Microsoft, the vendor for Internet Explorer, made a decision that each new window of IE should have its own set of stored cookies that were not shared. Mozilla Firefox and Google Chrome always had a shared cookie jar if I recall correctly.

Along came a Cross-Site Request Forgery (CSRF)…

Jesse Burns from iSecPartners (an NYC-based security consultancy that was acquired by NCC group) back then wrote a paper which I think was the seminal paper on Cross-Site Request Forgery. They called it “XSRF” back then because “XSS” was already in parlance back-then. Thereafter, there were presentations in 2006 about the same by Microsoft. The whole attack was simple. The victim has a browser tab open in which they are logged into a site that has issued that session a cookie value. Due to the browser same-origin policy (a concept that Netscape designed in 1995) that cookie would be resent by the browser in the request as a Cookie HTTP request header whenever an HTTP request was sent to the same domain, protocol (“scheme”) and port. There were few idiosyncracies of IE (which made it infamous back then) such as if the port number did not match IE did not complain and would think that access was allowed per the Same-Origin Policy (SOP). What does that mean? http://example.com and http://example.com:81 would be treated as the same origin! Weird right? It wasn’t the case with other browsers. This was also documented in Michal Zalewski’s book Tangled Web in 2011. Where am I going with this? So while IE did some weird things, it did one good thing – isolate cookie jars. So if you opened up a new window where the attacker ran a payload that sent a request to the site which had handed you a cookie, the new IE window would have no interesting cookies to share with that site – inadvertently protecting the user from being a victim to a CSRF issue. Yes, the hated IE protected the users from being victim to CSRF! Who would have thought? That’s how weird 2005 was 🙂

Fast forward…

Since all browser vendor today have concept of shared cookie jars because who doesn’t like opening new tabs of their favorite cloud consoles without having to re-login right? So what did we the people do? We came up with another attribute that could be added to a Set-Cookie HTTP response header – SameSite attribute which restricted the cookie from being sent unless the request originated from a page on the same site as the cookie issuer.

So there you have it… the history of SameSite and how one of the most hated browsers of the day (IE) did one good thing for users – protect them from CSRF! 🙂

Silsilay, the latest movie by Khalid Mohammed, a critic famous for his Sunday Times articles, is a disaster to say the least. Mr.Mohammed, who has torn apart most of the movies in his journalism career, to my disappointment, has not proven himself any better than the pack he tore apart. I think if he himself saw the movie impartially he probably would have given it negative five stars.
Silsilay, as the movie is called, is a movie of three stories running one after the other albeit aimlessly. The first story is of a film actress (Bhoomika Chawla) who falls in love with a bookie (Rahul Bose) who is two-timing his girl-friend, who in turn is two-timing him…sounds complex…don’t bother…it’s not complex but just kiwi drainex!
The second story is of a young girl (Riya Sen) who looks stunning in the movie and is afraid to lose her virginity and is consoled by her overly promiscuous friend to do *it*. Ashmit Patel steps into the story as her boy toy (read “snuggies”) and Jimmy Shergill, who is her co-worker from work and is looking to gain her attention. Some good (aimless) smooches result between Ashmit and Riya and Khalid Mohammed succeeds in spinning a story that is as ridiculous as Riya and Ashmit’s acting. For god’s sake Riya, Nirma soap advertisements were better!
As if the torture was not enough, Mr.Mohammed had a life-saver (or at least as he thought) a still more ridiculous story. Well, some B-grade films would have called this 3rd story a *saga*…but I frankly think that Khalid Mohammed doesn’t think!
It’s a combination of a love triangle…sorry…love quadrilateral with a diagonal (please figure out what this means on your own…watching the movie wouldn’t help anyway). In this story Tabu plays a housewife whose husband (KK) is going out with a (super hot) air hostess (Celina Jaitley) and whose son suffers from Oedipus Complex ( where a person falls in love with his own mother). As if this carcass did not stink the theatres…there was more bull**** coming across in the form of Shah Rukh Khan in between stories and scenes. Mr. Khan there are many ways to win Filmfare awards…this is probably the last way to *buy* the awards. Mr.Khan does a saving act by signalling to the audience how he behaves when nature calls arrive…how he insanely goes about dancing for no reason whatsoever.
This is all a part of the crap that I call Silsilay!
-Rajat.
Awesome Japanese Artifacts!

In the past few days, coincidentally I’ve been thrown into situations where packet forgery has been required. So I thought it’ll be a great moment to enumerate some good options that network or security professionals have. The basis for most of these tools lies in libnet and libpcap which are some of the most wonderfully functional libraries out there.

• Packetforge-ng – On the wireless side this utility allows you to capture wireless packets and create legitimate packets with a pre-determined payload that can then be replayed using tools such as aireplay-ng
• Scapy – This is a python based tool and can be extended to write custom Python scripts to custom create packets. This library has great functions to form packets layer-by-layer and other functions such as fuzz() that allow fuzzing of packets out of the box. The greatest utility comes by the use of python language to create custom tools. Imagine creating custom thick clients just by using simple python scripts. The capabilities with this library are endless!
• TCPReplay – Just convert your pcaps into traffic by replaying them. An excellent tool but be careful if you’ve sniffed some ARP packets. You could end up corrupting the ARP table entries (unless that’s exactly what your intentions is 😉
• file2air – An excellent tool by Joshua Wright to replay packet contents.
• Packit – A really easy to use and functional linux based packet injection tool.

I have a Dell Inspiron 700m. I have Kubuntu Breezy Badger 5.10 on this box.
This is how I got the WiFi going on this beauty.
1. Boot up into windows and get the Intel Driver from Intels 1st site OR Intels 2nd site

2. Save the files into a location on the drive which is accessible through linux.

root@trance:/home/trance# ls -al /media/hda1/intel/wireless_9.0.4_generic_109116/Drivers/
total 8680
dr-x—— 1 root root 4096 2006-05-14 05:42 .
dr-x—— 1 root root 4096 2006-05-14 05:42 ..
-r——– 1 root root 188416 2005-12-27 23:53 SetupWLD.EXE
-r——– 1 root root 4849 2005-01-25 15:17 SetupWLD.ini
-r——– 1 root root 13 2006-02-02 12:38 verfile.tic
-r——– 1 root root 1671168 2006-01-27 08:50 W29MLRES.DLL
-r——– 1 root root 2956544 2006-01-17 21:34 w29n50.sys
-r——– 1 root root 14821 2006-02-02 00:47 w29n51.cat
-r——– 1 root root 119785 2006-01-18 15:47 w29n51.INF
-r——– 1 root root 3325312 2006-01-17 21:32 w29n51.sys
-r——– 1 root root 466944 2006-01-27 08:49 W29NCPA.DLL
-r——– 1 root root 122880 2005-12-27 23:53 WLDMLRES.DLL
root@trance:/home/trance#

3. Go back into Kubuntu and get the ndiwrapper-utils, ndisgtk, ndiswrapper-source using

root@trance:/home/trance# sudo apt-get install ndiswrapper ndisgtk ndiswrapper-source

4. As root ndiswrapper -i will use the windows inf file to install the wireless driver. ndiswrapper -l lists the driver installed.
example:

root@trance:/home/trance# ndiswrapper -i /media/hda1/intel/wireless_9.0.4_generic_109116/Drivers/w29n51.INF
root@trance:/home/trance# ndiswrapper -l
Installed ndis drivers:
w29n51 driver present, hardware present
root@trance:/home/trance#

5. modprobe ndiswrapper checks if the ndiswrapper kernel module is installed. An installed module will result in no error. Then write the config file such that you do not need to go through the earlier steps every time you restart the system.

root@trance:/home/trance# modprobe ndiswrapper
root@trance:/home/trance# ndiswrapper -m
Adding “alias wlan0 ndiswrapper” to /etc/modprobe.d/ndiswrapper

6. If some error occurs check the output of lsmod

root@trance:/home/trance# lsmod | grep ndiswrapper

7. Now that your ndiswrapper is installed and configured. We now need to start up the wireless interface. On my box the wireless interface used to show up as eth0, however, it was not configured to use the ndiswrapper so I would get ‘segmentation fault’ on doing ifup eth0.
However, with the drivers set, I checked if all was well.

root@trance:/home/trance# iwconfig
lo no wireless extensions.

eth1 no wireless extensions.

eth0 IEEE 802.11g ESSID:”MySSID”
Mode:Managed Frequency:2.437 GHz Access Point: 00:13:46:46:78:28
Bit Rate=54 Mb/s Tx-Power=20 dBm
Retry limit:7 RTS thr:off Fragment thr:off
Encryption key:XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XX Security mode:open
Power Management:off
Link Quality=97/100 Signal level=-27 dBm Noise level=-89 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0

sit0 no wireless extensions.
root@trance:/home/trance# ifconfig
eth0 Link encap:Ethernet HWaddr 00:13:CE:D9:0D:74
inet6 addr: fe80::213:ceff:fed9:d74/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:48 errors:0 dropped:0 overruns:0 frame:0
TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:236683 (231.1 KiB) TX bytes:1104 (1.0 KiB)
Interrupt:10 Base address:0x8000 Memory:e0206000-e0206fff

eth1 Link encap:Ethernet HWaddr 00:12:3F:6B:36:2F
inet addr:192.168.0.109 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::212:3fff:fe6b:362f/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3050 errors:0 dropped:0 overruns:0 frame:0
TX packets:1534 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3117901 (2.9 MiB) TX bytes:159050 (155.3 KiB)
Interrupt:10

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:33 errors:0 dropped:0 overruns:0 frame:0
TX packets:33 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:2058 (2.0 KiB) TX bytes:2058 (2.0 KiB)

root@trance:/home/trance# ifup eth0
There is already a pid file /var/run/dhclient.eth0.pid with pid 0
Internet Systems Consortium DHCP Client V3.0.2
Copyright 2004 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/products/DHCP

sit0: unknown hardware address type 776
sit0: unknown hardware address type 776
Listening on LPF/eth0/00:13:ce:d9:0d:74
Sending on LPF/eth0/00:13:ce:d9:0d:74
Sending on Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3
ip length 328 disagrees with bytes received 332.
accepting packet with data after udp payload.
DHCPOFFER from 192.168.0.1
DHCPREQUEST on eth0 to 255.255.255.255 port 67
ip length 328 disagrees with bytes received 332.
accepting packet with data after udp payload.
DHCPACK from 192.168.0.1
bound to 192.168.0.101 — renewal in 241302 seconds.
root@trance:/home/trance# ifdown eth1
There is already a pid file /var/run/dhclient.eth1.pid with pid 6390
killed old client process, removed PID file
Internet Systems Consortium DHCP Client V3.0.2
Copyright 2004 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/products/DHCP

sit0: unknown hardware address type 776
sit0: unknown hardware address type 776
Listening on LPF/eth1/00:12:3f:6b:36:2f
Sending on LPF/eth1/00:12:3f:6b:36:2f
Sending on Socket/fallback
DHCPRELEASE on eth1 to 192.168.0.1 port 67
root@trance:/home/trance# ping www.google.com
PING www.l.google.com (64.233.161.99) 56(84) bytes of data.
64 bytes from 64.233.161.99: icmp_seq=1 ttl=233 time=73.5 ms
64 bytes from 64.233.161.99: icmp_seq=2 ttl=233 time=51.6 ms

— www.l.google.com ping statistics —
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 51.688/62.634/73.580/10.946 ms

8. To make sure that you don’t have to type iwconfig essid key every time you log on. Change you /etc/network/interfaces file to have these few lines at the end of the file. wireless essid is your wireless network name (SSID) and the key is the WEP key.

iface eth0 inet dhcp
wireless-essid XXXXXXX
wireless-key XXXXXXXXXXXXXXXXX

My /etc/network/interfaces of Ubuntu (in FC/RHL this is the counterpart of the /etc/sysconfig/network-scripts/ifcfg-ethX)
looks like:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# This is a list of hotpluggable network interfaces.
# They will be activated automatically by the hotplug subsystem.
mapping hotplug
script grep
map eth1

# The primary network interface
auto eth1
iface eth1 inet dhcp

auto eth0
allow-hotplug eth0
iface eth0 inet dhcp
wireless-essid USC-Trojans
wireless-key # This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# This is a list of hotpluggable network interfaces.
# They will be activated automatically by the hotplug subsystem.
mapping hotplug
script grep
map eth1

# The primary network interface
auto eth1
iface eth1 inet dhcp

auto eth0
allow-hotplug eth0
iface eth0 inet dhcp
wireless-essid USC-Trojans
wireless-key 11111111111111111111111111