Bluetooth Device Lookup

Post by: Snarky on November 22nd, 2007 | Filed Under Bluetooth, Linux, Perl, Programming, Security

Happy Thanksgiving! I'm spending the break catching back up on the state of Bluetooth security because, hey, I love the subject. Everyone has a phone with Bluetooth, just about, and many overlook it as a security hole because they feel there's nothing insidious that can be done with just replacing wires with some radio broadcasts. I'll give a quick rundown on how to get Bluetooth working under Linux, then the software I use, and finally give a tool I wrote watching the Dallas Game to speed up identification of Bluetooth devices.
Read More »

Comments (No responses yet)

I Can Has Pictures

Post by: Snarky on October 14th, 2007 | Filed Under Perl, Uncategorized

I've been badly addicted to I Can Has Cheezburger for a while now. Like me, those pictures are cute and funny. Unlike those pictures, I know how to grab them all! I finally got fed up with having to click next, and decided "What the hey", I can get all the URLs for the direct images! So I cooked up a quick Perl script that spits out a text file, one line for each image. Of course, once you have the aforementioned file, wget becomes your best friend. I needed a quick script success, and this little tidbit has both provided that, and given me something to do for the rest of the wee--- erm, night.

Comments (4 responses so far)

Software Design Oopsies

Post by: Snarky on June 12th, 2007 | Filed Under Perl, Programming, Stupidity

So, real quick as I just got the idea to actually post this little story, I was writing a little script. This script dealt with ids I'm using for a project. Basically I knew there was a lot to begin with, but wanted a flat file, not a database because I figured "Hey, I'm dealing with a lot, why pay the overhead every id of doing a bunch of queries?" Among other things, this script couldn't list an id more than once. So I (stupidly) chose an array to store the ids and sort through them. At first, no issues, I could process a few ids in a second and get all my work done on them. Well, after I hit around 15,000 I had issues. It was now taking about 5 seconds an id. It only got worse, and worse, and worse. Around 19,000 ids I finally CTRL-C's the script, to retool it. I changed it over to throwing all the ids into a database, accepting a tad more overhead per id, but overall this becomes linear time. I stupidly forgot my Big-O notation classes, and that sorting through a large list of numbers takes longer than a very short one. *sigh*.

Bottom line: For large amounts of data accept the higher overhead per unit when it'll lessen the overall overhead. Now my script runs happily all day without decreasing my speed. I only post so you geeks out there can laugh at me, and I'll remember this handy little lesson later on.

(I feel the need, as I do freelance programming, to point out I'm normally quite smart regarding how I design my code, and I'm posting this because I can't believe I did that!)

Comments (No responses yet)

Plaintext Passwords… Again!

Post by: Snarky on May 25th, 2007 | Filed Under Hacking, Perl, Security

If you follow my blog, and sadly most of my readers have stopped checking, you'll remember the security hole I found on a major website around Valentine's Day. You should also remember I had a very good experience with the developers there, in terms of their competance and politness.

Well, I just tried to log in to that site on an account I haven't used in... well.. a long time, lets leave it at that. Sadly, I'd forgotten my password, and they do a very smart thing in limiting how many failed logings one can have before resetting the password, forcing me to reset my password. Up to this point, everything is working as it should, removing the possibility of brute force attacks with only limited user annoyance every few months.

Then I noticed that... uh-oh... the reset page wasn't SSL. I thought "Oh, don't worry, I'll bet its posted to an SSL domain," but grepping the source proved otherwise. Bugged, I decided to sniff my traffic and see what was happening, and sure enough, my password flew by in plaintext. This time it wasn't anything as stupid as a "Mother's Maiden Name" type question that also requires a little social engineering, this is MY PASSWORD, and MY USERNAME flying by.

Here's a look at a sanitized version of the information in the packet that gives it all away.

Content-Type:application/x-www-form-urlencoded
Content-Length:102
submitok=1
cc=ff6cda68ba7b4c
tt=1180114618
email=****@****.***
newpass1=PLAINTEXT
newpass2=PLAINTEXT

The Impact:
If I have to be sniffing the traffic in order to catch the password, this isn't as effective as, say, just phishing for the credentials, but this attack doesn't require any human stupidity.

However, this again is a very effective attack for large networks. ARP Poisoning is fairly trivial in this day and age, so even on a switched network one can grab these credentials. On a large network such as a dormitory, or campus this attack will work on as many people as are connected to the router you have access to. Worse, combine this with a botnet or other malware on a victim's machine, and it'll work on everyone who logs on to the site on an infected computer.

Another fun trick, as identified by the researchers at Indiana University, is subverting routers. If one subverts a router to modify the firmware, such an attack could easily be set up to happen on all traffic passing through the router, eliminating the need for ARP Poisoning. However, this requires an insecure router to start with, and the target would be a much smaller number.

The Attack:
I'll talk through an attack from a dormitory, as that's the first I thought of. Once you're set up with your ARP Poisoning, its time to get users to reset their password. Get a large list of email addresses from your school (this is very, very easy to script, you should be able to get tons of addresses. Now, you can either exploit the password reset security feature, or simply hit the reset.php page with each email address. Once you've reset the password, sit and sniff the network for any packets going to the page that actually does the resetting. Save all those packets, and you have all the information you need to compromise the accounts of everyone in your dorm!

I happen to know (whipped up a script to prove it) that this can quite easily be done in Perl where you never have to do anything, just sit and watch the logins go by.

The Payoff:
Once you have all the logins, you can either be very malicious and overt, or very subtle and clever. One might immediately hit the account page to change the password to something to lock out the legitimate user, or maybe even delete the account. Or, to be clever, throw all the logins into a database for later exploitation. It'd be smarter to do the second, because then the attack will go unnoticed for a while.

My Actions:
As usual, I'm accompanying this post with an email to the development squad of that website. I'm not releasing the name of the site, will delete any comments that say what site it is, and won't make my exploit code available anywhere. I will speak for the quality of the site's developers, from my last dealings with them, and know this will be fixed before any real attacks can be launched.

Comments (No responses yet)

Quick Users

Post by: Snarky on February 17th, 2007 | Filed Under Perl, Productivity, Programming, Three Planets Software

I don't think I've said it publically yet, so a little heads up, I've gotten my first contract as "Three Planets Software". Rather (I hope) easy site in PHP/MySQL and some other goodness, but you'll hear more about that later when I put out a call for Beta testers. So I coded up all the login and registration pages two days ago, and now am working on some other fun stuff. Some fun stuff that required more than one user to test. Ideally, more than 10. I did *not* want to sit in phpmyadmin creating 20 dummy users that would only be used in testing, so I turned to perl.
Read More »

Comments (No responses yet)