3VILDATA

...this is where the hacking happens!

[3vildata]

Abusing the MPC-HC WebUI to steal private pictures

Update 2015-08-06: As of last night (2015-08-05), the snapshot.jpg function is disabled by default in beta versions of MPC-HC. More mitigation is also on the way but will likely take longer to develop. Thanks to underground78 for making this happen.

A while back I started reading the source code of Media Player Classic (MPC-HC), mainly as an exercise for getting better at reading C++ code. This post is not really related to C++, but to another pretty interesting (IMHO) finding.

MPC-HC and the WebUI MPC-HC is a popular open source desktop media player written in C++. It supports a wide variety of media formats and has a bunch of cool features. One of them is a web interface called the “WebUI” that can be enabled from the Options menu of the desktop client.

When WebUI is enabled, MPC-HC starts a web server on the machine where it’s running. Per default WebUI listens on the external interface of the machine where MPC-HC is running, but it can also be set to listen on localhost only. At first I thought that this feature was not very widely used, but I was wrong. As it turns out, the WebUI is used as an API by several iOS and Android apps, enabling users to remotely control the MPC-HC client over a local network.

When browsing to the WebUI, a very simple website is shown from where you can trigger a number of actions in the MPC-HC player, such as opening a new file, controlling the volume, shutting down the computer (!!!), etc.. There is also a “file browser” function that can be used to browse the filesystem of the host and to choose a file for MPC-HC to open. Any file that is chosen from the file browser will be opened by MPC-HC locally on the system where MPC-HC is running, which means that it is limited to the media player’s supported formats.

Since the WebUI is not protected by authentication, a “rickroll” attack could be performed by an attacker on the same network as the host running MPC-HC with WebUI enabled simply by issuing the following cURL command:

curl "http://<target_ip>:<target_port>/browser.html?path=\\\some_smb_share\rick_astley.mp4″ > /dev/null

Ok, that’s mildy amusing but not really much more. There is more though.

Hidden features, sort of While the fact that the WebUI can be reached by anyone on the same network as the host running MPC-HC is pretty bad since it means that it is possible to browse the filesystem, it is not possible to read or change the content of any files in this way. The MPC-HC client will attempt to open a file chosen from the file browser locally, and only files with a format supported by MPC-HC will be successfully opened. There is however a “hidden” feature in the WebUI that can be abused to steal actual content from the host.

While reading the source code, I came across this section:

There are several things that seem a bit off about the highlighted part of the code; firstly the fact that the “/snapshot.jpg” URI is not referenced anywhere in the HTML code of the WebUI, and secondly that it is pointing to a function (OnSnapshotJpeg()) in the CWebClientSocket namespace.

As it turns out, what the OnSnapshotJpeg() function (line 806 in WebClientSocket.cpp, too big to display here) does is create a snapshot of what is currently displayed by MPC-HC. This means that simply going to the “/snapshot.jpg” will create the snapshot and display it as a JPEG image.

Exploiting the issue Since we already have access to view the filesystem (but not read any file content), what we can do is to enumerate the supported files, make MPC-HC open the ones that are of a supported format (like images), and then download them from “/snapshot.jpg”. This simple Python script will for example steal every image in a given users Pictures folder on Windows.

And a video (sorry about the terrible quality).

While the above PoC is a very simple example of what could be done by abusing this weakness, there are multiple other ways of performing a more comprehensive attack. User names could also easily be enumerated, and there are several other places besides the Pictures folder where interesting media could be found. For example, both Firefox and Chrome store so-called “thumbnails” - image captures - of previously visited websites, which could potentially give away information about the victims browsing habits and other sensitive information.

About disclosure When I reported the issue, I was under the impression that it would be easy to fix and wouldn’t affect a lot of people, but it turns out I was dead wrong. Because of the 3rd party apps using the WebUI as an API, doing something obvious like implementing authentication would likely break things for a lot of people.

The MPC-HC team was very responsive when I reported this back in the beginning of May (the 5th) and assigned the case the highest priority (blocker). Unfortunately, not very much has happened since. As one of the developers put it: “we are understaffed and nobody has time to look into this more closely”, which basically means that this issue will likely not be fixed in a long while. Given that all the information is and always have been publicly available on the MPC-HC bugtracker anyway, I thought it best to fully disclose the issue so that users of MPC-HC can apply the mitigations mentioned below.

Mitigations The issue can be mitigated by disabling the WebUI when not on a trusted network (like at home) or behind a NAT device (i.e. not directly reachable over the Internet). This makes sense as users are unlikely to need the remote control functionality when watching movies on Starbucks or at an airport, but is not really a solution that will scale well across the user base.

Final thoughts This issue is a great example of why security needs to be involved throughout all the stages of the development cycle. Had there been an early security review of the WebUI design, it is very likely that authentication would have been present from the start and then all the 3rd party apps using it would have supported it as well. Fixing bugs is always cheaper the earlier you catch them, and this is not an exception.

One of the developers wrote that “...one has to remember it was never meant to be used outside of a properly protected LAN” which might have been reasonable thinking once upon a time, but given how and where computers are being used today, that reasoning simply does not hold up anymore.

[3vildata]

Some thoughts about trust

Today I was interviewed by a university researcher about the concept of trust; what it means to me personally, and the role it plays for the security industry. This got me reflecting over some things that I hadn’t really thought about in this way before, and I thought I’d share it here in case someone else finds it mildly interesting.

The basic concept of trust is possibly the most important thing in computer security; we want our systems to be trustworthy in order to be able to trust the data being processed by them and so on. This is fairly basic, but it got interesting when the researcher asked me: “So what does the security industry do to gain trust?”, and this is where I started thinking.

If you look at a company like Google and what they do for security and trust, you will see that they put in a lot of effort to make both their own and other people’s products more trustworthy. Note that this is not to say that they succeed all the time, but they do try. This approach is natural, as Google’s entire business model relies on people using the internet as much as possible.

Another similar case is Microsoft and their Trustworthy Computing initiative as mentioned by Haroon here, which basically started with Bill Gates saying: “Hey, unless we make an effort to make our computers trustworthy, people aren’t going to buy our products”. Of course, the incentive of making secure software or people won’t buy computers isn’t as strong these days since you pretty much have to have a computer to get by, but Microsoft is still doing a good job.

So Google and Microsoft are two examples of vendors who are actually trying, if for their own economic reasons, to make computers and software more trustworthy. But how about security vendors (and this is where it gets really interesting)?

Security vendors don’t really have an economic incentive to make computer systems more trustworthy, even if I wouldn’t say that they are not trying (there are plenty who do, and unfortunately also plenty who don’t). The interesting thing is that the way they attempt to build trust is not necessarily through their awesome APT-slaughtering security software, but through hiring analysts and having them write blog posts and reports. This is a way of earning trust by showing the world that they have really competent people on staff (and they do), but that competence might not have anything to do with the product that is being sold. For all the buyer knows, the product could have been designed by a highly trained team of monkeys (not the same ones working for YouTube though).

I guess what I’m trying to say is that when someone says “trust me”, think about what they have actually done to earn your trust. Because as long as the illusion of being trustworthy is enough to make money, that is the path a lot of people will take.

End of philosophical rant.

[3vildata]

About the infosec skills shortage

Today I got into an argument on Twitter that started with me saying something sarcastic in reference to a recent statement by a vendor and ended with a discussion about the skills shortage in security. Twitter can be a difficult medium sometimes and I don't really feel that I got my point across, so this is my attempt to correct that.

Before I start I would like to point out that in no way do I think that this is the only reason there is a skills shortage in security, but that I do consider it a large contributing factor.

In the beginning, there was firewalls Enterprise investment in security has traditionally been in products such as firewalls, anti-virus, IPS/IDS, and so on. Security products has in turn been marketed and sold as "solutions" rather than tools; heavily automated and not really much to work with. Because of this, they have been considered as infrastructure components rather than applications, you just install and configure them and then let them do their magic. 

Automation is great, until it isn't The thing about buying automated solutions is that it removes the incentive to invest in knowledge of the problem the solution was supposed to solve. Why pay money so that someone can learn how to solve a problem that has already been solved, right? For an enterprise, this makes perfect sense, and for a while it worked.

I've seen the future, brother: it is murder Fast forward to 2015 and things are different. It is widely accepted in the security industry that products alone are not enough to secure, well, anything really, and that you need skilled people too. The problem is that since skilled security people have historically been surplus to requirements for enterprises, there aren't that many available these days.

Ok, so we made the mistake of putting all our trust in machines while neglecting to invest in people and skills once, we're totally not gonna make it again, right? No so fast.

The thing about the thing Here's the thing: some vendors are still doing the "here's our latest product that will solve all your problems" song and dance, and people are still buying it. This means that the very industry that is suffering from the skills shortage is actually contributing to it. And yeah, you could argue that it is the buyers themselves that are responsible for understanding the need for skills as well as products, but that's not really how the world works. Unless security people tell organizations that you actually need to understand endpoint security to do good endpoint security, that's just not going to happen.

For example, the tweet that started the Twitter argument was in reference to Palo Alto Networks' CTO that went on the generally excellent Risky Business podcast to talk about their latest product that was going to "revolutionize endpoint security". I could be wrong here but that kind of sounds like the "buy our product and you won't have to worry about security" routine. Again. 

Here's another striking example of "trust our awesome product and everything will be A-OK" vendor propaganda. Notice the part where it says that if you are not protected by the vendor/product, you are not protected. Internal security team who?

Security in 2015 is on You Once upon time, back when security wasn't such a big deal, it made total sense to pay money for a product to make you secure. After all, like Martijn Grooten said: "AV and firewalls scale much better than people and do more in the short term". And they do, no question about that, it's just that it is kind of dangerous to rely on products that you have no idea what they are doing. In 2015, the option of letting a product solve your security problems on its own doesn't exist. Maybe it never did.

[3vildata]

