So is it true that malware for Firefox OS has been found?

Thursday, October 24, 2013

The power of a good headline is hypnotic. The one taking a lot of security news during these days is the "Found first malware for Firefox OS". The title is attractive, but, is it right? Reading the news invites to think about what has really happened, what is this "discovering" about, and why we haven't overcame still so many myths.

Firefox OS is a recent operative system based on web. All its programs are web based, created using JavaScript, CSS3 and HTML5. This implies that applications may be distributed in two ways: in a zip that contains it all, or via an URL that hosts it and is later visited.


A 17 years old by has developed a malware proof of concept for Firefox OS. He will be presenting its research in a convention in November. He states that his application allows to perform some potentially unwanted remote tasks over the device, and that is able to control it sending remote commands.

First of all, security model


According to Firefox OS security model"uses a defense-in-depth security strategy to protect the mobile phone from intrusive or malicious applications. This strategy employs a variety of mechanisms, including implicit permission levels based on an app trust model, sandboxed execution at run time, API-only access to the underlying mobile phone hardware, a robust permissions model, and secure installation and update processes". So far (except the way hardware is accessed), nothing that any other operative system doesn't implement (and nothing that really may stop "infections").

https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Security/Security_model

Something that, in some way, may make a difference in Firefox OS, is how it classifies permissions in apps. There will be three different kinds:
  • Certified: the ones installed by the vendor and critical functionality (telephone, SMS, bluetooth, clock, camera...). They will be able to access any API. For example, only certified apps (the ones coming with the device) will be able to make phone calls.
  • Privileged: The ones reviewed, approved and digitally signed by an authorized marketplace. They will have access to a subset of APIs accessible to certified ones.
  • Untrusted: The other ones that will not be in a market. These will have only access to a subset of APIs that may not make any harm.
Let's see now what can be deduced from the announce of the program created by Shantanu Gawde.


Differenciate between the "what" and the "how"

A teenager has created an application that makes unwanted actions on the system. He talks literally about "infecting" and "control like a botnet". About sending commands to access SD card, about "spooking the user remotely controlling FM radio", "upload and download multimedia files". It seems to be able to control certain device apps, but we do not know how far it may go.



Official description in http://g0s.org/key-focus-areas/
Is this malware? It depends. There will be legit applications that will need to access SD card data, contacts, etc. It will be allowed because the user will trust the vendor or developer. As the Firefox OS security description document states, the model is based on application trust.

What may attract some attention is the state about controlling other apps (he specifically talks about controlling FM radio). Talking about "sending commands" invites to call it "malware", too, though, once the application is installed, it seems quite easy to send commands... so in general, the problem is not so much "what" does this proof of concept do, but "how", how does it get the necessary permissions and how it got to get them. With the information we have, we guess the user launches an application hosted in a server and accomplish some tasks that may be potentially unwanted by the user.

More questions than answers

To get to the real scope of the statement, we should answer these questions.

  • Is this program able to bypass some security restriction in Firefox OS? This would include elevation of privileges, accessing without permissions to privileged API, bypass security dialogs, warnings that could alert the user... any way that implies bypassing, breaking or evading Firefox OS security model. It seems to do that, but it's not clear.
  • Does the malware replicate itself in some way, for example leveraging some vulnerability or design flaw? Does not seem so. If Gawde had found a way to spread a program without human interaction, that would have been breaking and disturbing news. But, with the information we have, it does not seem to be the case.
  • Does the malware hide itself in some way, for example in legit apps? It does not seem so, either. It would have been interesting if a way of launching hidden or embedded apps had been disclosed, just as the first "virus" did. What may be a problem with Firefox OS is, that confusing or obfuscated URLs hiding apps would execute just with a click... and that has been alerted since long ago.
  • Are special circumstances needed for the proof of concept to work? Are just some devices vulnerable?, Does it work with default configuration? Or is is necessary to keep some service, or app working...?
  • Does it use any technique to hide its execution from the user? Something that attracts attention is that the developer itself says "there is no way to detect the attacks or even stop them". In security, such convincing assertions are usually misguided. We suppose he refers to a model where an URL is visited and it results in an app executing that starts, without user interaction, some information exchange between the "victim" and the attacker, that may control the device.
Without these answers (between others), information may be based just on speculation. And the developer should have answered them beforehand in his statement, just like others do, so we can understand (without the need of technical details) how he got it and not describing so much what he got. It should be highlighted that he states that the purpose of the PoC is of course to motivate developers to ensure better security on their platforms rather than providing inspiration to those with malicious intents.

Anyhow, the "malware" or any other in the future will not be exactly a surprise. When execution of uncontrolled applications and alternative "markets" are allowed, abuse is practically guaranteed. Although it's through restricted applications, many of them will not need special permissions to infect with "adware" and show ads, and some other may just find some ways to bypass permissions leveraging vulnerabilities or design flaws.

A Firefox OS spokesman states that possible, Gawde relied on 
developer mode functionality, which is common to most Smartphones but disabled by default. In addition, we believe this demonstration requires the phone to be physically connected to a computer controlled by the attacker, and unlocked by the user. In other words, they think he has "cheated". Of course, they try to downplay the issue because of the lack of information.

So, without any more actual data, the headline should be that a researcher has possibly found a design flaw or a way to bypass some security in Firefox OS, executing privileged remote actions on the device. But we can't be sure yet. What is for sure is that, talking about "malware" confuses the user, that may feel menaced without an actual reason to... yet.



