Spike Fuzzer linker errors


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:


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.


Mobile Security


Seems like the pwn2own this time around is going to be putting up prizes of about $100,000+ for people who can find 0-days for a variety of platforms. Especially, the fact that about $60,000 are being devoted for 0-days on the mobile security platform including the android platform etc., indicates a new era of security bugs.
The iPhone (non-jailbroken ones) as well as the BlackBerry application do tend to use signed executables. One only hopes that like the trust-relationships of the SSL-based certificates, the trust is really kept by analyzing the blackberry and iPhone apps.
Tyler Shields from Veracode presented his work of TXSBBSpy (source code URL: http://www.veracode.com/images/txsBBSpy.java; Presentation slides: http://www.veracode.com/images/TylerShields-MonkeyBerries-ShmooCon-2010.pdf).  In this he suggested that when controlled APIs are used the code needs to be signed by RIM but to do that RIM only gets the hash and not the source code.  This presents an interesting situation where RIM could actually be signing something that they don’t really know what it seems to be doing.


New Home


I finally got a new home for my blog.  www.rajatswarup.com will be my new homepage.   In the coming days, I’ll continue blogging while also improving the look & feel of my website.  Any suggestions would be appreciated.


The Next Hope


This was my first hope conference (The Next HOPE Conference)despite being in New York City for more than half a decade. Always it seemed that work would send me out of town just before the con. However, this time around I had the good fortune of being in the city during the conference.
There were a few good talks some of which were not so technical but kindled the questions for privacy fanatics.
The talks I attended included Alessio Pennasilico’s talk about DDoS attack on Bakeca.it, Modern Crimeware and Tools talk by Alexander Heid, Steven Rambam’s talk on Privacy is Dead, Blaze Mouse Cheswick et. al’s talk which was abstract but awesome. I did attend a few more talks and it was fun. All in all a great conference.


Converting Java Key Store into X.509 certificates


Web services security has been very much talked about in the recent times. Especially, with the Service Oriented Architecture (SOA) gaining increasing importance. One of the interesting ways to protect these web services encapsulated in SOAP (Simple Object Access Protocol) is using digital client-side authentication certificates. Programmers typically use Java Key Store (.JKS) files to establish connectivity to these applications. However, if we want to create a custom client using some scripting it creates an issue as we tend to use languages such as perl, bash, etc. to create connectivity. So I ran into this excellent tool called KeyTool IUI. This tool helps you import the Java Key Store (Tools -> Keystore Manager -> JKS Keystore) and export it in the PKCS#12, X.509 PEM, and DER formats. You can further use OpenSSL to change the formats as you please or separate out the components of the certificates.
You could even take these certificates in X.509 or PFX formats and convert into JCEKS, JKS formats! Pretty cool huh? 🙂 Nice software!


WPA2+TKIP on Kubuntu with IPW3945


So I decided to use WPA2 Personal with AES+TKIP on my new Linksys WRT54GL router after my old D-Link router died. However, there were some issues in getting it to work on Kubuntu 6.10 Edgy Eft with my Intel Wireless IPW3945abg.
So I decided to put my /etc/network/interfaces and the /etc/wpa_supplicant.conf files up here for reference:
Suppose BLAH is my ESSID name. The psk value is an altered value for elucidation purposes only:


proto=WPA RSN

The value of the PSK command was obtained by using the value associated with the prefix “psk=…” after issuing the following command:

# wpa_passphrase BLAH passphrase

The /etc/network/interfaces looked like this:

auto lo
iface lo inet loopback

auto eth1
iface eth1 inet dhcp
wpa-conf managed
wpa-driver wext
wpa-ssid BLAH
wpa-ap-scan 2
wpa-proto RSN
wpa-pairwise TKIP
wpa-group TKIP
wpa-key-mgmt WPA-PSK
wpa-psk aaaa3fa7bbbbccccf6d44e199ecb2bebccccad25a0778beeee104db0b3fffff7
pre-up wpa_supplicant -Bw -Dwext -i eth1 -c/etc/wpa_supplicant.conf
post-down killall -q wpa_supplicant

Once I was done with this configuration all I had to do was, issue the following command to get wireless working with WPA2 and TKIP:

# /etc/init.d/networking restart

The case of an ID theft scam


An interesting incident happened this past week to a friend – he had his identity stolen. More specifically, someone got a hold of his social security number (SSN), his date of birth (apparently) and his address. What the scammers or their “mules” (a term used to describe criminals who act on behalf of the actual criminal at their behest) did was that they went to the bank and requested to wire a huge sum of money to an account. The neat trick they played was before actually going to the bank they called the Verizon helpdesk and suspended my friend’s phone service. When they reached the bank and showed the bank agent the ID (some sort of a non-standard / fake ID) and gave the SSN to the bank agent, he/she grew suspicious and tried to contact my friend. However, due to Verizon suspending his phone service, the bank agent couldn’t get a hold of my friend. Luckily, the bank agent also sent my friend an email to which he responded promptly. The culprits were arrested and the investigation is still on.
What was quite interesting was, the modus operandi where the criminals know that banks rely on calling the customers if they suspect fraud and they had this covered. Quite intelligent.
So, you know what you need to do if your phone suddenly stops working – check if ID thieves have had a run on you, change all your passwords including email, change your credit card accounts and bank accounts and PINs and place a hold on your credit history with the credit reporting agencies such as Experian, Equifax and TransUnion.