Organized attackers have a scope too

I often hear pentesters say that the test scopes they are getting from their clients are not good, that too much is off limits. The argument is usually that the scope should be "do anything" since "real attackers does not have to care about scope". In my opinion, this is an argument that does not hold up.

The joy of organization It's well known, and have been for some time, that attackers today are more organized than before. Something that is often forgotten about this is that while organization can certainly be a force multiplier for your business, it also comes with some drawbacks. Anyone who has worked for an organization of more than 3 people knows that to be effective, you need some sort of standardized way of doing things. This applies to everything from how support cases are reported, to what the standard server image contains, to how much time you're allowed to spend on a specific task, to - yes - attacks. Because if your core business is attack, you need a standardized and effective way of doing attack.

Organization and budget is what sets the attacker's scope What this basically means is that the attacker's organization and budget is what sets the attacker's scope. Now this does not necessarily mean that the attacker can only do attack in one way, but it does seem that a lot of them are pretty unwilling to change their modus operandi. For example, take a look at https://apt.securelist.com where Kaspersky keeps track of what they call APT actors. You'll pretty quickly find that there is a whole lotta spear phishing coupled with either a document reader or browser/plugin exploit going on, but not much else. Why? Probably because it's effective, but likely also because that is the type of attack that their organization is designed to support and diverting from it would make attacking much more costly.

Testing needs to be realistic While a "do anything"-scoped pentest could mean that the test would emulate a real APT actor, it is in my opinion much more likely to emulate a super (or at least somewhat) skilled basement hacker with a grudge. To me, that kind of testing is like neglecting to wear a seatbelt because you could be struck by lightning. One is much more likely than the other.

Organizations get compromised in the same ways all the time. If your testing is not emulating those ways, or you are not allowed to test accordingly, your customer needs to know that. Feel free to use my seatbelt vs lightning analogy if you like. :)

[3vildata]

The pointlessness of counting vulnerabilities

A while back I came across this article about the rising number of exploitable browser vulnerabilities. Since I am currently doing some research for an upcoming talk that partially covers this subject, I thought I'd share some thoughts about it.

Not all vulnerabilities are created equal First of all; counting vulnerabilities is pointless because it doesn't really say anything about the risk of using a given product. Let me demonstrate:

From January 2012 to December 2014, Internet Explorer had 392 and Google Chrome 550 vulnerabilities, according to the National Vulnerability Database over at http://web.nvd.nist.gov.

Wow, that must mean that Google Chrome is much less secure than Internet Explorer, right? Well, not really since the number of vulnerabilities doesn't take the severity of a vulnerability into account (Remote Code Execution is more critical than a Denial of Service, etc.).

Not even critical vulnerabilities are created equal Ok, but if we only look at vulnerabilities that would allow RCE? This generates a very different result; IE now has 355 and Chrome 54 vulnerabilities over the same time period. Surely this means that anyone running IE on the Internet is toast, right?

Again, not really. Even though Internet Explorer has had 219 RCE vulnerabilities reported in 2014 alone, only 3 of them have been included in the most popular exploit kits. That's a ratio of about 1.4% of reported vulnerabilities in IE that are likely to be exploited at any scale, which is what actually affects most people.

(It should be noted that there has been a number of zero day vulnerabilities in IE found in the wild in 2014, but every single occurrence has been in relation to a targeted attack, affecting relatively few people.) 

So why aren't critical vulnerabilities always exploited? There are several reasons for this, one of them being that attackers don't really need a lot of vulnerabilities to exploit as long as so many potential targets are not patching or applying additional security measures to their systems. A user who doesn't patch IE in January or February is unlikely to do it in March either, which means that the exploit for the vulnerability patched in January will still work in April.

Another reason is that some software is just not worth exploiting, because the return on investment is too low. For example Google Chrome has its "silent update" feature which pretty much guarantees that any vulnerability out in the open will not live long, and Java has with the introduction of click-to-play effectively made it much less attractive for attackers (no Java 0days found in the wild 2014) as it will no longer execute silently in the background.

What's your point? The point is that the numbers don't matter because they don't tell you whether a vulnerability will be exploited or not. Because of this, simply relying on rapid patching is ineffective because it will always be a whack-a-mole game. Defense should not be about chasing the latest vulnerability, but to implement mitigations based on your attacker's capabilities. Or even better; their limitations.

[3vildata]

Target Was Not PCI Compliant

First of all, as anyone who followed the aftermath of the Target breach that was announced on December 16th 2013 knows, Target was actually found to be PCI compliant (they passed their annual test in September 2013) so technically the title of this post is wrong. I am sorry for the link bait, but bear with me and I will make my case for the title.

Second, I want to state for the record that I am not a fan of PCI DSS. In fact, I think it’s a ridiculous charade with little to no connection to the real world. Or as Rich Smith so eloquently once put it: “PCI is the f*cking devil”.

Also, this rant is not really about Target per se, but rather how PCI compliance and auditing is not working. Target was just lucky enough to be chosen as my punching bag for this post.

If you’re going to do it, at least make an effort Here’s the thing: while PCI DSS may be bad, it is what we are currently stuck with so we should try to make the best of it. The problem is that we are not even doing that. Every company I have been in contact with or have read about is bending over backwards to do as little as possible while still passing their annual audit. The auditors themselves do not seem to be trying very hard either, as becomes painfully clear when you actually study the Target case. There is one PCI requirement in particular where I feel that Target (and most of the more recent similar cases) definitely fail.

The first requirement for PCI compliance reads like this:

Requirement 1: Install and maintain a firewall configuration to protect cardholder data

This requirement has a number of sub-paragraphs, most notably this one:

1.2 Build firewall and router configurations that restrict connections between untrusted networks and any system components in the cardholder data environment.

Paragraph 1.2 also have this “guideline” part:

It is essential to install network protection between the internal, trusted network and any untrusted network that is external and/or out of the entity’s ability to control or manage. Failure to implement this measure correctly results in the entity being vulnerable to unauthorized access by malicious individuals or software. For firewall functionality to be effective, it must be properly configured to control and/or limit traffic into and out of the entity’s network.

The way I interpret paragraph 1.2 and its guideline is that communication shall be allowed on an as-needed basis, which is pretty much how traffic filtering should always be configured anyway. So did Target comply with this? Hardly.

The breach and the fail The way the breach happened is that the Point of Sales (PoS) terminals in Target’s stores got infected with the BlackPOS malware which injected itself into the memory of the PoS terminal. From there it could “scrape” the clear text credit card data directly from the memory of the terminal and send it to a server under the attackers control on the internal network. From that server, the data was encrypted and exfiltrated to external servers on the internet. This is not very different from other similar breaches that we have seen since, with the exception that in most other cases the data was exfiltrated directly from the PoS terminals.

What I wonder is: how is allowing a server or PoS terminal on the internal network, unrestricted access to the internet not in violation with PCI requirement 1? Does it need to be able to communicate with anything or anyone on the internet? The easy answer: it does not, so it shouldn’t.

There are several other sub-paragraphs to requirement 1 that backs this argument up. Here is another one:

1.3.5 Do not allow unauthorized outbound traffic from the cardholder data environment to the Internet.

And the guideline:

All traffic outbound from the cardholder data environment should be evaluated to ensure that it follows established, authorized rules. Connections should be inspected to restrict traffic to only authorized communications (for example by restricting source/destination addresses/ports, and/or blocking of content).

Another requirement where I feel that Target failed miserably is this one:

Requirement 10: Track and monitor all access to network resources and cardholder data

And most notably this sub-paragraph:

10.6 Review logs and security events for all system components to identify anomalies or suspicious activity.

As you might recall, the Security Operations Center that Target has in India actually began raising alerts that something was going on as early as November 30th but no one paid any attention. Now I’m no expert but I am pretty sure that not looking at security events is a fairly clear violation of paragraph 10.6.

Conclusion This is really not rocket science and a lot of the requirements that PCI have could easily be fulfilled just by following basic security standards. A PoS terminal is not a regular workstation and should not be treated as such. A simple control to stop an internal server (or PoS terminal) from communicating unhindered with the Internet would likely have made both infecting the terminals in the first place as well as exfiltrating the data much harder for the attackers, and might even have deterred some of them permanently. This is the basic concept of least privilege, a very fundamental security concept.

There is no doubt in my mind that Target was not PCI compliant and that their auditor should probably have spotted that. An audit, as well as the interpretation of regulatory standards like PCI DSS, needs to be diligent to be effective. I am not saying that the breach would not have happened if Target had really been PCI compliant, but it would definitely had made life harder for the attackers.

Finally, I have seen articles saying that PCI failed Target but I think that is bullshit. If anyone failed Target, it was Target and their auditors.

[3vildata]

A Brief Analysis Of An SMS Spam Campaign

A few days ago I got a message from a friend asking if I could investigate a message he had gotten by SMS about possibly having won 10 000 SEK at Swedish supermarket chain ICA. I said “sure, why not” and spent a few hours digging around. As it turns out, the message in question was nothing more than a spam campaign trying to get people to fill out a survey and thereby give out their email addresses and sign up for different “offers”, but there were some parts about it that triggered my curiosity so I thought I’d do a brief write-up. Please note that this was done during a pretty busy weekend, so you’ll have to forgive my somewhat high level analysis.

Statement by ICA It should be noted that ICA has an official statement on their website about not being involved in any such campaign. The statement also says that ICA never passes customer information on to 3rd parties.

Getting started Before I got going, I went on Twitter and asked around for recipients of similar text messages. I got a few relevant responses, and also a couple that were for what seems to be a different campaign with some similar traits. I also did a Twitter search and found a few cases where people said that they had received these SMS. I eventually ended up with 6 samples, which is not a lot but still much better than just a single one. 5 of the 6 samples had links to the same domain (www.finalen.org) while the 6th had a link to a different one (matfinal.com). This domain does not exist anymore, but the URI turned out to work for www.finalen.org too, so this is definitely the same campaign. This also shows that the spammers are switching domains quite rapidly, possibly to minimize the effect of a particular domain being highlighted as spam.

