#!/zitstif.no-ip.org/

http://www.securitytube.net/GSM-A5-Realtime-Cell-Phone-Interceptor-video.aspx

There’s a saying amongst a few fellow computer security enthusiasts that I know of, that goes a little something like this, “If the attacker has physical access to the machine, the game is over.” (Or something to that extent)

This couldn’t be any further from the truth. If I were to do a permitted pentest upon a company which included physical access as part of the scope, then I would definitely test the local workstations and use one of them as a pivot point to gain further access/information.

To mitigate this attack, the administrator should ideally change the boot sequence to have the hard drive as the first device the computer boots from in the BIOS and also set the BIOS password, and have the computer case locked down, so one couldn’t clear the CMOS (it’s usually jumper 1 on the motherboard).

However, in most large facilities, administrators usually don’t take the time to do this and are usually more concerned with other types of attacks, in my opinion.

Now I will give a hypothetical scenario for a pentester that will permit him/her to do a pentest that will include physical access to this factitious facility.

Upon gaining physical access to a workstation, the pentester has a few tools with him/her. In his/her arsenal he/she has as follows:

BackTrack 4 on a USB flash drive
PLoP ( http://www.plop.at/en/bootmanager.html )
Konboot ( http://www.piotrbania.com/all/kon-boot/ )
cmospwd ( http://www.cgsecurity.org/wiki/CmosPwd )

As the pentester reboots the computer and tries to enter the BIOS, he/she is stopped by a password prompt. In the password prompt, he/she tries a few combinations including backdoor passwords that are sometimes set by manufacturers. ( http://www.uktsupport.co.uk/reference/biosp.htm )

Realizing that none of these worked, the pentester needs to then assess whether or not the administrator has locked down the boot sequence.

Out comes the flash drive and into the USB port it goes! The pentester is aware of how some motherboards will default to the USB drive as the first boot device when plugged in. (I’ve personally experienced this on a motherboard I own). However, still no luck!

With the pentester’s lock picking skills not at their best, he/she is detoured by the workstation’s case lock. It is time to him/her to revert to PLop.

PLop is one beautiful tool. It is a boot manager that you can even use on old motherboards that don’t support booting off of flash drives.

The pentester was in luck! The workstation checked the CD-ROM drive first in its boot sequence! Now the pentester can direct the victim workstation to boot off his USB drive (with Backtrack 4) via PLop.

Upon getting the prompt from Backtrack 4, the pentester is now curious about what the password was set to on the workstation.

To find this info, he/she uses cmospwd. By retrieving this password, the pentester can use this as leverage towards other devices in the network.

I’ve had luck with some motherboards using cmospwd for retrieving the password from the dump it can produce. Consequently, it’s not perfect, but it can get the job done.

I know I mentioned konboot as part of the arsenal but didn’t have the pentester use it, but I thought I’d mention it due to the fact it’s such a wonderful tool to have.

I’ll have more to come as usual and I have two programs in mind that I’m working on..

After having some down time, which started on May 29th, I scrambled around to find a quick solution to the problem.

The problem came to light after noticing a few nights prior to May 29th, that my web server was not responding correctly and I could not log into it what so ever.

So, ergo I had to actually get on my server (physically) and noticed a bunch of read errors, and the first thought that came to mind was “Bad hard drive!”.

With that in mind, I backed up my server contents as needed and booted my server off of a usb drive which contained a live Linux distro and used:

python -m SimpleHTTPServer 80

to host a simple page displaying what had happened.

At a later time I then realized that I had a spare 10 GB hard drive in my basement and that is what the server is currently running on. Hopefully it lasts for quite some time…

My goal with my server is to: top out the specs for it (max out the memory, and hard drive capacity) and have some virtual hosts on it.

For those of you who are fans (I sincerely doubt there are any, but I can hope!), zitstif.no-ip.org is back up!

A key phase in the steps to penetration testing is reconnaissance. Without reconnaissance, pentesters would be essentially blind.

In addition to this, pentesters have myriad of tools to help them with the recon phase.

When hunting down hosts that belong to an organization, dnsmap is a wonderful tool for finding subdomains.

After doing some experimenting with this tool, I stumbled upon a limitation. Dnsmap does not have the capability to read from stdin for keywords to use in the subdomain bruteforcing. It requires a word list. Well what if I want to use john the ripper?

So, I pondered to myself, “What’s wrong with just ‘host’ and ‘john’ in tandem to bruteforce subdomains?”. Well my friends, here’s an example:

john --incremental --stdout | while read words; 
   do host ${words}.google.com &> /dev/null; 
      if [ $? -eq 0 ]; 
          then echo "${words}.google.com"; 
      fi; 
   done

Of course you could change this to accordingly, but here’s it as a function and you could even add this to your .bashrc file.

function dnsbrute {
 if [ ${#} -lt 1 ];
   then 
      echo "I need a domain name...";
      return 1;
 fi
 john --incremental --stdout | while read words; 
   do host ${words}.${1} &> /dev/null; 
     if [ $? -eq 0 ]; 
        then echo "${words}.${1}"; 
     fi; 
   done
 return 0;
}

More to come as usual..

(I’m still dragging my feet on ettersploit.. 🙂 )

Just a quicky:

If you’re in a local area network and you’re trying to do some passive information gathering using a sniffer, here is a great way to find .local host names:

tcpdump -i wlan0 -vv 2&>1 | egrep '*.local'

What’s beautiful about this method is you can usually find people’s full names, especially if they’re using Apple devices. Along with that, you’re not probing or alerting the targets.

Also, if you’re not in range of a wifi access point and can barely see the AP, you can use this method while trying to connect (it makes this method a little less passive..), but I’ve discovered Iphone device names via this method.

And now…. back to the books. 🙂

PS: I’m going to set aside time this week to put more effort into ettersploit.