Capturing admin passwords of embedded devices via Dynamic DNS poisoning

Sometimes, when an embedded device such as a DSL home router is compromised (i.e.: via an authentication bypass vulnerability), the attacker will attempt to extract the administrator's password. This might be possible by saving a backup of the configuration file (i.e.: via the web management console)and looking at the contents. Occasionally, the admin password can be found in the HTML source code within pages of the device's web interface (sometimes "hidden" as a type="password" parameter which can still be read in the source code). A third possibility is the admin password being accessed via SNMP read access.

However, what happens if these techniques fail to work? Well, there is another technique that the attacker could use to steal the admin password. The only requirement is that the administrator must connect to the target device via a Dynamic DNS domain name at some point in time. The idea is that the attacker launches a phishing attack against the admin user via Dynamic DNS poisoning.

Similar to traditional DNS poisoning attacks, dynamic DNS poisoning attacks cause a domain name requested by the victim, resolve to an IP address controlled by the attacker. Such an attack could be used for many reasons such as exploiting the user’s browser in order to install malware or launching a phishing attack.

However, there is a difference between classic DNS poisoning attacks and Dynamic DNS poisoning attacks on embedded devices: the attacker doesn't need to attack the DNS servers in charge of the target domain directly. Instead, the attacker compromises the DDNS service's account that handles the target domain name.

For instance, there are at least two ways to compromise the Dynamic DNS service account in charge of managing the domain used to manage ZyXEL Prestige routers remotely.

The first method is to snmpwalk the OID 1.3.6.1.4.1.890.1.2.1.2 using the read SNMP community string. The second method consists of accessing the DDNS page (/rpDyDNS.html). Note: you might want to check out our ZyXEL routers security paper for more info.

Either method would provide the attacker with the credentials necessary to hijack the admin user's Dynamic DNS account at www.dyndns.com. At this point, the attacker can make the domain name used by the administrator to connect to the ZyXEL router remotely (i.e.: zyxel01.company.dyndns.org) resolve to any IP address of his/her choice. By resolving to the IP address of a web server that returns a login page identical to the ZyXEL router's login page, the attacker can capture the password of the admin account successfully as soon as the admin user logs in.

A good year of vulnerability research for ProCheckUp

2007 was a very good year regarding vulnerability/security research for ProCheckUp. In fact, it was the most active year in the history of the company for carrying out research.

A high number of advisory bulletins were published (20 in total), and some advisories feature more than one security vulnerability!

Having established a good relationship with the vendors who produce the software affected by the vulnerabilities we found, we managed to get mentioned on several high-profile vendor sites.

ie:

BEA Systems:

http://dev2dev.bea.com/pub/advisory/251
http://dev2dev.bea.com/pub/advisory/252
http://dev2dev.bea.com/pub/advisory/254

Aruba Networks:

http://arubanetworks.com/support/alerts/aid-070907b.asc

Microsoft:

http://www.microsoft.com/technet/security/Bulletin/MS07-040.mspx

Blue Coat Systems:

http://www.bluecoat.com/support/securityadvisories/advisory_cross-site_scripting_vulnerability

lso on smaller vendor sites such as:

http://tincan.co.uk/?lid=1975

And recently, in early 2008, also SUN:

http://sunsolve.sun.com/search/document.do?assetkey=1-26-103180-1

Although some of the issues we have found are very common vanilla (non-persistent) XSS vulnerabilities, we have also found some quite interesting issues. The following are a few of them.


Aruba Aruba 800 Mobility Controller Admin Login Page Hack

We found a HIGH risk persistent XSS on Aruba 800 Mobility Controller. This attack is very powerful as the attacker can modify the admin login page by simply requesting a specially-crafted URL of the target controller device. For example, the attacker could modify the login page so that when the legitimate admin user logs in, his/her password is sent to a third-party site where it is logged by the attacker.

The beauty of this attack is that the vulnerable device is the "controller" of the entire Wi-Fi network. In other words, if you own the controller, you own the entire Wi-Fi network.