The message The message arrives as an SMS and claims that the recipient has qualified for a final and thereby has the chance to win 10 000 SEK (about 1100 Euro) at ICA, a Swedish supermarket chain. The message also contains an HTTP link with a URI that is unique for each recipient. The messages appear to come from multiple pre-paid Tele2 numbers, which is yet another sign that this is not a legit campaign.

“Congratulations, you are in the final. Big chance to win 10 000 SEK at ICA. Confirm your place by clicking here”

As you can see, the unique part of the URI has been blurred out, and we will get to why shortly.

The domains When looking up whois information for the domains used by this campaign, I found that finalen.org is registered by a company called Domains By Proxy LLC, and that matfinal.com does not exist. Just as the name suggests, Domains By Proxy is a company that specializes in acting as a proxy for domain registrations, thereby keeping the actual registrant secret. I can fully understand why such a service would be needed, but not for someone hosting a legit survey. There is definitely something shady going on here.

After doing some googling, I found that matfinal.com was previously also registered by Domains By Proxy but has now been deleted, something that just further underlines the tactics used by these spammers. Registering domains for a short time and then removing them is a classic example of shady behavior.

The URL The URL in the SMS looks like this:

http://www.finalen.org/q/MzAx{15 character unique string here}

When the recipient clicks the link in the SMS, he or she is taken to a page that reads the URI, and then redirects the recipient via a location header to another URI that looks like this:

http://www.finalen.org/quiz/q?survey_code=MzAx&aff_code=MTIzNDU3&dom_id=14&last_name=recipient’s last name&first_name=recipient’s first name&phone=recipient’s mobile phone number&address=recipient’s address&zipcode=recipient’s zip code&city=recipient’s city&gender=recipient’s gender&pn=recipient’s personal number

What is interesting about this is that the recipient’s information, including personal number (Swedish equivalent of social security number) and gender, is included in the URI. This means that this is not someone sending spam to random numbers, but a campaign that has a database of people that contains some quite sensitive information. This also means that this particular campaign will have an air of legitimacy about it, as a user that follows the link and finds that his or her information, including personal number and gender, is already filled out is more likely to assume that this is in fact a legit survey.

It should be noted that personal numbers are considered public information in Sweden and that there are a number of payed services that you can use to get someone’s information. I am however not sure if there is any service that can link a person’s personal number with their mobile phone number. More about this later.

Update: It has come to my attention that services like ratsit actually provides both phone number and personal number to subscribers of the service, although not publicly. Such a service could potentially be where the user information comes from, although there are still some questions about how that would be possible for at least one of the samples (see the “Samples and oddities” section below).

Looking closer at the URL, we can see a couple of interesting things:

The first 4 characters after http://www.finalen.org/q/ seems to be some sort of campaign code. These characters are the same for all the samples, and are also the value getting passed to the survey_code parameter in the redirect URL. Nothing else from the original URL seems to be passed to a parameter in the redirect URL.

The 15 unique characters after the campaign code seems to be a unique identifier that resolves a URI to a particular user.

At the moment I have no idea what the parameters called “aff_code” and “dom_id” does, although “dom_id” could be what identifies the domain used when the updated information is passed back to the database.

Samples and oddities As I mentioned earlier, the occurrence of sensitive information like personal numbers was something that made this campaign stand out. This got even more interesting when I noticed that one of the samples had some odd characteristics.

The sample in question was the one that did not have www.finalen.org as the domain in the SMS, but instead the deleted domain matfinal.com. Since the URIs looked the same between the domains, I simply changed the domain to www.finalen.org and got a hit. While this made this sample different from the start, it got even more differentiated from the others when I found that the personal number that got passed to the URL was not that of the female born in 1994 registered for the phone number that the SMS was sent too, but for a man born in 1967 with the same last name. Though I have not been able to verify this with them, I’m assuming that the man is the girl’s father.

Considering that this information has to come from somewhere, one theory is that the girl’s father started a subscription of some sort for his daughter, but registered her phone number as it was her who would be the primary user of the service. This kind of thing is usually done for services that has an age limit, so it could possibly be for a mobile subscription or possibly even for the ICA Bank. As I wrote earlier, the phone number seems to be registered for the girl, although the subscription could have changed owners after the spammers obtained the user information.

Cracking the unique URI strings Another thing that struck me as odd was some similarities between the unique parts of the URIs. Here are the URIs after the www.finalen.org/q/MzAx part with their corresponding personal numbers:

XzA3Mj{REDACTED} 1967{REDACTED}

XzA3MD{REDACTED} 1974{REDACTED}

XzA3MD{REDACTED} 1976{REDACTED}

XzA3MD{REDACTED} 1978{REDACTED}

XzA3Mz{REDACTED} 1972{REDACTED}

XzA3MD{REDACTED} 1978{REDACTED}

As is fairly obvious, the personal numbers starting with 197* all except for one (starting with 1972) have XzA3MD as the first characters of their unique URI string. This initially led me to believe that the unique string was in fact some sort of encoding or replacement cipher, and it turns out that I was not completely wrong although it had nothing to do with the personal numbers.

As it turns out, the unique URI is the recipients phone number encoded with eval() and base64_decode() in PHP, and can be decoded by some simple PHP code or by using an online tool such as this.

So for example:

MzAxXzA3Mz{REDACTED} becomes 301_0733{REDACTED} once decoded.

Where the first part is the campaign identifier and the underscore just acts as a separator between the values. The reason why so many of my samples had the same first characters in the URI was because the phone numbers started with the same digits. Duh.

The database If I had any doubt whatsoever that these spammers were operating based on the content of a database, it was all gone once I encountered this:

This was the result of simply changing lower case letters to upper case and vice versa in the unique URI string. This is a sure sign that the spammers are not very technical, and someone with a little less ethics than myself could probably dump their entire database with a little SQLi trickery.

The website An interesting thing about the website is that it requires a mobile user-agent for the redirect to work, just going to one of the links from the text messages on a regular computer does not work as the page will not load. I tried a number of mobile user-agents and got the same result, so this does not seem to be browser or mobile platform specific in any way. This could potentially be because the spammers does not want the recipient to be able to see the entire URI, although that is admittedly not a very strong reason.

There does not seem to be any exploits or malware being served, something that was not really surprising although I kind of hoped for it just to spice things up. As previously mentioned, the technical level of the spammers also seems to be pretty low as I got a number of PHP database errors just by modifying values in the URL GET parameters.

The survey The website the recipient is redirected to when clicking the link in the SMS has a number of form fields, many of which are already filled out by grabbing values from URL parameters. One field that is not pre-filled out is email address, which suggests that wherever the spammers got the user information, email was not included information. Email address, and the ability to connect an email address to a phone number and persona number, is likely to be one of the biggest objectives of this campaign. When I entered an email address and started filling out the survey, I almost immediately received an unsolicited spam email which appeared to have no connection to this (although of course it had) to my dummy email address.

The landing page, clicking “Delta nu” (participate) makes the page scroll down to…

…the pre-filled out form fields.

The survey itself mainly asks questions about eating habits and economy. The next question seems to be based on what your answer to the previous question was, and every third or so page is basically an attempt for the user to sign up for some service or mailing list, something that probably happens regardless of what you choose.

Conclusion Considering ICA’s official statement coupled with the short-lived domains, anonymous domain registrations, and other classic spammer tactics, there is no doubt that this is not a legit campaign. While it is seemingly no more than a scam to trick recipients into giving up their email addresses and signing up for services, the presence of personal information is disturbing. The main question is where this information comes from. Some theories of mine are:

The information has nothing to do with ICA at all and comes from some other source that does not have a problem sharing (likely for money) customer data with 3rd parties. This source could potentially be a service that has an age limit, as the discrepancy between phone number holder and personal number in one of the samples suggests.

The information comes from a database breach, possibly even ICA’s own customer database, and has been sold on the black market. The theory of a service with age limit is relevant also in this case.

The information has been gathered and compiled, manually or semi-manually, by the spammers themselves.

Spam sucks regardless of delivery vector.

(Update) The information could come from a service such as as ratsit, but that would not explain the mismatch between phone number and personal number as described in the “Samples and oddities” section. Ratsit also has this, somewhat ironic, message on their website:

Finally, if anyone has any more information or samples regarding this, please drop me a line at addelindh at gmail dot com or give me a shout on Twitter.

[3vildata]

Hitting the High C-levels for Better Security Organisations

In my last post I explored (read: ranted about) some of the more commonly sighted shortcomings related to use and implementation of various security devices in organisations.

The magical devices and our failures to treat them with appropriate care and respect are the visible tip of the iceberg – dangerous and certainly annoying to navigate around – but the real danger lies under the surface and is much harder to “fix”.

The root cause often culminates in decisions made, or rather, not being made high up in the organisation – in many cases in the board room, cascading bad decisions (or lack of them) free-falling through the enterprise until they either find an appropriate fan to hit or meet the final buckets low on the floor level.

In order to create a healthy decision making chain and positive security culture in your enterprise, you need to have an organisation that supports, enables and dare I say – empowers – people to take responsibility for the security of the enterprise.

Just a short caveat emptor, before you read any further: I’ve never held a C-level management position in my life and most likely never will. I’ve worked many years in global, Fortune 500 enterprise – some of it as a techie, some of it as an architect and some of it as a team lead and group manager. I can communicate with C-level people well enough, but my hands-on experience from steering a large enterprise is limited to middle-management roles. Take this article with an appropriately sized bucket of salt.

What’s the Problem Joe?

Drink up when you see a C-word!

Many organisations have a poor security management structure. Even large enterprises which are traditionally hierarchical and heavy on management layers suffer from this. For example, our current  favourite breach-victim poster-child Target – did not have a Chief Information Security Officer (CISO) or a Chief Security Officer (CSO), instead their Chief Information Officer (CIO) took the fall over the security breach.

