Operation n

In the past 2 years, client side attacks such as XSS and CSRF have been on the increase. In a presentation I gave at OWASP a short time ago I discussed what I called the Attack Renaissance, where attacks move toward breaking-in via client-side holes rather then traditional server-side vulnerabilities; however, there is more to it then meets the eye.

I think many would agree that web applications have become target number 1. However, I would like to draw the glaze away from that for a second and point out that network-based intrusion is by no means dead and burried.

Services such as VOIP and BES are growing in popularity and often require significant network design and architecture changes to get working. Also, encryption within new protocols may provide attackers with tunnels to hide and mask traffic to avoid intruder detection systems.

Robert Moore is in prison for breaking into a number of VOIP providers, this is what he had to say:

“I’d say 85% of them were misconfigured routers. They had the default passwords on them,” said Moore. “You would not believe the number of routers that had ‘admin’ or ‘Cisco0? as passwords on them. We could get full access to a Cisco box with enabled access so you can do whatever you want to the box. …

In summary, web applications are vulnerable yes, but it is only one area of concern. Currently SANS shows little traffic to BES (one service i’ve been researching lately), but this may very well change in months to come.

A couple days ago I had to have a look into vulnerabilities associated with Blackberrys - see my post "Blackberry Insecurities".

While its fresh in my mind, I’ll discuss some brief security strategies and techniques supported by BES (Blackberry Enterprise Server).

Blackberry security at the enterprise level should include (at minumum):

• Good Design & Architecure
• A Strong BlackBerry IT Policy (similar to MS Windows Group Policy)
• Policy and Procedures

This could probably make a nice whitepaper, but who has time! :)

The BES server is the central point to manage registered Blackberry devices. From here, you can view the current settings of the BlackBerry, change its password, check its software, lock it and much more. The BES server is made up of a number of components and generally these components are installed on the same server but do not have to be. It is recommended that the BES server router component be placed in a DMZ, allowing port 3101 through the firewall at both ends. However, there are other more complex designs which may be preferable.

Passwords must be used on the devices to mitigate risks in the event that they are stolen. A really strong IT policy should be in place which dictates what software is permitted on the user’s Blackberry. BES actually allows you to deny the user access to the Blackberry should it not meet the IT policy requirements.

Some basic policies and guidelines should be in place, such as having the user contact the IT department in the event that the Blackberry is stolen, and a process for the IT department to follow, dictating how to lock the phone out of the network.

You basically have two choices for BlackBerry connectivity, Wireless (G) or GPRS. GPRS, doesn’t introduce new holes into your network, however, Wireless (G) does, as you then have to worry about how the Wireless is configured. Regardless of what solution you choose, remember that additional holes will have to be punched in your firewall regardless. With this in mind, let me encourage you to really think about your Network Design and Architecture before plugging in your BES server and please remember, the BlackBerry should be treated like any laptop of mobile device.

I’ve heard alot about hacking BlackBerry devices via Blackjacking. It was big news late last year, but was it really big news? I wanted to get down to the facts and the real risks involved.

If you don’t already know, Blackberry’s are awesome little "dinky" mobile computers that many companies use to connect their offices via giant Blackberry enterprise servers usually placed within the internal network so that it has access to their Exchange mail servers (or Lotus) to get mail etc. I think you get the point.

It all started with Jesse D’Aguanno who released a really funky tool called, "bbproxy" (BlackBerry Proxy).

bbproxy is really just a trojan which performs port forwarding. Once installed an attacker can perform attacks against internal systems via the BlackBerry. You cannot send the trojan via e-mail, because the BlackBerry Enterprise Server (BES) doesn’t allow software to be installed via e-mail attachments. This means, the more likely route would be via a web server; the attacker would have to lure the user to a peice of software on a web server somewhere and get them to install it.

My first thoughts were, well, how different is this from sending a trojan to a normal PC? There are some subtle differences. Firstly, once BlackJacked (the user has installed bbproxy), Intruder detection systems will be unable to detect the attacks as all traffic is encrypted between the BlackBerry and the BES server via symmetric encryption. Second, the BES server is often located within the corporate network rather then being seperated on its on DMZ. This is because of all the required ports to the MSQL server, mail servers and a fair bit more.

So is the risk any different from installing malware on a PC within the internal network via a website? Its a debatable point in my mind.

From a security perspective, the BES server and every component should really be seperated (security best practises). Also, you can define on the BES server what software can be installed on the BlackBerry - almost like MS Windows group policies.

As a side note, I have seen some guys reverse engineering parts of the BlackBerry proprietary protocols which allows some communication if you can get the BlackBerry key, as well as a number of Denial of Service issues via Bluetooth . . . so in the future we may have a little more to go on.

I released an article on GNUCitizen today around XSS engines and worm propogation techniques. In this article I discuss 3 XSS Engine types:

• Scrape;
• Specific; and
• Generic XSS Worms

If you haven’t already checked it out, I would recommend the read.

This article is part of my concept Ad-Jacking: XSSing for Fun and Profit.

Attacks of the future may utilise Web 2.0 and XSS to propogate worms for profit. The most obvious way to do this is via Ad-Jacking, a term I coined for a category of attacks that utilise a combination of XSS, JSON services and click-fraud. As I mentioned before, Ad-Jacking is like click-fraud on steriods.

Today I will discuss a potential Ad-Jacking scenario as well as a proof of concept JavaScript payload.

You will see many affiliate systems using HTML anchor wrapped around an IMG. For example:

<a href="http://www.the-affiliate/?afl=97781">
<img src="http://www.the-affiliate/images/banner7.gif"
alt="" border="0"></a>

As part of our XSS SuperWorm, for our proof of concept the attacker has setup his/her own affiliate account and is given the affiliate number 12345. Our attackers CPA link would look like this:

http://www.the-affiliate/?afl=12345

Now for our little XSS JavaScript payload which will change the pages affiliate ID (’97781′) to the attackers (’12345′). This means, if the user visiting follows the link and purchases something, the attacker will receive the credit rather than the original site.

The code is simple, we grab every link from the DOM and parse it for our affiliate URL. Once we find it, we simply replace it with the attackers:

var x = document.getElementsByTagName('a');
for (i=0;i<x.length-1;i++) {
 if (x[i].href.match(/http://www.the-affiliate/?afl/)) {
   x[i].href = 'http://http://www.the-affiliate/?afl=12345/?aff=test';
  }
}

An attacker is most likely to Ad-Jack your exisiting Ad network. The reason behind this is that the webmaster has most likely already optimised the website to have the Ad display in the best possible place for increased sales; more importantly, the webmaster is less likely to get suspicious of the attack if an existing Ad network is Ad-Jacked.

XSS can be used for alot more then a simple alert box and should be treated with the fear it deserves.