It's worth mentioning that although non-technical users might not be familiar with products from Aruba Networks, their products are very commonly used in high profile enterprise Wi-Fi networks.


Several information disclosure issues on BEA Portals including
extraction of all portal usernames by unauthenticated users

We found that BEA AquaLogic Interaction and BEA Plumtree Foundation Portals allow attackers to obtain all the usernames of the target portal, including those with full administrative privileges.

Once an attacker compiles a list of existing usernames, he/she can mount a password cracking attack, which is exactly how we accomplished gaining access to a BEA portal during a penetration test.

Plumtree and AquaLogic portals are very widely used not only on Intranet, but also on Internet-facing sites (almost 400,000 results in Google).


ASP .NET request validation bypass

The ASP .NET is considered to be a very secure framework for building web applications. One of its star features is known as ValidateRequest, which is a built-in filter that makes attacks such as XSS much more difficult.

However, we demonstrated how to bypass such filter which allows us to accomplish a fully exploitable XSS condition in many cases. This is obviously an accomplishment we're quite proud of!


Critical vulnerabilities on Absolute News Manager.NET CMS

Absolute News Manager.NET is a CMS (Content Management System) used by companies who need to update their websites regularly in an easy manner.

We found several HIGH risk vulnerabilities, including a file retrieval vulnerability that allows attackers to gain access to any files located on the target server. When we found this vulnerability during a pentest, we demonstrated how we could read the contents of the file containing all the database server settings (server name, username, password, etc ...).

Provided that the database server is visible from the Internet, this would allow an attacker to gain full access to the back-end database server.

Reading the source code of server-side scripts is also possible with this vulnerability.


Multiple vulnerabilities on Axis IP cameras

We found several vulnerabilities on Axis IP cameras, which are - among
other things - used for surveillance purposes. One of the highlights of
our paper Owning Big Brother is a demo exploit that allows an attacker to fully compromise
the device when an admin user checks the camera logs!

We included lots of demo attacks/payloads, including stealing the passwords file, and adding a new backdoor account that have full privileges on the system.

The demo attack which was most welcomed in the security community was replacing the video stream. This attack is just like the technique popularized by Hollywood movies in which the attacker changes the video stream, with a looping video clip, in order to bypass the survelliance system of a building.

Well, those were the highlights of our research for the year 2007. As you can see we've kept ourselves pretty busy! Stay tuned for some new coming cutting edge research in 2008!

BEA Plumtree Portal usernames disclosure and other issues

BEA Plumtree, now known as BEA AquaLogic User Interaction is a popular corporate portal system used by many companies out there.

ProCheckUp has recently published a few vulnerabilities, which Jan Fry, Richard Brain and myself discovered during a pentest. From the three vulnerabilities published, the most interesting one is a disclosure of usernames to unauthenticated users.

We found that by tweaking the parameters of the search request, it becomes possible to obtain all the usernames on the target corporate portal. The results not only include regular user login names, but also administrative ones. Since BEA Plumtree portals are typically used by a big number of corporate users, submitting the specially-crafted search request usually returns hundreds of usernames!

This type of issue is referred to by some people as a username enumeration vulnerability. However, unlike classic username enumeration vulnerabilities that rely on noticing changes in the responses returned by the target server, this type is of username enumeration is of "dumpable" type, which means there is no need to run a dictionary attack to find valid usernames.

What makes this vulnerability more of a concern is that the attacker doesn't need to be logged in in order to obtain the list of usernames. Thus, the threat in this case is not only internal but also external. Also, the fact that BEA Plumtree Portal doesn't enforce a secure password complexity policy (at least not by default), increases the chance of an account being compromised by trying weak passwords against the list of usernames obtained.

In fact, this is exactly what we did during our pentest. We extracted the full list of usernames and then we attempted weak passwords such as passwords equals to "password" and passwords equal to the username. Finally, we managed to identify an account which was using a password equals to the username. At this point, we could already gain access to corporate documents by using the cracked username/password pair.

eBay Insecurities