Organisations that have managed to establish CISO or CSO roles have usually a reporting structure where both of these roles end up reporting to the CIO. Sometimes they are buried even deeper in the organisation. I’ve seen an example where the CISO reported to the head of IT-Infrastructure. A strange situation which leads to a very long security decision chain and a very disenfranchised security organisation. 

Start the C-level Musical Chairs

I believe any organisational change must start in and include the boardroom. Unless the top-brass structure reflects and changes with the rest of your organisation, any effort to reorganise will usually fall short further down on the floor with “well I switched desks/cubicle and department number, but am still doing the same business as usual“.

I’m a strong believer in having Security (the CSO) represented in the board room. Security is a responsibility the board has to take – it can’t be reliably initiated anywhere else in the decision making chain.

Really? Me? Again?

This in itself represents a slight problem – adding another C-level to an already crowded board isn’t easy. And adding a role that effectively undermines the CIO’s IT-mandate (from the CIO’s perspective) is even harder. You’ll probably end up seeing the new potential CSO beheaded faster than Sean Bean.

Typical CIO vision for enterprise IT goes something along the lines of  “to be a world-class supplier of IT products and services that help our business make boatloads of money”. This often translates to a misson that attempts to run the IT-infrastructure reliably in the most cost-effective manner while providing application development in a lean and – you guessed it – cost-effective way. IT cost-effectiveness earns money. I’m sure you’ve all heard this many times before.

If your enterprise security falls into this context, you will most likely focus on wrong things and your security is based purely on IT-driven needs (possibly even inheriting the cost-effectiveness aura in the process). The common misconception in IT is that security “gets in the way” of running things cost-effectively and reliably. While the second part has never been true, the first part of the claim might have carried some weight earlier, but the recent breaches have shown how much money good security can actually save. Selling this to hard pressed, cost saving IT-departments is still a tall order though.

Bad decision chains lead to bad decisions (wellduh!) and reduces the visibility of security in the board room drastically. I’m quite sure the CEO won’t be able or willing to answer very many security related questions in interviews, unless you have a security agenda in the boardroom. Bad security visibility also has the (often unintended) side-effect of nullifying any attempt to do effective operational IT-security; that ghost of cost-effectiveness again – let the techies figure it out while they do their other techie-stuff.

This leads to a situation where many organisations think they are doing operational security, but in reality everyone is “too busy with production issues” to actually do anything security related at all (except maybe complain about the lack of it).

Instead of hiding the CSO deep in the IT organisation, the role needs to be made equal to the CIO. Additionally, if your board is getting crowded and you need additional levels of hierarchy, you should have them reporting to different superiors. IT is based on operational business needs, so it would make sense to have the CIO reporting to the Chief Operations Office (COO). Security, on the other hand is risk based, so it is more natural to have the CSO report to the Chief Financial Officer (CFO).

This removes the Mexican standoff between the CIO who wants to be in full control of IT and the CSO who wants to dictate what controls IT should implement. They will both have their boardroom champions lobbying for the CEO’s attention (I tend to think C-level politics as something George R.R. Martin might have written. Though generally with a little bit less incest and far more vicious power plays).

Creating an organisation with a reasonable chance to succeed in both Operations (and IT) and Financials (and Security) in the highest levels will create a calmer situation further down the decision chain. Security will be created on business risk based decisions instead of IT-driven cases (or even worse, IT-infrastructure) or through the drive to reach absolute cost-effectiveness.

So keep this in mind next time you end up sharing the elevator with your CEO. It’s pitch time.

[3vildata]

It Is Time For Defenders To Go On the Offence

This is the comment piece I wrote for the February issue of Virus Bulletin, but that I for copyright reasons haven’t been able to share before now. I will be presenting at this year’s annual Virus Bulletin conference (VB2014), it is a great conference and I highly recommend it to anyone into information security.

Defence is hard. From a defender’s point of view, it only takes one slip-up, one misconfiguration or one unpatched machine for an attacker to gain access and capitalize with potentially disastrous consequences. Not only that, but it is also very difficult to know if or how well your defences are working. Sure, you can measure it to a degree, but only for the events that you and your security products can actually see. For an attacker, it is pretty much the other way around; they usually know if what they are doing is working or not.

One of the major problems for those tasked with defending networks is a lack of knowledge about what they are supposed to be protecting against, on a technical level. A lot of defenders are former network or firewall administrators who are great at TCP/IP and routing, but seriously lacking when it comes to understanding how exploits work or how security products can be bypassed. This, coupled with the way some vendors are marketing their products (basically as self-playing pianos) has in many cases led to investments in and reliance on automated security products instead of competence and personnel development. I believe that this is a dangerous road to travel as attackers will always be able to subvert security products that are run in out-of-the-box mode.

There are few areas where such a lack of knowledge becomes more painfully visible than in Security Information and Event Management, or SIEM. While, for example, an IPS or anti-virus product will still do some level of good if you do no more than install it on your network and make sure it gets updated occasionally, a SIEM will not do anything except generate a (huge) bill. Although most vendors will include a set of default correlation rules, being welcomed by 12,000 so-called ‘security events’ the first time you log into the management interface is an overwhelming experience for anyone. The point is, if you don’t know what you are looking for, a SIEM is only likely to cause you pain.

So what can be done? Well, for a start, defenders need to be allowed to develop their offensive skill set. Instead of routinely sending security staff to some vendor-supplied or defensive training, challenge them to take a penetration testing or exploit development class. By knowing and understanding offensive techniques, defenders will be able to start thinking like attackers and defend accordingly. If you don’t understand what post-exploitation is or how it works, how are you supposed to be able to spot it going on in your network? And how are you going to be able to detect an SQL injection attack on your web application if you don’t know anything about attacking web applications? The challenge here is to make sure that defenders get offensive training that actually reflects current, real-world attacks, and not outdated techniques that are only used by penetration testers.

Another area defenders need to be more proficient in is threat intelligence. Although most vendors have some kind of offering in this area, they seldom offer anything that does not relate directly to their own product(s). While these offerings can certainly be of some use, a more vendor-agnostic approach is needed. The point of threat intelligence is to be able to make informed decisions on defensive prioritizations by studying actual attacks and trends. This is an area in which defenders in general could get more involved by doing their own research and contributing their own conclusions to the security community as a whole. (It should be noted that to be able to do this, a whole different skill set from configuring a firewall is needed.)

To conclude: it is time for defenders to go on the offence. It is time to stop defending based on gut feeling and outdated best practices. It is time to start making informed decisions based on real attacking knowledge and intelligence. After all, a defender who knows nothing about offence is effectively no more than a system administrator who happens to manage a security product.

And there is no reason why defenders cannot be hackers too. I know I am.

[3vildata]

Bypassing Advanced Threat Detection Systems

First of all, let me make it clear that this post is entirely theoretical as I have not been able to test any of the techniques or approaches discussed in it. All of my conclusions are based on my experiences working with these kind of systems, the conversations I have had with the people selling them, and what written information I have been able to find.

Advanced Threat Detection systems (or Breach Detection Systems as they are called in this NSS Labs report) are generally touted by vendors as a “must have” for detecting and stopping advanced attacks, and in particular advanced malware. Some vendors even go as far as to saying that their system is the only one defenders need to pay attention to. Often, the point is made that other security tools are high on false positives (IPS/IDS), can only do signature based detection (client anti-virus), or that they fail in some other, usually spectacular way. So what makes Advanced Threat Detection (ATD) systems so different then?

We are the cyberz, duh duh-duh-duh.

The type of ATD system I’m referring to is network based, i.e. there is no software installed on the resources it is protecting. It is placed somewhere between the internal network and the Internet, mainly to be able to intercept and inspect traffic to and from the Internet. The idea is that everything that goes into the network (like responses to web traffic, email, attachments, etc.) as well as everything that goes out (like malware infected hosts communicating with a command & control (c&c) server) will be seen and inspected by the ATD. To help decide whether a downloaded file or email is malicious or not, the ATD has the ability to start a number of virtual hosts where the payload can be executed. The ATD can then see what the payload does, and can use this information in its analysis.

This approach sounds great, and it is an improvement to how traditional security tools work, but it still leaves room for some fairly basic issues. Considering that the marketing of these systems are very much focused on stoping attacks that are advanced, let’s look at some not-so-advanced ways of bypassing them.

Denial of service on virtual hosts As already mentioned, these kinds of systems have a number of virtual hosts that can be fired up and used for analysis of, for example, downloaded executables. As this kind of analysis takes time, web traffic and email are treated differently; emails are not passed through to the recipient until the analysis has finished, while web traffic is let through immediately and then acted upon later if needed (if the analysis detects something malicious). This is because it is usually OK for a user to have to wait a few minutes on an email (that he might not even know has been sent), while loading a website is a completely different matter when it comes to acceptable latency.

One pretty basic issue with this is that a virtual host requires hardware resources, and such resources are never infinite. Because of this, an attacker who knows that his target is using a specific ATD can overwhelm the system to exhaust all of its available hardware resources by sending it gibberish to analyze. Once all the hardware resources that are available for virtual machines are occupied, the system will likely fail open as internet availability would otherwise be affected, and the attacker can launch the real attack. One approach to this could be to have the website where the “real” attack is hosted also perform the exhaustion attack, simply by launching both in sequence as soon as a user from a specific IP address (like the targets web proxy) visits the site. The exhaustion attack should not be a web attack as the ATD system would then be able to connect it to the user in question, but rather by email or other media.

Sorry bro, no hardware resources left.

