Basic AWIS (Alexa / Amazon Web Information Services) with Python’s boto

I wanted to use AWIS from Python. It’s surprisingly straight forward. Firstly, make sure you setup your boto config. Here is a simple example of how to create a connection, and run a query:

>>> import boto.connection
>>> conn = boto.connection.AWSQueryConnection(host='awis.amazonaws.com', is_secure=False)
>>> conn.APIVersion='2005-07-11'
>>> response = conn.make_request('UrlInfo', params={'Url':"http://youporn.com", 'ResponseGroup':'TrafficData'})
>>> # response is a httplib.HTTPResponse instance
>>> response.read() #Returns an XML response


Protected: Mental Breakdowns

This post is password protected. To view it please enter your password below:

Password:

Cookie Snarfing

I wrote a simple cookie snarfing attack. The source is available here:
http://bazaar.launchpad.net/~sargun/cookiejack/trunk/annotate/head%3A/ergle2.py. It utilized scapy, PyQt4, and multiprocessing. It enables me to hijack most popular websites over a WiFi hotspot. Right now the code only is there for gmail, mail.yahoo.com, facebook.com, and reddit; extending for other sites should be trivial. It works by looking for cookies, and hijacking them for my own session. A video demo is below:

Monitoring your network, and doing it right

So, at my employer, deCarta, we recently moved from using a Cisco ASA5510 to using Vyatta firewalls. At some point later, I’ll review Vyatta. We did the migration on July 4th, so everything was in a nasty flux. Anyways, because of various reasons, the firewalls implementation was rushed, and that left certain security holes. In most networks, you verify that packets can traverse a particular part of the network. Though, we don’t test our security equipment enough. We often fail to verify that packets are not traversing the network. To look to our programmer brethren, many people are adopting test based development, where you build several unit tests around a particular function, and certain ones are supposed to fail (gracefully), and others are supposed to succeed. The point of checking for graceful failure is to make sure that the application isn’t accepting bad input.

Networks are far more fragile to human error than programs. Programming languages have certain barriers which prevents programmers from making mistakes. On the other hand, most network equipment is made to make ease of use a top priority. This allows someone to accidentally switch around the order of words, or leave out a stanza, opening up a network to attack. We need to verify that our security rules are working, and dropping the proper packets.

There are a few obstacles to this kind of testing. Doing specific SYNs/ACKs between different networks is difficult unless you have some sort of probe sitting in the center of the network, that can touch all portions of it. There are a variety of ways to approach this, which again, I wont cover here. Next, is the more complex part, coming up with the ways to test the rules. You can’t test every possible situation under which the rule should activate, and drop a packet. For example, if you have a rule which says that no system in 192.168.123.0/24 can contact hosts in 10.88.88.0/24, we obviously can’t test every possible combination of this, because that’d be 255^2. Instead, you come up with several different cases under the rules might fail. Firstly, a base case (a very typical one), make sure that 192.168.123.102 cannot send an ICMP request to 10.88.88.101. Next, you come up with a list of typically used numbers, like .100, .254, .1, or any other management hosts you have in your networks. Lastly, think of exceptions to the rule. For example, let’s say 192.168.123.22 is allowed to contact 10.88.88.55. Add these to the probe lists on either side. Now, on either side you have several hosts which you can test between, and that will give you a fairly good idea if your network filtering is active.

192.168.123.0/24 hosts: 192.168.123.55 192.168.123.1 192.168.123.102 192.168.123.254

10.88.88.0/24 hosts: 10.88.88.22 10.88.88.1 10.88.88.102 10.88.88.254

From this you can derive 15 test which should fail to pass packets, and will cover most typical human error. Remember, human error is never typical, so take these as examples, and remember you can never have too many tests to fail.

Anyways, all in all, just remember to make sure that your network is dropping as many packets as it can, and it only takes one packet to compromise your network .

Doom Hack

Doom hack. I’ve gotten PRDoom running on the device. PRDoom is an open source doom clone that uses SDL for its rendering backend. The Palm Pre’s GUI, Luna, utilizes a framebuffer. The SDL backend we used was directfb.

The Palm Pre’s rootfs, based on openembedded, had directfb, but the openembedded repositories did not have any versions of SDL which linked against the directfb provided by palm. The other option was to use fbdev, but I couldn’t get it working, so I moved on quickly. In order to control the rootfs, and libraries, I built a debian rootfs using debootstrap, and was able to install many components not available via ipkg.

Getting directfb working was actually fairly trivial, because palm uses it for their testing. The /etc/event.d/LunaSysMgr file, it had the line: exec /var/mft/usr/bin/ted -m –dfb:no-vt –dfb:no-cursor –dfb:bg-color=00000000 –dfb:pixelformat=ARGB. I was able to dervice the directfb options from there.
Video:

Howto: http://predev.wikidot.com/doom

New Blog

So, I’m starting a new blog. This will primarily be tied to Pre Hacking. I’m with the WebOS Internals team (A bunch of Pre hackers). We have gained root access to the device, as well as been able to manipulate, and modify the OS.

Dev team:
Wiki: http://predev.wikidot.com/
IRC:
Server: IRC.freenode.net
Channel #webos-internals

Me personally:

Old website: http://xbmodder.us
Phone: +1.925.235.1105
Location: San Francisco Bay Area, CA
Name: Sargun Dhillon