Sergio de los Santos
ssantos@11paths.com

How to use Metashield protector for Client and why using it

Monday, October 21, 2013

Metashield is an Eleven Paths product that allows to clean up metadata from most of office documents. It tries to cover a gap where there seems not to exist any unified solutions to remove all metadata from documents.

Why is it so important to remove metadata?

In 2003 Tony Blair presented a report in the british upper house, received from US intelligence service. It was supposed to be an undeniable proof of the existence of weapons of mass destruction in Irak. The prime minister denied that the document had been manipulated or modified in any way by the British government. Nevertheless the document was released in the government's webpage and metadata revealed a list of certain users that proved that it had been manipulated by British government staff.

On December 2010, a document released as a press notice from AnonOps (Anonymous Operations) showed a name in its metadata. It was the graphical designer Alex Tapanaris, that was put under arrest because of his relation with Anonymous.

A "defacer" that hacked some official United States webpages, published some photos of his girlfriends neckline, mocking with impunity. He forgot to clean up the metadata and his GPS coordinates where found inside the photo. The FBI arrested him.

In December 2013, John McAfee was on the run from the Belize police when declared as a "person of interest" after one of his neighbors was found shot to death. Some journalist showed a photo boasting of being with him. Metadata revealed his exact location. 

How to clean up metadata?

Metashield Protector For client  is a tool to remove metadata in a fast an effective way. It creates a copy of the document, so the original document remains untouched. Eleven Paths has developed this tool for Windows environments, and is able to remove metadata from Office, Open Office, StarOffice, Pdf, Jpg and even iWorks Apple documents. It is enough to spot one or several documents in the computer (or inside of a shared network directory) and remove the metadata with a mouse-click.

This tool allows to select two kinds of "cleaning":
  • Clean keep original files: It generates an exact copy of the document, with no metadata keeping the original one untouched. 
  • Clean Metadata: It removes the metadata from the original file.

The speed of the process depends on the number of selected documents and their size.


The examples mentioned before, show how unknown metadata is, and how metadata can be reached in digital documents by anyone in the net. On the other hand, a metadata-free document implies professionalism, responsibility and dedication from its owner, not disclosing any kind of sensitive information aside from the strictly necessary.

How to take advantage of Chrome autofill feature to get sensitive information

Tuesday, October 15, 2013

At the end of 2010, Google introduced autofill in Chrome, a comfortable feature, that may be a security problem for its users. Even after some other browsers suffered security problems related to this feature, and the feature itself were questioned, it is still possible to steal information stored from the user filling up a form, without him to notice.

As a rule of thumb, storing sensitive data in the browser is not a good idea. Just before Chrome implemented autofill, during 2010 summer, it was discovered how to disclose data stored in Safari, by bruteforcing with JavaScript. The user filled up an input field but the browser was able to rescue all other stored data pieces, just by trying letters and letting the browser do the rest. The vulnerability was patched short after. Not long ago, in 2013 summer, it was hardly discussed how easily you could recover passwords stored in Chrome, which could be viewed in clear text.

With an easy method, a user may give unconsciously his data to a third party, just by filling up an innocent form.

How does it work?

Chrome’s autofill allows to store postal addresses (divided in some other data like name, surname, telephone, postal code...) and credit card (divided in cardholder name, number and expiration date). Every data piece (except credit card) can be synchronized with a Google account. The configuration menu and how to get to it, may be observed in the following image sequence.



Different autofill configuration screenshot in Chrome
For a form to take advantage of autofill feature, input fields has to be properly identified so Chrome knows what values go with them.


It relies on some heuristics for the fields to match. For example, it knows that autocomplete="mail" should be autofilled with the same content that autocomplete="Work email".

The "attack"

An attacker may take advantage of this characteristic to obtain private information like an address or credit card data. We set out a scenario where the victim visits a specially crafted https web page, fills up some data, and the attacker uses browser's autofill to get stored sensitive data. And this, despite the easy-to-bypass obstacles that Chrome introduces in its code to avoid this situation.

For example, as a precaution, Chrome only fills up credit card number with autofill under https pages. This is not a problem for the attacker, since he just have to operate from a SSL connection. There are fraudulent webpages that work with certificates issued for free.

The second step is to set up a form and hide the inputs the attacker is interested in from the user. First idea is to use a "hidden" tag. But it’s forbidden in Chrome. A second idea would be to introduce the form inside a div tag with visibility set to "hidden"... but Chrome avoids to autofill inputs under this conditions. How to get it then?

A formula would be to take advantage of the scroll property, rising up the layer some pixels so the inputs used to steal information are unseen. In this case, the "decoy" form would be:


By using this specially crafted "div", we get to hide inside it all these inputs and the browser will not show them (but will autofill them):

div style ="overflow:hidden;height:25px;"


Chrome will fill up all that information without the user noticing anything. The attacker, may pick up the information and get much more information than the user thought he had given.


In summary, although it is comfortable to use (for systems used by a single person), autofill should be avoided since it is proven to be a risk. A victim could offer to any https webpage sensitive data such as credit card number and expiration date, without the victim noticing.

To avoid this problem (or any other potential one in the future), the best remedy by now is to simply not use this functionality.

Ricardo Martín Rodríguez
ricardo.martin@11paths.com