Attacks over SSL This one is so basic, I’m actually almost reluctant to expand on it. Here is the short version: Very few companies do SSL inspection, i.e. decrypt SSL encrypted traffic, inspect it, and then encrypt it again before forwarding it to the server or user. Because of this, tools like ATD are blind to the content of a web request or response over SSL, or even encrypted email. This makes it impossible for the ATD to analyze the downloaded content, and the only fallback is alerting on known malicious domains (or possibly traffic pattern anomalies), something an advanced attacker would never use.

Out-of-band infections Another approach that an advanced attacker with knowledge of his targets ATD could use is an out-of-band infection, i.e. performing the attack outside of the ATDs reach. This could be done by passively fingerprinting the targets client platform, for example by purchasing ad-space on a website that the targets employees are likely to visit frequently. Once a good fingerprint has been established, configure the attack to only launch on targets that match the fingerprint but that does not come from the targets IP space. This way it is possible to perform an attack on an employee that is using his client outside of the targets network, and then perform callbacks from within the network once the victim returns to the office where he has access to all the juicy information that the attacker wants.

Of course, the callbacks might be spotted by the ATD, but there is a solution for this too.

Callbacks over non-suspicious channels The ATD will inspect traffic coming into the network as well as traffic going out. This is a good design feature as it will allow the system to catch callbacks from hosts where it has not seen the actual infection happening, like for example in the scenario above. There is however a fairly simple way of bypassing this too.

Because the ATD will inspect everything going out of the network and alert or block anything it detects as malicious, the trick is to make the callback look like regular user traffic. One way to do this is to make the request look like it came from a commonly used software, like Internet Explorer, and also to make the request go to a non-suspicious destination, like Facebook. From the fingerprinting exercise in the previous scenario, the attacker will already know what a request from the targets installation of Internet Explorer looks like and can tailor the request accordingly. As for the destination, a site with a chat function (like Facebook or Google) would work well for receiving commands and even exfiltration of information. Even if SSL inspection was being done, there is little chance that an ATD would be able to tell the difference between a bot receiving commands over Facebook chat and a regular user chatting to a friend.

Authentic picture of botnet.

Conclusion These are just some examples of the back of my head, but I’m sure there are several more once you really think about it. The point is that to say that these systems will detect advanced attacks is basically a question of semantics. Yes, they will (in some cases) detect more advanced attacks than regular, run-of-the-mill malware. And no, they will not detect or stop an attack coming from an advanced attacker who is aware that there is an ATD system in place. As a piece of a defense-in-depth architecture, these systems can definitely play a role alongside other, more traditional tools, but to claim that an ATD product could replace everything else is just borderline idiotic. Not to mention that no security tool will ever realize its full potential without a skilled human analyzing the events produced by it, something that is constantly overlooked (or ignored) by sales departments everywhere.

[3vildata]

Avoiding Phishing in Simple Steps

The Wikipedia definition for phishing is following

Phishing is the act of attempting to acquire sensitive information such as usernames, passwords, and credit card details (and sometimes, indirectly, money) by masquerading as a trustworthy entity in an electronic communication.[1][2]

Anyone who has spent any time near the Internet and with electronic communications has most likely seen some examples of live phishing. If I look into my e-mail spam box right now, I can count 19 phishing e-mails in the last 7 days.  Of course most of the time they end up straight into the spam box and I never see them, but they keep on coming, a steady stream of spam, scams and phishing. Mass scale phishing is relatively cheap, safe for the attacker and it has potential for great rewards, that’s why the steady stream of e-mails keeps on coming.

Catch of the Day! Is that you?

Most of the common phishing spam these days focuses on one thing alone, stealing your credentials. It might be your bank, your web-mail or online game you’ve played. In fact, online gaming accounts can be a real gold pot for the attacker – back in 2010 a World of Warcraft account could net you anything between $35 to $28,000 depending on how well the characters were developed. I’d guess that sum is significantly lower now, but it still seems attractive enough to send out regular phishing campaigns. Out of those 19 phishing e-mails in my spam box, five are trying to phish for my World of Warcraft credentials. (Also Blizzard offers a wide variety of security tools for their customers – everything from two-factor tokens to SMS alerts – more than most financial institutions – but that’s probably material for another article).

So – how do you avoid getting caught in these campaigns? There are couple of very easy methods that will catch most of these scams.

For InfoSec veterans these might be points that are often taken for granted or applied automatically but the amount of times a relative or a friend has called me asking for help to identify potential scams is frighteningly high – so I thought a basic how-to would be in order – basic advice for avoiding getting phished – for your own digital safety, spending time to familiarize yourself in these techniques is well worth the effort.

Common Sense Doesn’t Require License

Whenever you receive an e-mail telling something is wrong with your account – be it World of Warcraft, your Bank or your Facebook/Twitter – your spider senses should be tingling immediately. Banks and companies don’t send out that kind of communication in e-mails.

If the e-mail contains attached HTML or PDF form for you to fill in, it’s always a scam. Your bank/game/service has a website and a login page, they don’t need to e-mail it to you, no matter what they say in the e-mail. They never will.

If you receive an offer that seems too good to be true, it most likely is.

If you’ve won a prize or lottery you’ve never heard of, you most likely haven’t.

If you receive an e-mail from a service you’ve never used or signed up for – you most likely don’t need it now either.

The widow of a Nigerian ex-prince with bags full of dollars doesn’t need your bank account to transfer the money.

Good, old-fashioned common sense, without any tech knowledge goes a long way when fighting phishing. Just because the communication is in electronic format in e-mail doesn’t mean you should switch your brain off.

When in doubt, don’t click the link in the e-mail, instead:

Pick up your phone and call the company support desk. Verify the issue with them first.

Type the address of your bank/game/service manually in the browser address bar, never trust the link in the e-mail.

Read it Carefully

So let’s have a look at one of the phishing e-mails in my spam box and try to figure out why it’s a phishing e-mail.

This one seems to be from Blizzard Entertainment and it looks like they’re suspecting I’ve been engaging in suspicious activities in World of Warcraft – my account is in danger of being closed!

The mail is fairly well crafted, it looks like a Blizzard e-mail, it uses the World of Warcraft logo from the most recent expansion, the links seem to be pointing to Blizzard and it looks fairly legitimate. You’ll notice the language is quite “off” if you read it carefully, it’s smells a bit like automatically translated message. That’s Strike One, Blizzard would make sure their English is correct.

I’m an occasional World of Warcraft player, so of course this could be worrying to me. If you’re not – then that would be your second obvious clue that this is just misplaced phishing attempt. (so potentially Strike Two for you – but in my case, let’s move on)

Moving on to the top of the mail – the sender:

The battle.com address, while close – is not correct – as a player, I know Blizzard’s Battle.Net service lives – rather unsurprisingly – at battle.net. That alone should set a warning bell in your head, but if you want to be really sure,  you can use a tool like who.is to verify the registered owner of a domain name.

Nope, not BlizzardYeah, that’s more like Blizzard

Note that you can’t always trust the whois information, it can be forged – but it gives you a hint. Generally – legitimate corporations don’t obfuscate their info. Criminals do.

So the battle.net seems to be the correct domain. The mail doesn’t seem to be from Blizzard. Strike two.

The next hint comes from the body of the e-mail – just by looking at the link:

It looks correct – but I’m a European player and Blizzard would know this, so why would they try to send me to their U.S site? Clearly this mail comes from someone who doesn’t know which server my WoW account is. So most likely not Blizzard. Strike three.

By further examining the link – this is easy if you read your e-mails in browser (i.e. Gmail, Yahoo mail, Outlook.com etc.), just hover your cursor on the link and look at the status bar of your browser – it shows where the link is really pointing:

hmmm…wait a minute…..that part doesn’t look quite right…

Obviously, that “.warcraft.cn.com” part shouldn’t be there. Instead of pointing to Battle.Net, the link points to some site in China. Strike four (!).

If you’re not reading your e-mail in a browser, you can still examine the link. Most modern e-mail clients (Outlook, Thunderbird etc) offer you a chance to see where the link is going if you just hover your cursor over it.

Outlook 2013 shows the link in tooltipThunderbird has a status bar showing the link target

Read the tooltip/link carefully, the attackers are very good at trying to obfuscate the addresses, using typos and letters that look the same “1” (the number one) and “l” (lower-case letter L) for example. And as with above example, the beginning of the link looks correct – so be sure you always see the entire link – sometimes they’re really long on purpose in hopes of running the misleading parts off your screen so they’re not directly visible.

At this point, the mail has already raked up four rather obvious strikes and I’m 100% certain that this is a phishing e-mail and it didn’t originate from Blizzard. I can safely delete it.

There are more technical tricks that we could apply here to examine the e-mail more closely, but it’s very seldom that you have to go that far. Most mass scale phishing mails are easily detectable by using the above technique.

Additionally…

Keeping your software and web browser updated is extremely important. Most modern browsers have built-in functions that block dangerous and reported pages – if I had clicked the link in the e-mail, my Chrome would have warned me with following:

Most anti-virus programs have also plugins that allow them to scan for dangerous links, so keeping your AV software updated and current is part of your basic Internet hygiene.

Summarizing

Don’t panic

Apply Common Sense

Check who the sender is.

Read the mail carefully, is it grammatically correct or does it feel like a cheap auto-translation?

Check where the links are really pointing to

And if you’re still in doubt:

Pick up your phone and call the company support desk.

Type the address manually

Finally – here’s some further reading to learn more about anti-phishing techniques:

STOP. THINK. CONNECT

Anti-Phishing Work Group (APWG) Consumer Advice

Bank Safe Online

Hope this helps – safe surfing!

[3vildata]

My Magical Box Syndrome Rant

I guess many of us in the InfoSec business have been there. Staring into the console of a security device, faced with thousands upon thousands of “security events” generated by the default rule-set that was installed by the vendor when the box shipped, many, many moons ago.

