November 15, 2009

In my boredom as of late I'm finding myself searching through Twitter's public wall to see what sort of "juicy" information I can find. Not surprisingly, people are openly sharing all sorts of information that I would consider to be "private."

I've seen user statuses that include information ranging from cell phone numbers to their mother's maiden name. I'm pretty sure that "What is my mother's maiden name?" is still a commonly used security question for various websites. As for publicly sharing your cell phone number, I hear "SMS Bombing" is a fairly common attack nowadays...

Here are some of my search queries thus far (If I come up with any other decent ones, I'll add them here):

"text me at"

"call me at"

"maiden name" + "first pet"

"won't be home"

"won't be home" + "til"

November 2, 2009

NetLibrary is a web site that allows for access to a large digital library of books that can be viewed from the comfort of your own web browser. The library at the college I attend has a membership with NetLibrary, allowing students to be able to access a wide variety of books in order to aid with research papers and the like. In order to access this site through the college's account, you must log into it from an IP address that is associated with the college. Thankfully, the college library has set up a proxy server that allows students to log into NetLibrary from home. [The proxy server clearly deserves some dedicated research of its own...]

Out of boredom, I decided to see what sort of books I could access on NetLibrary. Naturally, I did a search for "hack" and surprisingly got a large number of results. Results ranging from Johnny Long's Google Hacking books to some on cyber terrorism. I just had to read some of the books I found.

While viewing some of these books, I noticed that every time I clicked to go to the next page, a PDF file was being loaded into my browser. Were these PDF files actually being downloaded onto my computer and then loaded into my browser? A quick look into my Temporary Internet Files directory showed me just what I wanted, PDF files galore. Could it be possible for someone to get free ebooks from a college resource? No way!

One problem existed though, every page in a book loads as its own PDF file. This means that a 200 page book will result in 200 PDF files (bummer). After some Googling around, I found just what I needed: PDF Split and Merge. I had to test this out.

After loading, and then saving, 300-something PDF files (Yikes!), I managed to have every page in the book I chose. I fired up PDFSAM and loaded every single PDF file into it and clicked to merge them all into one file. I wasn't certain at all if PDFSAM would be able to handle so many PDF files at once, did. Success! With only some good old time and effort, I now had a complete ebook.

Note: This blog post does not encourage the reader to commit piracy. This research was done for purely academic reasons. DO NOT follow what was listed here in order to obtain ebooks.

September 26, 2009

Off and on I've been working on a USB ran application similar in idea to the USB Switchblades found over at Hak5. My main problem is that I never had a set goal of what exactly it was that I wanted the application to do. This caused me to scrap the project multiple times and begin anew. Each of these new attempts also failed due to a lack of an overall goal.

Today, after thinking it over significantly, I came up with four levels of attack that an attacker would likely use on a local system. These four levels are:

1. Privilege Escalation
Before an attacker can do much of anything (install applications, copy certain files, etc), they must first obtain a higher level of access to the system.

2. Obtain Local Information
This is the most common attack done from a USB drive. The idea is to gather system data and copy it over to a folder on the USB drive. The data that is gathered typically includes browser history, passwords, system info, wifi keys, LSA secrets, and so on. With this data, an attacker is able to compromise more than just the local system.

3. Compromise & Control the Local System
With this attack level, an attacker installs a backdoor into the system, installs the ever so popular USB Hacksaw, turns the system into a zombie node on an elaborate botnet, or whatever their black hearts desire to do. Essentially, the attacker now has some level of control over the system even after they leave.

4. Prepare for Network Ownage
In this level, an attacker gathers data that can help them to compromise other computers on the network. This is done by scanning the network for nodes, port scanning these nodes, capturing packets, etc. With this information the attacker will have an idea of how the network is set up, which they may use later in compromising other systems.

With this four attack levels in mind, I think that I will continue work on this USB tool by implementing all four levels into it. Maybe with at least this basic idea, I won't scrap the project again.

August 22, 2009

I stumbled across an interesting contest today, and just had to give it a shot. There's just one catch though, I have never tried to extract data from a PCAP file before. In fact, I really didn't even know that it could be done...although I'm not surprised. Anyway, here is how I extracted the complete document that was transferred from Ann's computer to the rogue laptop. You did read the puzzle's scenario, right?

Bear in mind that as this was my first attempt to do something like this, I went through quite a few failures before I did the following. Despite my problems, I had fun and am glad I kept at it.

The first thing to do was download the PCAP file and open it up in Wireshark. Once the file was opened, I set Wireshark to show only the packets sent from Ann's computer by setting the following filter:
ip.src ==
From the scenario, I knew that Ann sent some sort of file to the rogue laptop, and that more than likely it was done through an IM client. The previous image shows that "aol" is listed in the info for all of the packets going to the address I don't know much about AOL, but I do know that they have an instant messenger that is quite popular. Knowing this, I decided to look at these packets and see what could be found.

The first thing I noticed in the packet was "Cool FileXfer." Things started looking really interesting. So that I could see all of the traffic sent from Ann's computer to this address, I chose to follow the TCP Stream of the conversation.

It all looked like a bunch of gibberish, but one thing really caught my attention..."recipe.docx." Maybe this was the file I was after. I decided to give it a shot and chose to save the stream. To save it, I selected Raw, clicked Save As, and saved the stream as recipe.docx.

Trying to open the file in Word proved unsuccessful, as there was an error with it. Still certain that this contained the file I was after, I decided to do a little hex editing. Not wanting to mess things up, I opened up Word and created my own DOCX file to serve as a baseline for my editing.

Looking at my test file, I noticed that its header had a hex value of:
50 4B 03 04 14 00 06 00 08 00 00 00 21 00 DD FC 95 37 66 01 00 00 20 05 00 00 13 00 08 02 5B 43 6F 6E 74 65 6E 74 5F 54 79 70 65 73 5D 2E 78 6D 6C 20 A2 04 02 28 A0 00 02
The corrupted Recipe document had the same hex value, but there was unnecessary bits preceding it. I decided to do some hex editing and remove the unnecessary bits from the Recipe document. After hex editing, I saved the Recipe file and opened it in Word. I still got a warning about the file, but I chose to try and open it anyways.

Bingo! There was the secret recipe I was looking for. I had actually managed to extract all of this from a simple packet capture. Wicked!

What? You want to know the recipe? Well...go get your hex editing on like I did.

August 16, 2009

Back in April of this year I made a startling discovery regarding a certain web site that I was required to use for one of my college classes. This web site was not using SSL on its login page.

For those who don't understand how SSL works, here's a partially summarized explanation:
SSL (Secure Sockets Layer) is a protocol that was designed to transmit data securely across the Internet. Data transfered across an SSL connection is encrypted using a public key. TLS (Transport Layer Security), an extension of SSL, is a protocol designed to provide privacy and data integrity between devices communicating across the Internet. Together, these two protocols are known as SSL/TLS.

There are two layers that make up SSL/TLS, the TLS Handshake Protocol and the TLS Record Protocol. The TLS Handshake Protocol is where the authentication between the server and client takes place, as well as the negotiation of the encryption that will be used during the communication. The TLS Record Protocol ensures privacy during communication by using data encryption.

SSL is used to secure web communications by way of HTTPS (Hypertext Transport Protocol over Secure Sockets Layer). This differs from HTTP in that data is sent over SSL/TLS, and is therefore encrypted. HTTP, on the other hand, sends data as plain text.

Knowing all if this, the problems with the discovery that I made start to become clear. With users submitting their login information over HTTP and not HTTPS they were unknowingly transmitting their usernames and passwords to the site as plain text.

This was big a problem.

With data transferring insecurely, an attacker on the same network as the user could run a packet capturing application to obtain the user's login information to this particular web site. The security problems start to really add up when it is taken into account that many users still use the same login credentials across multiple web sites. With this in mind, the security flaw with this one site can potentially compromise multiple web site accounts owned by a user.

Eventually, I had one of my IT instructors notify the web site's administration about this flaw so that they could fix it. Four months later and this is what can be seen in the packets sent to the web site.

It has yet to be fixed.

August 10, 2009

Fired up NetStumbler today while in town. Managed to scan a total of 36 access points during my short trip. Of the 36 access points, 24 were using encryption. Can you guess what type of encryption they all used? Yeah, they were all using WEP. Of those 24 access points that used WEP, 13 were using default SSIDs.

I'm seeing more and more people setting up their APs with WEP as of late. I guess I should be happy that they're actually trying to secure themselves, but I'd really like to see some SSID cloaking. Better yet, some WPA encryption going on.

Nonetheless, driving around with NetStumbler running is always fun. I get to see how popular WiFi is becoming in these rural towns, plus I get to see some very unique SSIDs from time to time.

July 20, 2009

I suppose this is where most "bloggers" would post about how this is their new blog and they're so excited to have one. Well, I'm not gonna do any of that. This is indeed a blog, and it is new to me, but I'm not going to get all giddy and excited like many people would.

Will I use this blog? Yeah, probably. It'll give me something to do. Heck, maybe one out of the billions of Internet users will frequent this site enough for me to consider having a "user base." Bah, I have begun to ramble...
Subscribe to RSS Feed Follow me on Twitter!