From Security Weekly Wiki
Jump to navigationJump to search



Announcements & Shameless Plugs

Security Weekly - Episode 157 - June 25, 2009


Episode Media


Interview: phishing for pen testing Val Smith

Val's blog



Val Smith has been involved in the computer security community and industry for over ten years. He currently works as a professional security researcher on a variety of problems in the security community. He specializes in penetration testing, reverse engineering and malware research. He works on the Metasploit Project as well as other vulnerability development efforts. Most recently, Val founded Attack Research which is devoted to helping us gain a deep understanding of the mechanics of computer attacks. Previously, Val founded a public, open source malware research project.


  1. On your site it states, "Offensive Computing has the largest malware collection publicly available." Thats just so cool! What can you tell us about the Malware you collect, are the bad guys winning? What is the theme with respects the purpose or intent of the Malware/Malware authors? What are some of the lamest things you've found in the Malware you've collected?
  2. How can organizations best protect themselves from Malware?
  3. For me Tactical Exploitation was one of the best presentations on penetration testing I've ever seen. I am a huge fan of the philosophy, and was so glad to see the concept of targeting data, process, and people be put into the spotlight. In terms of discovery, do you think Maltego is the shit, or is there some shiny new hotness we need you to enlighten us about?
  4. In Tactical Exploitation you talk extensively about MiTM techniques, which ones are still the most effective and how can people defend against them? Also, when you plug into a network or compromise and end user station, how do you know which machines and connection to "middle" if you will?
  5. When doing a penetration test on an internal network of thousands of hosts, how do you determine what the best path is to the sensitive data?
  6. Collecting credentials is such an important part of your assessment, what tools and methods do you use to keep track of which credentials came from which systems, which ones got you into which systems, and which ones have been cracked, and which ones have been re-used the most?


  • Presentation from the SANS PenTest Summit - Metaphish

Tech Segment: Backtrack 4 Pre-Release via SD Card by Larry Pesce

I was excited to be able to use the new pre-release version of Backtrack 4, as I love to use it on my Asus EEE 1000HA. When it was released I was eager to make it work, booting off of an SD card in the EEE so that I would not have to mess with additional USB thumb drives (they stick out of the laptop, and the SD card is internal). During the process, I was happy to discover that both the internal wireless and bluetooth adapters are now supported. The wireless card even appears to support injection!

<img src="http://securityweekly.com//backtrack-4-beta.png" alt="backtrack-4-beta.png" border="0" height="100" />

I'll be tailoring this to use on an SD card, but the steps are exactly the same as a USB thumb drive.

Thank you to the Offensive Security folks who put together this video, as this guide is based on it exactly. I wanted to put it down in text as it isn't always that easy to print out video, or view when you don't have internet access (such as on a plane...), where I initially wanted to accomplish this.

Additionally, this is a signifiant departure from the previous methods for creating a persistent install. This will not work for the BT4 beta versions.

Let's get started.

Two things that you will need:

  1. The Backtrack 4 Pre-release ISO, booted on a machine with an SD card reader
  2. An SD Card 4 gigs or larger (or USB thumb drive 4 gigs or larger) that we can completely wipe. This is a destructive method, as we need to create a few partitions.

After Booting in to BT4, and insert your SD card. Issue the command "dmesg". At the very bottom of the output, we should be able to identify the plug in of our SD card, and the device to which it was assigned. Mine happened to be /dev/sdc, so that's how the rest of the instructions will progress. Replace /dev/sdc with your assignment from the output of dmesg.

Now, as root (the default user for BT4), we need to fdisk our SD Card. BE CAREFUL, as selecting the wrong drive here can potentially hose your system. That's why I like doing this from within a VM. Start fdisk with the appropriate drive:

# fdisk /dev/sdc

Within the fdisk utility, print the existing partition table with "p". If there are existing partitions, delete them with "d", and select the appropriate partition, and repeat until they are all gone. You can reverify by reprinting the partition table with "p".