It’s a special sense of despair and it only gets worse when you realise it’s just the first box. In an enterprise security landscape you’ll probably find plenty of other similarly configured boxes. Each of them designed to solve a specific problem. Some of them perhaps designed to solve all possible problems. But none of them really solves anything and most likely they’re all in a more or less similar state of decay – the horde of zombie events escalating by the day. If they could, they would pull out those 1U mounts, shamble out of the rack hungry for “Moooooreee brainnnsszzz…”

Unfortunately, many times enterprise security devices are like the walking dead. Feared like the plague and best kept in dark crypts where they can’t escape and can’t be touched.

In the more mature enterprises, perhaps the alerts they generate are sent to a distant screen of a Security Analyst, sitting in an off-shored and outsourced SOC, trying to perform some kind of security analysis – but most likely just applying pre-defined thresholds and filing escalation tickets like there is no tomorrow.

So why does this happen?

Compliance is a check-box…you always know what you get.

Enterprises have to follow compliance rules. They don’t really have a choice. So security-wise, buying in Magic Boxes to pass the compliance bar is the natural thing to start with. However since compliance is about checking the right boxes – in many cases, a Magical Box humming in the rack will be enough to satisfy the requirements – the rulesets and signatures don’t actually have to be relevant to the actual threats your business face. Some people in the security team most likely have a policy and compliance background – for them this is a completely acceptable situation.

We’re all just glorified SysAdmins

Nothing wrong with SysAdmins, I used to be one as well. Security people are in many cases old infrastructure (and/or network) people. Sometimes you even see CISO’s organised to report to the head of IT-Infrastructure. For some reason it doesn’t seem to be equally common to move from application development to the security team. This has a tendency to lead to a culture where treating security devices as “boxes” is completely normal. Just like the compliance people are fine with checked boxes, the ex-Infrastructure people are fine with “device based security”. Blinking box mounted to a rack, what else do you need? Just like a network switch, right?

I have this Bridge in London, would you like to buy it?

Security Device vendors are extremely good at marketing silver bullet solutions. They will happily sell you boxes and solutions that will magically solve all your problems. The catch is – they rarely want to follow the sale into your organisation, making sure that those value added superlatives in brochures are actually realised. That’s your problem. They tend to disappear after you sign the P.O. This is of course a very short-sighted strategy, but still a surprisingly common thing to see. New buzzwords like Threat Intelligence, Cloud Security and Big Data get similarly packaged into “products” and sold with the same concept, “plug it in and forget” and the worst of vendors will probably use FUD tactics to get the sale (x% of enterprises in your field are breached! The sky is about to fall!) – but as good or bad as it sounds real life hardly ever works like it does in brochures – enterprises are not static, there is no One Size Fits All solution.

Can’t we just talk to each others?

Each Magical Box speaks it’s own magical language. Sure, it might hook into other parts of your enterprise infrastructure. It might authenticate towards your AD. It might be able to mount remote file systems. You might even be able to monitor if it’s on or off through SNMP. But once you log on to the interface where you’re supposed to spend most of your time analysing events, you’ll notice it’s most likely a horribly buggy Java creation from 1999.  It probably doesn’t even work in your enterprise approved web browser. It probably has just enough functionality to make you want to tear your fingernails out one by one and you end up spending many sleepless nights writing scripts trying to integrate the data exports into something that actually achieves more complicated filtering than “Sort by Name”. Forget interoperability and integration, it will absolutely and completely refuse to talk to any other security device.

Security Teams as Application Owners

Enterprise Security teams are often staffed with Policy/Compliance and/or Infrastructure people. Both are of course fine choices, but lack the application maintenance perspective. So when a new shiny Magical Box is brought in, it tends to be treated either as a compliance tool or a rack device full of Das Blinkenlights.

Any other common off the shelf enterprise product (say, SAP or Microsoft Sharepoint) will most likely have a separate Application Maintenance team, Development team, Service Delivery Manager, Runtime Manger, Infrastructure team and a User Support team. But your million dollar Magical Box is going to be owned and handled by your security team – who most likely has no clue at all about how to actually maintain it.

So, how are we going to change all that?

Maybe we can’t. At least not overnight. A lot of attitudes need to change and mature and no one has the magical polyjuice potion to transform it all in one go.

Vendors will need to change their sales rhetorics and strategies. Buyers need to require more than just a brochure with the latest buzzwords. Security teams and organisations need to mature to a point where security devices are not treated as boxes in a rack and is handled and maintained like any other enterprise application.

But perhaps we can start the change.

Every time you see a vendor presentation or meet with their sales people, instead of asking about their device’s network throughput or Events-Per-Second, ask about their Integration possibilities or interoperability of their interface. Ask if they have a documented and open API you can use.

Identify your users. Applications have users, if you treat your security device as an application, then you need to think about your users. Talk to them and find out about their requirements. This will lead to feature- and change requests.

Challenge your organisation to build Security Application Maintenance teams. You’ll need to plan how to develop feature requests and how to deal with change. You probably need to look at your event flow and figure out ways to increase the quality and signal-to-noise ratio from your SOC. You’ll have lots to do.

Gradually things will get better and maybe one day the thought of security devices without application maintenance team will seem just too silly to be true.

You need to separate your security applications from your security infrastructure. Don’t stand idly by and let zombies take over.

[3vildata]

From CSRF to Credential Harvesting Over SMS

A while back I started doing some research in the security of 3 and 4G USB modems, mainly regarding their web interfaces. This is a write-up of a pretty fun trick I came up with which is leveraging a Cross Site Request Forgery (CSRF) vulnerability, something that is (not surprisingly) present in some form in every one of the devices I have looked at so far. As I haven’t had time to notify the vendor yet, I will withhold all information regarding vendor and model for now.

USB modem network setup Most USB modems have a network setup similar to that of your standard WiFi router; it creates an internal C-network, assigns the client an IP address within the network and sets itself as the default gateway and DNS. This is also where the web interface that the user interacts with resides. The modem itself also has an external interface which receives its network configuration from the internet provider.

Modem features In the modems web interface, the user is able to perform a number of configuration tasks such as setting a pin, changing the pin, disabling or enabling the pin, disabling or enabling roaming, adding a profile, and so on. Most of these functions would at best be mildly interesting to an attacker, after all; where is the profit in locking out someone’s SIM card? Luckily these devices all have another more interesting feature too, namely the ability to send and receive text messages.

The web interface view for sending text messages.

SMS by CSRF I fairly quickly found a CSRF vulnerability that would allow me to make the modem send a text message to any number of my choosing, simply by having the user go to a website under my control. Unlike WiFi routers, there is no login functionality for USB modems so I didn’t have to worry about bypassing authentication. This is what the POST request for sending a text message looks like:

The POST request for sending a text message.

Fairly straightforward if it wasn’t for the highlighted parts, especially the msg_content parameter. At first I thought it was a hash of some kind but when I discovered that it changed size depending on the content of the SMS_Content parameter, I realized that it had to be some kind of encoding of the text message content. As I figured that this encoding had to be done client-side with JavaScript, I started looking around for some code resembling an encoding function and I soon found this:

Does this look like an encoding function to you?

As it turns out, all I had to do was supply this function with the text message content and it would return a valid value for the msg_content parameter. Success! The other parameter I was curious about was the rd parameter in the URI, but even though it changes for each text message sent using the web interface, it will still accept the same value every time.

While this would mean profit to an attacker (send a text message to a high charge text message service under the attackers control), I thought it was too easy and not very fun. So I started thinking about how this vulnerability could be used in other ways.

Let’s go phishing Another thing I had been looking half-heartedly at was spoofing websites using the data URI scheme supported by a number of browsers. The reason I thought this was interesting was because it would not require any domain or web server infrastructure for an attacker to host the spoofed website on, as all the HTML would be loaded directly in the address bar. As an exercise, I created a fake Facebook login site which in addition to logging the victim into the real Facebook at the same time also steals the users login credentials. I then proceeded to turning the HTML file into a data URI using this online tool, and then used TinyUrl to shorten the extremely long data URI to a real HTTP address which would then resolve to the data URI.

Looks legit.

So what if I were to combine these two attacks and have my fake Facebook login-site send me the stolen credentials in a text message? That would mean a targeted phishing attack aimed only at users of (certain) USB modems. Sounds far fetched, right? Perhaps, but a fun exercise nonetheless!

Update: It has been pointed out to me (thanks @peterjaric) that I should probably explain why I thought combining these two attacks was such a good idea in the first place. It is mainly because this would mean an attack completely without infrastructure requirements; no web server to host the spoofed website, no server to post the stolen credentials to. All that is needed is an email address or some other way to distribute the URL, and a pre-paid phone to receive the text messages.

Stealing credentials with out-of band harvesting  To begin with, I added some JavaScript code to the fake Facebook login site. One function (steal_credentials()) to grab the credentials from the login form fields and send them in a text message using the CSRF vulnerability in the USB modem, and also the function to do the encoding required for the CSRF exploit to work.

Nothing evil going on here at all…

After that I added my steal_credentials() function to the functions to be executed after the user tries to login.

On submit: fireworks!

And then we try it out…

Receive an email and click on the link…Login to Facebook……and the phone gets a text message.

Conclusion As I wrote earlier, this attack sounds pretty far fetched, but is it really *that* far fetched? Considering the modem I used in this example is a high-end one, quite expensive, and from what I understand mostly used by corporate customers, maybe it isn’t as unlikely as it may seem at first. With that said, it would have to be a highly targeted attack as there are much easier ways that also have a broader target scope than this when it comes to stealing login credentials.

Protection Some ways to protect from this kind of attack is to use a plugin like NoScript, and also to be vigilant of what the browser address bar actually says. Another useful thing would be a plugin that would block requests to internal addresses (192.168.x.x, 10.x.x.x, etc) initiated by external or other untrusted websites, but I haven’t seen one so far.

[3vildata]

Enumerating Open Shares On The Buffalo Linkstation

(The following issues were reported to Buffalo on the 21st of March 2013. I have asked for a response on when or if they plan to have it fixed but have not received one. I have also informed them about my plans to blog about it, something they answered with “this would be fine”. So, here goes.)

