All posts by dmitryc

New tool for your toolbox

Actually, the title of this blog is a bit misleading.  It should read “a new toolbox for your toolbox collection” 🙂

If you’ve ever done a web app pen test, you know that it gets messy really quick.  Add in source code auditing, screen shots, movie shots, reporting, etc. etc. and you end up with tons and tons of tools running, large folders of data, and a headache when it comes time to put all this data into a presentable format.

Dinis Cruz is hoping to relieve some of this headache with his new OWASP O2 platform.  This single interface ties together source code auditing, some penetration testing tools, integration with 3rd party scanners (in the future), windows productivity tools, movie editor, and a whole lot more.

I installed it and have been playing with it.  As with any toolbox, there will always be things you would like to see, but this beta release (1.2) has a ton of features and hooks for many more.

So, go and try it!  You can get the code from http://www.o2platform.com/wiki/O2_Release/v1.1_Beta

!Dmitry

dmitry.chan@gmail.com

More email fun

I love parsing public data.  I blogged about it here http://blogs.securiteam.com/index.php/archives/328  about 4 years ago (wow, how time flies)

Now, there is a new set of email data from Supreme Court Justice nominee Elena Kagan which the Sunlight Foundation folks put into a nice gmail interface here: http://elenasinbox.com/

Unfortunately, the dump from the archives looks to be in PDF format.  I’m hoping there is a way to get the plain text dump of these emails.  I’ve contacted the Sunlight guys and hope to get a chance to run some parsing algorithms shortly 😉

Update: Tom Lee and Jake Brewer quickly responded and shared their methodology with me (thanks guys!)…I’m downloading now and will be parsing shortly 😉

Last update:  After getting everything converted over to text, I ran a series of checks for different things like checking/saving accounts, ssn, credit card, pr0n, etc.  The only hits were a password to a non-existent site and some pr0n hits in the received box.  All in all, very tame stuff.
!Dmitry

dmitry.chan@gmail.com

network scanners and flash

So, obviously, network and application scanners are targeting flash ‘.swf’ (swiff) files.  These scanners decompile and then do static analysis on the code.  Very cool stuff.  There are several that I know of that are handling swiff code in this manner.

1) SWFScan  (sorry for linking to a forum search, but there is no nice clean URI for this product)

2) Ratproxy which uses  Flare

If I had the time, I’d like to see how these automated scanners handle malformed swiff files (hack-a-hack attacks).

A quick question for those more familiar with flash security tools: is there an open source lib for decompiling flash swiff files?  Comment here or shoot me an email at dmitry.chan@gmail.com

Peace,

!Dmitry

Kiosk security

Regarding http://blogs.securiteam.com/index.php/archives/1165 , I won’t be able to do daily posts…I’m just way too busy for that…

A few months back, I was sent a 4-foot tall, 80 pound kiosk in the mail.  I had 32 hours (one weekend) to figure out how to break the software.  It only took a few hours, so I thought I’d put together a list of Kiosk 101 security bullets.

1) Encrypt *all* of the traffic.  If you’re not using certificates, it is downright trivial to modify a DNS server (or write a quick MITM proxy) to point your web/xml client to some other web site.  Plus, do you really want your clients order, warranty information, address, phone number, best time to contact, etc passed in plain text over the web?

2)  Do not trust the store network.  Assume that someone malicious can both read AND write data on the store network.

3) Port scan or do a netstat on the kiosk OS to ensure that your kiosk isn’t set up with a service that binds a socket that you haven’t thought to ACL.  I thought it unusual to find 6 open TCP ports on a secured kiosk device.  For that matter, how about just blocking everything except the ports that you need?

4) disable broadcast services, especially ones that tell the passive listener the OS, system name, etc.

5) there is more at risk than just the kiosk.  Consider the attacker who figures out how the client protocol works and then uses this information to spoof a malicious client and attack the server.

6) disabling the cache on the local system isn’t the same as always storing confidential data securely (in transit and at rest).  Assume that the attacker can figure out your “magic key strokes” (maybe by recording a technician servicing the machine??????) and get local access.

7) This will be a service nightmare, but the devices shouldn’t be configured with the same accounts and passwords.  If you break one kiosk, you shouldn’t be given the keys to all of the same kiosks.

!Dmitry