September 2007 has been a poor month for Ebay with a couple of security issues reported.

In the middle of the month, it was reported that two scripts existed which used a security hole within the Paypal API to obtain some personal account details of eBay members by fake second chance offers.

Later on in the month on the 25th an attacker known as Vladuz posted to the eBay trust and safety board, personal details of about 1200 members including credit card numbers and CVV. EBay has denied the credit card information is valid, though third parties have disagreed with this statement.

More information on this incident below:-
http://www.auctionbytes.com/cab/abn/y07/m09/i25/s00
http://www.ebaymotorssucks.com/vladuz-is-back-again.htm

And now earlier today on the 27th, another security hole was found which disclosed member postcode information to all and sundry. By simply adding an auction number to a public script on a Korean eBay website, postcodes and other information on the winners and bidders of public auctions were displayed without any form of authentication. This script used an eBay API that is documented on eBay’s site, the hole was mentioned on the ebay.co.uk messageboard and the post later deleted.

My concern with all the above is the public nature of the Paypal API, anyone can explore and develop applications based on the Paypal API without registration. Is it responsible for a financial service provider to allow all to view its API?. I don’t believe so, especially in light of all the above.

Developer discussions are open, and require no registration at all:-
http://www.paypaldeveloper.com/pdn/board?board.id=api
https://www.paypal.com/IntegrationCenter/ic_documentation.html

An example call is:-
http://www.paypaldeveloper.com/pdn/board/message?board.id=api&message.id=2429

Default to No

While recently studying for my CISSP exam (more on that at a later date, perhaps), I came across a simple yet oft forgotten way of “adding” security – Namely, "Default to No".

Any good CISSP book will tell you that traditionally “Default to No” was applied to access control. When access is not explicitly allowed, it is implicitly denied.

Let's take a look at how this kind of thinking could be applied to Internet facing applications:
- Allow external access to the Administrator Interface? No.
- Default Administrator password? No.
- Give external users incredibly verbose error pages? No.
- Multiple sample set-ups with masses of functionality and user accounts, which, in order to be removed, require the customer to trawl through the entire user manual? Please, no!

As some developers might point out, in some instances it is very straight-forward to disable, for example, external access to the administrator interface. This usually demonstrates that care has gone into the user interface. Now, if it is trivial to enable/disable external administrator access, why don't developers help protect their customers, by initially setting such values to “No”?
While looking for some supporting arguments, I stumbled across an opposing view, entitled “Default to Trusting”. (Worth checking out if you have a few minutes to spare.) The writer supported his own argument by stating that a well-known programmer named Richard Stallman had encouraged the use of open, password-less systems in an interview. What he failed to mention, however, is that Stallman clarified this by saying: “Security might make sense with banks and military facilities, but in a computer lab, that is a sign of a social breakdown.” Social breakdown? That sounds like a remarkably apt description for the Internet.

After so many years you would think that developers, particularly those of web applications, would have come to realise that their applications are now "in the wild". Alas, no. Security continues, for the most part, to lurk in the depths of developers' minds ... and that keeps us very busy indeed :).

Fun at Defcon 15

This year, ProCheckUp sent us again to the Defcon security conference in Las Vegas.

Defcon is known as the largest underground hacking event in the world. It takes place every year in Vegas in the month of August. This year's conference reached an impressive number with more than 7000 attendees!

Although the event has many fun activities besides presentations (such as contests and parties) it is mainly focused on hacking in the security sense of the word.

Every year hackers from both sides of the fence meet at this event, all of them sharing their knowledge. Defcon is not about showing off what you can do, but is rather to exchange ideas, show what you have learned to the world and let everyone teach you about things you don't know. It's that simple.

Besides the annual event, Defcon also has monthly events known as the Defcon groups which are based all over the world. Check out the link to see if there is a meeting taking place near you. No matter what your interest is I'm sure you have something to offer at the Defcon groups, so why not give it a try?