There’s been a number of enumeration-related security stories in the press lately, most notably regarding Amazon’s S3 bucket storage, but we’ve also revisited the one that sent Andrew Auernheimer, a.k.a weev, a.k.a @rabite, to jail for 41 months. Since enumeration seems to be all the rage at the moment, I thought I’d chip in with my own, although admittedly very much less high-profile, one.

The Buffalo Linkstation A while back I purchased a Network Attached Storage, or NAS, device. Since my budget was a bit constrained at the time (home renovation tends to do that to you), I couldn’t go with the device I actually wanted and had to settle with a cheaper variant. What I ended up buying was a 2TB Buffalo Linkstation Duo, a device that Buffalo themselves describe like this:

LinkStation™ Duo offers cost effective RAID network storage and backup for all PC and Mac® computers on your home or business network. Enjoy uninterrupted access to terabytes of storage on your network and even over the Internet while you’re away.

While the NAS itself has done a decent job functionality-wise, I of course had to take a look at it from a security perspective too. I was especially interested in the “WebAccess” feature, a function that enables access to files from the internet over a web-interface. In Buffalo’s own words:

While on the go, Buffalo’s free WebAccess service allows you to create a personal cloud for easy remote access and file sharing with anyone, anywhere over the Internet. Your data remains securely stored in one place on your home network, but you can access it quickly from any computer, tablet or smartphone device over the Web. Sharing is as easy as sending a link to your friends and family; they can securely access only the files you’ve selected for them to see.

Sounds pretty good, right? The good thing is that it IS actually pretty good as long as you configure it correctly, the bad thing however is that Buffalo doesn’t really encourage a decent configuration.

While I did find a number of other issues that has also been reported, for example an authentication bypass in the administrative interface (usually not reachable from the internet), I don’t feel that any of them are as critical to the end-users as the one presented below.

Web Access As I’ve already mentioned, the WebAccess function is actually a pretty good idea. It basically works in the same way as dynamic DNS does; the device calls home to Buffalo within regular intervals and reports what IP address and port it is listening on. Buffalo then provides a website where you type in the name you chose for your NAS when enabling WebAccess, and you get redirected to the IP address of your NAS (or more likely your home router which then forwards you to the internal IP of your NAS).

To enable WebAccess, you have to log in to the administrative interface of the NAS and make a number of choices; NAS name, password (for the Buffalo database), what port WebAccess should use, and if SSL should be used or not. The NAS will then attempt to automatically configure port forwarding on any UPnP enabled router or firewall, or the user can do it manually. After that, the user will have to choose which shares that should be reachable over Web Access, and what access controls that should be used.

Configuring Web Access according to the user manual The problem is that even though there are a number of security measures like file level access, SSL, etc., available, Buffalo seem to have written the instructions in their user manual to produce as few support cases as possible, not to help the user configure the device in a good way. Here is a picture of the admin-panel from which you enable WebAccess, note the placement of the “Read Manual” link. Guess where you’ll click if you are unsure of how to do all this difficult IT-stuff?

When clicking the “Read Manual” link, a new window is opened and the user manual on the Buffalo website is presented:

Going further into the WebAccess setup instructions, the following is presented to the user:

Note bullet number 2 above. Also note that this is the only advice the user is given regarding access control whatsoever. At least in my book, this is pretty damn terrible advice for something that is going on the internet.

The enumeration issue Ok, so what’s the big deal? No one but me knows the name of my NAS anyway, right? Technically yes, although anyone with an internet-connected browser is free to take a guess. Here is what the website for accessing a NAS remotely looks like:

When a NAS name is typed into the box, the server checks its database for a corresponding entry and if found sends a “HTTP 302 Found” response to the browser along with a Location header containg the IP address and port for that entry:

Proof of Concept To get some sort of idea of the extent of this potential issue, I wrote a simple Python script to make some basic checks. What the script does is the following:

1. Check each entry in a long list of names against http://buffalonas.com to check which ones receive a Location header in the reply.

2. For each Location header received, check whether the NAS is actually reachable and if anonymous sharing is enabled.

To check whether anonymous sharing was enabled, all I had to do was check the number of characters in the response’s body. A response from a NAS that has not got anonymous access enabled is always 390 characters, so it was simply a matter of checking if the response was bigger than 390 characters.

This is the result from running the script for about 10 minutes (after which I manually aborted it):

From this, admittedly very short and not in any way scientific, test we can see that out of 36 found devices, 9 are sharing their files with anyone on the internet. This gives us a rough percentage of 25%, which sounds like a lot. Now, it might be that these 25% are willingly sharing anonymously, but I highly doubt it.

Finally When this issue was reported to Buffalo, I suggested that they password protect their website so that users can log in using the NAS name and password chosen when enabling WebAccess. Once logged in, the user would be presented with a link to their own NAS. This would at least make it impossible to perform an enumeration attack on the database as it would no longer be publicly available.

As a final remark I would like to state that I have no idea how many Buffalo Linkstations there are out there, or how many that have WebAccess enabled or with what access control settings. I have tried to find sales figures for these devices but have not been able to so far. However, based on the result of the 10-minute scan above, there seems to be quite a few out there, and my guess is that a fair share of them have followed the poor advice from Buffalo when configuring it.

[3vildata]

Migrating Enterprise ‘Ultra-Legacy’ systems.

This article started as a comment to Wh1t3Rabbit’s post about Ultra-Legacy Problem and Technical Debt. Rafael invited me to turn the comment into a proper blog post, so I’ll be trying to do just that here. This might appear in his blog at some point (edit: here) – in some form or shape. Cross-posting it here for posterity.

The Context

Let’s get the boring stuff out of the way first.

I work for a large automotive manufacturer. We’re somewhere around total of 100k employees and our products include trucks, buses, construction equipment, marine and industrial power equipment, aerospace components, financial services and IT among other things. The IT operation staff is probably somewhere around +5k, globally. We’ve been in business since the late 20’s.

The Project

For the past couple of years I’ve been working on a project of migrating 20 year old B2B-integration ‘ultra-legacy’ system to a new modern platform.

The business driver for the change has been around for a while. The work to migrate from the platform was started six years ago, so project is almost ultra-legacy in itself. The team has gone through four iterations – many of the people originally involved are not around anymore.

The System

The product itself has been unsupported for many years, the company that made it doesn’t exist anymore and the source is not available. It runs on end-of-lifed version of AIX (luckily IBM has been willing to sell extended support). It’s one big monolithic system, where everything is tightly coupled together. It’s also highly customized to our business needs and it’s absolutely and completely business critical.

The system handles messaging and integration between backend ERP’s (plant material planning systems, logistics, just-in-time messages, financial and HR systems etc.) and external partners (manufacturers, aftermarket, invoicing, delivery schedules, shipping notices, logistics etc). In both cases the connecting systems are counted in thousands and yearly message flow in millions of messages. Some of messages are also (of course) time critical, a 30 minute delivery delay will result in manufacturing line hiccups. The general landscape has changed alot since the system was bleeding edge. The business has moved rapidly to JIT manufacturing. Same with logistics and financial transactions. The IT landscape is not about circuit based communications (like X.25/ISDN) anymore, it’s all about the Internet. Application design is multi-threading instead of sequential process and hardware has gone virtual (and to the cloud). New “radical” messaging formats (like, *gasp* XML) have taken over. As you’d expect from a 20 year old system, it doesn’t really “get the Internet”. It can do (O)FTP and poll e-mails from a POP3 server, but that’s about it. It’s also buried so far back in the network topology it has to chain communications with several more recent systems to reach out.

All messages are processed sequentially resulting in huge “batch runs” and any configuration change (like adding a new integration) takes at least 24 hours, because the system needs to reload the config file every time. Reading in the current config file takes about 2 hours and the system needs to be offline during that time. This used to be OK when dealing with plants in one time-zone, but these days our “night” is someone elses prime-time for production.

So in short, not really the epitome of our modern Internet based JIT-business system.

Challenges and Lessons Learned

It’s hard to give good advice without getting too generic or too specific. Your ultra-legacy system is probably specifically tailored to your business needs, so any specific advice would miss the mark. It’s like tree-ring dating, your business development is reflected in the layers of your ultra-legacy system and the things that work for my project might seem strange, so take the below with a grain of salt.

Aim High

You’ll want to anchor your project as high as you can in your organization. I can’t stress how important this is. If you can get a C-level decision and backing, you’re going to save a lot of extra work and grey hairs down the line. During your project you’ll discover new stakeholders and system owners who probably don’t even know they’re part of your ultra-legacy landscape. Once you actually start the hands-on migrating, things will break. Having a good backing at the top will help.

Team & Methodology

Keep your core team reasonably small. If your project is going to run for multiple years, large team will cost and is generally hard to maintain for a longer periods. If you managed to anchor your project high enough, you can pull in area experts from different teams when you need them.

As for methodology, the age-old KISS approach applies here. It’s a complex matter, but your job is to keep it as simple as possible. Cut through the system until you have small enough components, then use those to design your migration strategy. Use Agile and Lean or whatever method support you happen to have around – the basic idea is: Don’t do big monolithic plans or project cycles. Small iterative changes are easier to manage and easier to test.

Also, on the soft-skills side – the people in your team are going to face both organizational and technological challenges before they can celebrate even smallest of victories, so go lightly on the core team, you don’t want to wear them out.

Tech

Spend some time gazing into your crystal ball. Your migration project might run over several years, you don’t want to deliver your new shiny system and realize it’s already antiquated legacy. Your ultra-legacy system is probably a somewhat monolithic and tightly coupled, that’s why no one has migrated it until they absolutely have to. Don’t do the same mistake twice.

Select modular, easily extensible replacement systems with loose coupling – that way you’ll minimize legacy/technological debt in the future. Generally – use whatever works on the Internet (in terms of protocols and tech) – it’s usually well tested and well supported by multiple vendors.

