Archive for June, 2009

Podcast Episode 3: Convincing Management Security Is Important

Finally got Episode 3 released after I (Micheal) had some technical difficulties. Here’s a shoutout to Securabit!

Show Notes!

Welcome to Georgia’s awesome show notes. Here you will find links to
more information about the things we spoke about in the show.

Defcon (link: www.defcon.org): Very big hacking conference where
Georgia will be on the podcast.
Pauldotcom (link: www.pauldotcom.com): Very good security podcast. We
would like to be invited to their party at Defcon.
Securabit (link: www.securabit.com): Our very first mention on a very
important podcast.
Twitter: (link: www.twitter.com): A very cool place to hang out.
Defense in Depth (link: http://isc.sans.org/diary.html?storyid=6604):
Kevin Liston’s very good article on Defense in depth.
White Wolf Security: (link: www.whitewolfsecurity.com): The very cool
company who put on cyber defense.
???: Where is my very filled with celebrities picture?
White Wolf Security CCDC Pictures: http://www.whitewolfsecurity.com/galleries/ccdc_regional_09.php

How not to pick locks…

On the very first day that Georgia, Rachel, and Micheal envisioned the magnificent entity known as GRM n00bs, we went to the store to pick up a lock with the sole purpose of dismantling it. We also filmed the whole thing.

Super ultra disclaimer: This video shows us learning lock picking as part of our education as information security professionals. We do not promote lock picking for any reason other than to assess the physical security of an enterprise when you have explicit permission to do so. This video was made for entertainment purposes in a private residence with privately owned locks.

GRM n00bs podcast episode 3 is coming your way; we discuss techniques for convincing management of the importance of security practices in an organization. Look out for the trailer of the infamous collegiate cyber defense documentary.

Georgia

The littlest hack station part 2: Persistent Changes and Drivers BT3 EEE

Technically some might argue that is in fact Monday meaning I missed yet another deadline. Things are not looking good for me as a working professional eh? Anyhow as I have not yet been to bed despite the fact that I have my first day on site as a real life professional penetration tester, I claim that it is still Sunday.

There are no screenshots in this tutorial at all, so here’s a fun one for you. This is what moving looks like at my house. Everything I own is still in boxes, but there’s an ad hoc network running off a phone, three computers, and some Arduino stuff going on in the background.

When we left off in Part 1, we had replaced the wireless card with an Atheros based card that is natively supported by Backtrack and successfully booted into Backtrack on an SD card. Now we are going to set up persistent changes in Backtrack, fix all that wonky bit about the graphics on boot, and get the wired network interface setup. Then we should have a fully functional little hack station.

The folder to store the persistent changes needs to be an ext2 file system. It can be on the SD card (if it is big enough) or on the eee harddrive. When I installed Easy Peasy on the harddrive, I kept the partition structure of the origonal Xandros install with a 4gig partition for /home on the remaining 16gig partition. We are going to put our persistent changes here as well.

The harddrive is mounted in /mnt/hdd1 (though the name may be different in each case depending on the labels given to the partitions). For the remainder of the tutorial replace /mnt/hdd1 with the path to the ext2 media you wish to store changes on.

Create the changes directory inside your media of choice:

cd /mnt/hdd1
mkdir changes

Now edit /boot/syslinux/syslinux.cfg with vi because it is better than nano.

Add:

LABEL pchanges_eee
MENU LABEL BT3 eee 901 Persistent
KERNEL /boot/vmlinuz
APPEND vga=785 initrd=/boot/initrd.gz ramdisk_size=6666 root=/dev/ram0 rw changes=/mnt/hdd1/

directly beneath

PROMPT 0
TIMEOUT 40
DEFAULT /boot/vesamenu.c32

at the top of the file.

This also solves the problem of having to manually tell it what graphics resolution to use each time you boot. It will automatically use KDE in VESA mode 1042×768 when we startx.

Reboot and the choice BT3 eee 901 Persistent will appear as the default. We select this option, log in, and startx manually to test that the graphics are working.

Make sure persistent changes are working by creating a file, changing passwords, changing the background image, whatever strikes your fancy. Reboot, and when your changes are still there, you know it’s working.

The Ethernet card in eee 901 is not natively supported by Backtrack 3. So we need to install the drivers manually. In order to compile the drivers we need the source kernel module available from Offensive Security. Copy this file to /BT3/modules on the SD card. You will need to reboot before compiling any drivers to use this file.

The source for the Ethernet driver is available from ASUS. Unzip it with unzip and navigate to /root/LinuxDrivers/L1e_Lan. Use

unrar x l1e-12e-linux-v1.0.0.4.rar

Then navigate into /src. Type

make install

to compile the driver.

Then

insmod /lib/modules/2.6.21.5/kernel/drivers/net/atl1e/atl1e.ko

to insert the module into the kernel. Now upon reboot we have the eth0 interface available when we type ifconfig and wired networking works fine.

Now our little hack station is ready to go.

Well I’m off to nervously await the advent of my time as a real life professional penetration tester which is fast approaching.

Georgia

Guest Tutorial: rooted G1 access point

Having survived my week of orientation to work and gearing up for my first day as an actual penetration tester, I’m already slacking and having other people do my work for me. I haven’t actually done this myself, but I’ll certainly be getting one of those G1’s to fool around with as soon as the pay checks from this real life penetration tester gig start coming. On with the tutorial:

Here are instructions for turning a G1 phone into a rogue wireless AP and sniffing the packets of your victims. Note that the only packets sniffed during the sessions described here belonged to the author.
This is presented purely for educational purposes and so on and so forth amen.

This simple exploit isn’t based on any new ideas, and it uses onlyout of the box materials. But it is entertaining, and as far as I know I thought of it first. It might be that other people who thought of it didn’t think it was even worth mentioning, or it might be that they’re up to something nefarious and don’t want to spill the beans.

Materials needed:

1. A rooted g1 phone with data connection. see http://www.androidfanatic.com for explanations of how to get root access to your g1 phone and links to necessary files. Also see http://forum.xda-developers.com/forumdisplay.php?f=448 for useful instructions and downloads relating to root access. This subject is worthy of any number of tutorials in its own right. There are dozens of community developed ROMS for the phone at this point.

2. A debian installation on your g1. see http://www.androidfanatic.com for instructions and downloads relating to this. our debian disk image is 3.5 GB. Significant space is required for saving captures, so you ought to resize the out-of-the-box image following instructions found on http://www.androidfanatic.com. See also Saurik’s page for information from the originator of the debian-on-g1 hack. The size is limited by the fact that the VFAT filesystem on the sd card has a 4GB limit on file sizes. This may have been addressed in some of the more current ROMS, which may patch the android kernel to allow it to use ext2 and ext3 filesystems. I haven’t had time to look into this yet.

3. A wifi tethering application for your g1. I know of two free ones. The one used in this demo is aNetShare, available from http://android.a0soft.com/aNetShare-v2-30-20090326.apk. the other one is called “wireless tether for root users”. This project has been successfully tested with this app as well. it is available for download at http://code.google.com/p/android-wifi-tether/. The various paid tethering apps are untested.

4. Tshark installed in debian on phone. Use aptitude or whatever you like to do this. Note that tshark is the no-GUI version of the justly famed wireshark.

5. A public place where people might expect to find free wifi.

What to do:

1. Set ssid of tethering app to something appropriate.

1.5 Boot up debian on the phone.

2. Invoke tshark in debian terminal emulator. for full contents of packets
dumped to file use

tshark -V -i rmnet0 > filename-to-dump-to

for summaries of packets use

tshark -i rmnet0 > filename-to-dump-to

I figured out the name of the interface to listen on using ifconfig.

3. There is some art involved in getting files out of the debian filesystem
and making them accessible to android and the phone apps. It can be done,
but this isnt a debian-on-android tutorial. They can be read with less,
more, cat, vi, tshark itself, and so on. if you follow the instructions on
http://www.androidfanatic.com to install an xwindowing implementation over your debian it is even possible to use wireshark to analyze the packet dumps, although it taxes the limited resources of the phone.

4. Exercise: install driftnet in your debian-on-android and use it to capture and reassemble images and music files from the tcp stream through your phone. This turns
out to be quite simple, and often hilarious.

Directions for further research:

1. Dsniff and associated applications.

Finally: use this only for good and not for evil, and have fun! If you find these two
goals to be mutually exclusive, then God help save your mortal soul…

papelarroz@foutu.org

Five days of content has quickly turned into five posts before the end of the weekend. Look out for the second half of setting up backtrack on the Asus eee 901 directly with some foolery with a Madwifi access point to follow as soon as I quit breaking networking on the remote machine.

Georgia

Syslink? Was my wireless access point always called that?

For today’s tidbit we are going to talk about securing your wireless router and a bit on what I thought for about a minute was going to be my first ever vulnerability disclosure…but alas.

From the reactions of my mostly business types work training class when a young finance consultant announced that the router was fine after the teacher had problems connecting to the work VPN, it seems that alot of people including your not too average Joe know all about “admin, admin.” However, judging from how often it works in the wild, alot of system administrators don’t know about “admin, admin.” Hence it seems worth posting about if only because the really good stuff isn’t ready yet and I took these screenshots.

As always we strongly encourage you to only do this on systems you own or have permission to hack, and the usual disclaimers apply. If you just can’t help yourself it may be worth your while to change your mac address as outlined in the previous tutorial Problems in WEP Cracking and How to Fix Them for reasons discussed later in the post.

Once connected to a wireless router find out your ip address on the network with ifconfig, ipconfig, etc depending on your poison of choice. If your ip address is 192.168.x.y there is a good chance there is something like this waiting for you at 192.168.x.1:

Now it is quite possible that the administrator of the router in question may used a password that meets most definitions of complex enough for deployment. Then again it might be admin (or the default credentials for the router model in question). Entering “admin admin” yields this:

And yes you can do alot more than change the SSID in there…

The moral of the story is on top of using good encryption on your wireless, make sure to secure interfaces to the router from users on the network.

Once upon a time Micheal, Rachel, and I were fooling with a linksys, a fairly up to date model that supports all those secure things like wpa2 and mac filtering and that sort of thing. We noticed it was at certain times allowing us to bypass the login screen to the router. Had we stumbled upon a vulnerability in the web interface implementation?

After some analysis it turned out that it was only logging the MAC address on an interface that had logged in with correct credentials allowing that interface to bypass credentials by just navigating to the url of another page within the interface instead of entering credentials founr some amount of time before the router is reset.

While not a vulnerability persay, it is not exactly a security feature. For instance if one happens to notice someone performing administrative tasks on the router over the wireless one might ascertain a good mac address similarly to beating mac filtering.

Not a major vulnerability, but it was a bit of fun and most instructive in the process of accessing vulnerabilities.

Georgia

A Hearse on My Morning Commute

Another gag podcast? This is possibly the most epic fail of my entire career, and it’s only day 2. Perhaps we should do a whole interview series on famous information security names talking about their most embarrassing epic fail moments. For now here’s mine:

Podcast Episode 2 Point Something and a Half

Georgia

Georgia’s first day of work

So we’ve been gone. Now that we are back expect a lot of content. This little monologue is about my first day as a real live penetration tester…sort of.

Download Episode 2 point something

Georgia

Return top