One of the presentations I liked the most was "Biometric and token based access control systems" by Zac Franken. He demonstrated how proximity cards systems, although secure from the user-to-reader perspective, are completely insecure from the reader-to-backend perspective due to the insecurities of a protocol called Wiegand.

Zac mentioned that when your card gets read, the handshake is encrypted and protected against replay attacks. However, all the traffic between the reader and the backend travels in the clear and is vulnerable to replay attacks. These are flaws present in Wiegand which affect just about every ACS out there, which makes Zac's findings huge.

He built a hardware tool called Gecko, which is in essence a man-in-the-middle (MITM) device. The idea is that a crook hooks up the device after (or inside) the door reader (the size is very small) and then he can come back with his own counterfeit card which passes commands to Gecko. My favourite command was probably "replay last successful login", which allows you to authenticate as the last valid user. The attack assumes that the crook compromises the card reader or at least the cabling that comes afterwards.

Zac even discussed some of the new features for the next version of Gecko which will allow him to dump card data remotely by implementing a bluetooth interface. This in turn talks to a GSM device, so you can be anywhere in the world when dumping data which you can then use to counterfeit your own Proximity cards.

At time of writing the presentation is available on Youtube, so check it out!

Cookie of death?

Many popular websites only use encryption while authenticating. After your browser sends the HTTP request containing the username and password, the connection is downgraded from HTTPS (SSL/TLS) to clear-text HTTP. After this, the rest of the traffic is submitted in the clear for overhead reasons, since these sites are accessed by many users simultaneously.

This is a big security problem. The assumption that only the username and password should be encrypted is simply naive. Since most websites use login form authentication, the integrity of the user's session is typically determined by 'Cookie:' headers. Such headers are always sent in the clear after logging into the site.

If someone steals your cookie this is a problem and don't fall into the trap of thinking this is highly unlikely. The fact that many people use Wi-Fi hotspots these days, makes cookie theft trivial by simply listening to the traffic using any standard sniffer such as Wireshark. Other attacks such as XSS can also be used for cookie theft but this is beyond the scope of this post.

Take someone having a coffee at Starbucks who goes online using his/her laptop. Most likely this user will login to his/her webmail service (i.e.: Live Mail) or favorite social networking site (i.e.: Facebook).

After having researched many free webmail and social networking sites I found it concerning that there is no idle session timeout period in place in most of them. This means that unless the user clicks on "Logout", the session ID value(s) within the cookie will always - or at least for a significant amount of time - be accepted by the target site.

Now, here is a scary thought: what if there was a scenario in which stealing a cookie would ALWAYS grant the attacker access to the victim's account? What if changing the password after the account is hijacked wouldn't make a difference in this attack?

Let's describe an example scenario:

1. Victim checks Xmail periodically
2. Eventually someone captures victim's cookie while using a Wi-Fi hotspot
3. Victim closes browser (or clicks on 'Delete All' on Internet Explorer for that matter)
4. Because Xmail doesn't have an Idle Session Timeout Period in place, the stolen cookie WILL BE ACCEPTED BY THE SITE ALWAYS
5. Even if the victim changes his password he will never be able to expire the session that was stolen

Note: Xmail in this case could be any popular webmail service.

Notice that because the user closed the browser, Xmail will ask him to login again next time he visits the site. The same behavior applies to clicking on 'Delete All' on your browser's history.

The point is that when you close your browser (or click on 'Delete All', all current session information is deleted from your browser (NOT the target site's servers!). So next time the user goes back to Xmail he will be asked to login again. This is because the browser is not sending a valid session ID anymore (it was deleted).

Even if the user clicks on "Logout" after logging in, the session flagged as 'terminated' by the server will be DIFFERENT to the one whose cookie was stolen by the attacker.

In summary, without getting technical, all I'm saying is that someone stealing your cookie can sometimes lead to a permanent hijack of your account, even if you ever change your password. The period of the account being hijacked could be several days, or even permanently (in cases in which session IDs are never expired on the server side).

Note: most websites allows multiple sessions by the same user, either from the same IP or different IP. Xmail was simply used as an example in this post. The same applies to most popular websites.