There is no magic boxed set that will solve all your problems, select your vendors carefully and check if they actually have practical experience from legacy migrations. Make sure your vendors understand what they’re getting into, they’re used to selling their wares and GTFO. Don’t let them off the hook – make them part of your process (again, your friends high-up in the organization will help here).

Security

You might want – or be expected – to migrate everything as a ‘black-box’, but most likely you can’t. Your policies have changed and your risk and threat scenarios are most likely quite different now compared to what they were 20 years ago. You will need go through them and apply your current requirements to your new system. You’ll need help from your security org, pull them in and make them part of your new design, the earlier the better.

Test

As another poster pointed out, managing your test scenarios and cases is the hardest part of the whole process. Creating good tests requires business knowledge (why does it do what it does?) and tech knowhow (how does it do what it does?). As above, in many cases, the expectation is a clear ‘black-box’ migration. Unless your organization has very deep pockets, it’s not really feasible and it can end up being very expensive. Create strategy (you can’t test everything, what are you going to test?), tools (automated testing is a must) and talk to your friends in high places – make sure everyone understands and accepts the potential risks and is willing to back you up.

Information

Information is very important factor. Make it a habit to visit random stakeholder departments, support organizations, customers and just generally anyone willing to listen. Have your presentation ready and rehearsed. The more awareness you manage to create, more support you manage to drum up – the easier time you will have dealing with your customers and organization when things break (and things will break, it’s unavoidable) once you’re down to the actual war-room, hands-on migration part.

Hope the above article provided some food for thought. Good luck with your ultra-legacy migration.

[3vildata]

All The Small Things

Details, details, details. Aren’t details just so annoying? Just when you thought you were finally finished with that server, a small configuration detail pops up and you have to go back and fix it.

Or perhaps just ignore it. Someone else will probably fix it. And maybe someone else will. Eventually.

Today I want to talk to you about web server configuration. And details, of course. So miniscule details that most people don’t even realize they’re there. But as a Certified Security Professional, you should know better, right?

The configuration detail I want to talk about is called DirectoryIndex in the Apache web server. The same detail exists in other web servers, but I’ll go with Apache in this article as it’s reasonably popular web server on the Internet (and relevant to our example below).

So what is this DirectoryIndex then? To borrow the Apache documentation:

The DirectoryIndex directive sets the list of resources to look for, when the client requests an index of the directory by specifying a / at the end of the directory name.

So basically, when someone types in  http://www.example.com/solutions/ in their web browser, your web server needs to figure out what to send back. By default it would just send back a list of files in that directory. But using DirectoryIndex you can tell it to look for page names. So if your DirectoryIndex would look like this:

                             DirectoryIndex index.html index.php index.pl

Then your web server would look for and return the first it finds:

http://www.example.com/solutions/index.html

http://www.example.com/solutions/index.php

http://www.example.com/solutions/index.pl

..in that order. If you know your site is written in PHP, you could have just said:

DirectoryIndex index.php

..and the server would have sent you the index.php page in that directory.

So – let’s say your DirectoryIndex looks something like this:

                             DirectoryIndex index.php index.htm index.html

Maybe your page uses PHP and you’ve read googled that you really should include index.php in your DirectoryIndex to Make It Work. And perhaps your web designer prefers to work on Windows, where three letter file suffixes are quite common (.htm) and perhaps that .html was there by default and you didn’t want to remove it?

Fairly common setup I’d think and reasonably innocent at first glance.

So just to make things more interesting:

Let’s say you’ve been hosting your page at a $Provider Web Hotel. Let’s also go a bit wild and crazy and say that the said Provider got hacked and the evil hacker replaced all index.php pages with their own “elite-greetz” page.

You know, a bit like that TiGER-M@TE hack back in 2011.

That hack defaced massive amounts of websites by replacing the index.php page with the hackers own page. The hacked page then tried to install malware dropper on visitors system.

Cleaning up that hack was straight forward – delete all index.php files from your site and restore your own from latest backup. And the servers serving the malware got closed long time ago.

So why am I bringing this old hack up now in a post about DirectoryIndex details?

Update (November 2012)! Code Green Networks finally fixed the issue described below – well over a year after the actual exploit.

Because last week, I was reading about software vendors who sell DLP (Data Loss Prevention) software and I happened to stumble upon Code Green Networks site.

Their solutions seem quite nice. Oh! I hope you noted that the page you’re looking at is called index.htm.

Now – I wonder what page would I see if I went to http://www.codegreennetworks/solutions/?

If the folks setting up the website had ever gone back and fixed a small detail of DirectoryIndex configuration, you’d see that very same index.htm. But of course they didn’t. No one ever does. Details.

So the web server loads index.php. Can you ever guess what the index.php is? – well here’s a cached screenshot, in case you don’t feel like checking the link on your own.

And yes, looking back, it seems they indeed got stung by TiGER-M@TE hack. Back. In. September. 2011.

And they’ve since then switched hosting to Amazon cloud, but not even site migration was cause enough to trigger a review. And why should it, it’s just a detail.

I feel like I could launch into a Huge Rant on the tangent of  “how the hell are we supposed to make things more secure and people listen to our advice if we can’t even keep our own backyard clean!11!”

But I digress.

It’s all just details.

Ps. If anyone thinks it’s unfair/unethical to “name and shame” – I mostly agree and I believe in (Somewhat) Responsible Disclosure. Sometimes hacks happen, regardless of your Best Efforts to secure yourself. This is why I reported the incident to them a week ago. Received automated support ticket number but no other reply. The page is still there. But then again, it’s been there since Sept 2011. Just a small detail.

About the Author - (0 Posts)

[3vildata]

That Samsung Remote Wipe Show

Internet in your pocket is fantastic. Combined internet, messaging platform, calendar and entertainment center is even better. Except when you happen to surf to a page that has malicious iframe embedded with following code

<frame src=”tel:*2767*3855%23″ />

If your pocket Internet device happens to be not entirely updated Samsung (S2, S3 and other models), then you’ve just wiped your fantastic pocket of information and performed a factory reset. Hope you had a backup.

Now it’s important to point out that Samsung has already fixed this flaw while ago – so if you’re running up-to-date OS (v4.0.4 and later), you should be safe. If not, go and hit that Update button right now.

Even though you’re now at least potentially safe, the bug is interesting enough for a quick safety demonstration – and perhaps more importantly for a quick reminder of why selecting sensible default settings in your software design is extremely important.

So what makes the this exploit tick? Two things

The USSD code which executes immediately after you type in the last character. Normally you key in one of these codes and then have to hit the “Dial” button in order to execute it. A bit like hitting enter for executing command on your computer. This one doesn’t need it, it just runs automatically after the last character.

Your browser has a URL protocol-handler that is configured to execute your Dialer app as soon as it sees URL starting with “tel:“. This is similar to mailto: (launches your mail app), file: (launches your file browser application) and itms: (launches iTunes) on your desktop computer. Normally you’d expect to get a warning when your browser decides to launch external apps- but in this case the default in Samsung browser seems to be just the opposite – it just quietly executes the handler and launches the dialer with the wipe code.

So there you go. I made a quick test page here, in case you’re wondering if your mobile is vulnerable. IT DOESN’T USE THE WIPE CODE, it executes following:

<frame src=”tel:*%231234%23″>

Which displays version information. But by all means, visit the page with your desktop browser first to verify (view source) before you rush there with your mobile browser.

Problem here is that you can’t do very much about the USSD code. It’s sort of brain dead to have a code that auto-executes, but it’s there and you have to live with it. I guess you could try to replace your Dialer app, there are certainly plenty of alternatives – if you’re lucky, you might find one that prompts before execution – but the chances are, it’s not going to.

Another option would be to de-register that protocol handler from your browser – but again, our browsers are frustratingly good at hiding and removing configuration options from users  – especially so on the mobile devices.

I couldn’t find a way to change the protocol handler in my stock Samsung S3 browser, so again, you’re SOL, as they say.

However, you do have some options!

Opera Mobile has sensible default settings – it suppresses the iframe content and warns you, like a good browser should.

You can also download Firefox – and even though it’s vulnerable with the default settings – you can actually re-configure the protocol handlers and thus at least get a warning before the dialer is executed (select Cancel and live happily ever after).

You’ll have to do some config-foo though – enter

about:config

In your URL bar and then search for

network.protocol-handler.warn-external

Then just toggle the false flag to true. Happy days.

Chrome seems to go ahead and execute the tel: handler by default. The desktop version of Chrome has easy access to protocol-handlers, but the mobile version has hidden them well (I couldn’t find it, please let me know if you know where it is).

So what did we learn from this? Probably not much, but I would hope next time you write code – you give extra thought or two to the default settings you’ve just defined. And please – don’t build in things that automatically execute external things – even though “the process should never get here”.

2012-09-27 edit:

And just to clarify, if the Wikipedia link above wasn’t enough. USSD codes are not new, they’ve been around since the non-smart GSM mobile handsets. They’re not limited to Samsung devices. There’s also no guarantee that one USSD code will work everywhere as there’s no standard for them. So even if you’re totally and completely running the latest patches available for your device or perhaps not running a Samsung device at all  – you might still be vulnerable (especially true for older Android segment as they’re generally not upgraded to ICS/JellyBean). iPhone has USSD codes as well, but they’ve done the sensible thing and disabled the URL protocol handler in their Appstore, so you can’t trigger the codes  with tel://code/ sequence from webpages (I don’t have iPhone to test with though, so don’t take my word on it).

Also, I tested this on my daughters Samsung Galaxy S2 which has F-Secure’s mobile AV scanner installed – the scanner blocked the page. So that might be one additional way to protect your mobile, if you’re out of other options. I’m guessing other AV scanners have similar functions – but I have rather limited “test-lab”.

About the Author - (0 Posts)