We now need to create two new partitions with in fdisk. For the first partition enter "n" for a new partition, "p" for primary partiton, "1" for first. Use a size of "+1500M" for 1.5 Gig. For the second partition, "n" for a new partition, "p" for primary partition, 2 for second. You can accept the default for size, or at a minimum of 1.5 Gig with "+1500M"

Activate (set as bootable) the first partition with "a", and select partition 1. Assign a type to partition 1 by issuing "t", select partition 1, and use the code of "b" to identify it as W95 FAT32

Verify the new partition table by issuing a "p" with in fdisk. If all looks OK, write it to disk (and exit) with "w"

Ok, you can breathe again. The dangerous part is done.

In order to use our new partitions, we need to format them. The first partition (/dev/sdc1) will be vfat, and the second (/dev/sdc2) will be ext3. We can format them with the following commands:

# mkfs.vfat -F 32 -n BT4 /dev/sdc1

The mkfs.ext3 command will take some time, so be patient.

Before we can begin copying over the files, we need to mount the forst partition after creating a directory to mount it to. We accomplish that with:

# mkdir /mnt/sdc1
# mount /dev/sdc1 /mnt/sdc1

Copy away! We're going to copy the contents of our current, booted BT4 enviroment to the new partition on the SD card:

# rsync -avh /media/cdrom/ /mnt/sdc1

Again, this one will take some time, so be patient. Also, note that the extra "/" at the end of /media/cdrom/ is important. If you use tab completion to add that directory to the command, it will not be included and the rsync copy will fail.

Let's install the grub bootloader so that the thumbdrive will actually boot, and know where to fund all of the appropriate files:

# grub-install --no-floppy --root-directory=/mnt/sdc1 /dev/sdc

Editing the startup items will make our experience that much better. You can use your favorite text editor here (vi for example), but nano is included on the BT 4 install, so feel free to use that:

# nano /mnt/sdc1/boot/grub/menu.lst 

At the top of the file, change the default boot option to 5 to automatically use the persistent install at boot time if no user interaction is provided. the line should now read as:

default 5

Also, edit the block towards the end of the file with the title of "Start Persistent Live CD". You'll want the kernel line to be updated, and at the at the end add 0x315. This sets the default video mode for boot, and was the highest resolution available on my EEE. For normal installations (such as on non-netbooks), use 0x317. The updated line should be as follows:

/boot/vmlinuz BOOT=casper boot=casper persistent rw quiet vga=0x315 

Exit nano and save the file to the default location (with ctrl x).

We are almost done! Just unmount the SD card ad reboot:

# umount /mnt/sdc1
# init 6

Enjoy your persistent Backtrack 4 installation on an SD card!

Stories For Discussion

  1. Security tools for Windows up for less then a day - [strandjs] - What is this about? Usually when MS commits to something (good or bad) they stick with it. Is it a good idea for Microsoft to get further into the AV business? Could this stem the flow of malware on home computers? We shall see.
  2. DHS killing the self-spying satellite program - [strandjs] - Many of you dont know this, but there are spy satellites flying over the US on a regular basis. Up until recently they are not allowed to capture data over the US. I would love to get the rest of the PDC crew's views on this.
  3. Cyber warfare is B$ - [strandjs] - Looks like the NSA is going to be heading up the US cyber command. How behind, or ahead is the US? There was quite a fight as to who was going to be heading this up. Personally, I think it is a bit of a mixed bag that the NSA is running it. First, they are great at this stuff. On the other hand, they have a tragic tendency to not share with other agencies and organizations.
  4. US cyber security attack range - [strandjs] - I am a bastion of US DoD cyber news today. In reality the development of a cyber test playground is interesting. However, I am a bit afraid that it will be tuned to specific attacks and not reflective of "real-world" situations. That being said, some US adversaries have a Cyber test rage too.... It is the US
  5. Cisco Video Camera DoS - [Larry] - Nice, very Oceans 11, but with some crafted packets, you can DoS video streams. I can think of a number of times where this might be useful. Also, with credentials cameras will disclose any file on the camera.
  6. Where'd that drive go? - [Larry] Looks like a Northrop Grumman hard drive ended up in an e-waste processor in Ghana. The drive was purchased by a reporter for $40, and it contained "hundreds and hundreds of documents about government contracts" that were marked "competitive sensitive", unencrypted, either by file or whole disk. What can we learn here?
  7. I sense a job opening o two - [Larry] - When companies get spanked, and told that they have to get with the program and get audited for the next 20 years, it is likely that these folks will be looking to put together a robust security program.
  8. Nmap digging deep on Windows - [Larry] - A great SANS Gold paper on using some NSE scripts for digging deep on windows.
  9. SlowLoris (and PyLoris) for the win - [Larry] - Aside from the total FAIL that 'Loris introduces, it is possible to have a website all to yourself. I've ben throwing it at everything I can find with a web interface with interesting results (which I'll discuss)
  10. Loose Tweets Sink Fleets - [Larry] - Let's talk about the dangers of social media...
  11. Splunk/LCE Integration - [Paul] - Sorry, there is no link for this one yet, but check http://blog.tenablesecurity.com tomorrow morning for the post. First, I wanted to tell you about the Tweet. I was under the gun a little and needed some help with Splunk. Thank you to all who responded, approximately 7 minutes after I tweeted I was on the phone with Ty from Splunk. He was awesome. Turns out there was a bug in the web interface that was hosing my config. I editing the config files directly and stuff started working. What stuff you ask? Oh, the integration of LCE and Splunk. I won't give you the vendor pitch too hard, butyou really need to analyze your logs. I give an example where you may see a lot of SSH login attempts. But you only care about the successful ones, there are tools out there that can get you this information, so use them! I also thought that Splunk's web interface was cool, it autocompletes when searching and lets you filter just by clicking on stuff. Neat. We're going to bring them on the show for an interview.
  12. PCI Roundtable - Part 1 - The Jericho Interigation - [Paul] - Sorry, there is no link for this one yet either, but check http://securityweekly.com soon. We did another PCI roundtable. The first one can be found here. I think that PCI takes a lot of crap, but after experiencing PCI in many aspects, and doing two roundtables, I think PCI does way more good than harm. Sure, there are problems, politics, and auditors that don't know jack, but at the end of the day a company with no security may actually patch a few things and thats a good thing.
  13. 10 Things Your Auditor Isn't Telling You - [Paul] - Dave takes some time to point out the security FAIL that is auditing. I will play both sides, you're not totally safe just from having a pen test either. Here's the thing, auditing is going to miss things that a pen test is going to find, and pen testing is going to miss things that an audit will find. Example, auditing missing the "Where the rubber meets the road" aspect and doesn't fully test your network with exploits, social engineering, information gathering, etc... Pen testing finds all that stuff, but does it really verify that all your servers have a specific configuration? Probably not, especially with large tests, you are going to compromise the low hanging fruit to get to the good information, but probably not do a patch and configuration audit in the mean time. So, you need both.
  14. Cisco ASA Vulnerabilities - So You Have A Firewall - [Paul] - These vulnerabilities have to do with mostly client-side stuff. It is concerning though that everyone puts so much faith in the firewall and VPN, what happens when they contain a vulnerability?
  15. Cisco Security Cameras - Do You Really Want to call them "Security" cameras? - [Paul] - More holes in security cameras, I'm starting to think that all of this convergence of physical security with network security is a bad idea. Why do my cameras need to be on the network? Remember when they were on a separate network? Isn't that better? Same thing with RFID, what happened to a lock and key? I think we need to mix in some old school tech with our fancy new technology just to keep everyone in check. Sure, I can pick a lock, but someone may notice. When I swipe a card or RFID chip I blend in.

Other Stories For Discussion