Eleven Paths with Latch, in Campus Party Brazil

Sunday, January 26, 2014

This year is the seventh edition of Campus Party Brasil, that will take place in Sao Pablo, Brazil. For Eleven Paths, it will be a very special week in the Campus: a Hackathon will be organized,  where the contestants will put to the test the possibilities of our new Latch technology. Our Argentinian CSA, Claudio Caracciolo, from Eleven Paths, will give a presentation together with Leandro Bennaton about CiberSecurity on January 28th.

Hackathon is born as an intend of Telefonica to generate a meeting, fun and learning place, based on the development of applications from Latch's API, in order to integrate it to other platforms, or to give it different uses taking full advantage of its potential. The target is to generate new applications or implementations using Latct's API, (which is perfectly documented on our website), on purpose to get the most out of the tool and of the imagination of the assistants to Campus Party Brazil 2014

We hope really different applications will be developed at this edition of Hackathon, that is why we have proposed the following topics, not mutually exclusive:
  • Access Control for remote control account services to different operating systems, e-mail, CRM´s, etc.
  • Activate or deactivate accesses to administration account of a wi-fi routers.
  • Activate or deactivate SSID broadcast within a wi-fi net, or just turn on/off the net.
  • Activate or deactivate ignition key of a car, or make sure the car will not be turned on at certain range of hours.
  • Activate or deactivate a TOR, VPN, or Torrent client; or program a schedule in order to make it run under specific conditions or certain hours. 
  • Enable or disable RFID type access cards.
  • Activate or deactivate features of other phones or tablets. 
Participants may compete in teams or individually. The results will be evaluated and there will be great prizes for the winners:
  • 1st. place: AlienWare laptop.
  • 2nd. place: A tablet (Ipad or Galaxy)
  • 3rd. place: A Smartphone (Iphone 5 or S/note3)
The steps to participate in the hackathon that will be held since today, January 27th to January 29th, are:
  • Register for Campus Party to be able to access to the event.
  • Register for Latch Hackathon on https://www.elevenpaths.com/cpbr7
  • Access https://latch.elevenpaths.com and create an account and register for free, if you had not done it before.
  • Read the API documentation.
  • Develope based on the conditions and rules of Hackathon, , available on : http://www.vivo.com.br/campusparty 
Good luck to all contestant. We expect great ideas and contributions.

Metashield videotutorials... now on YouTube

Tuesday, January 21, 2014

Nowadays, most common information leaks occur through unseen channels such as metadata and unseen document information. Through these externally shared documents it is possible to obtain critical data from an organization that can allow an attacker to fingerprint its assets and computer network. The consequences of this leak may have economic impact and the organization reputation can be seriously harmed. Metashield is our bet to solve this.

Metashield Protector lets you configure a security policy of metadata in the documents you are serving outside your organization. It provides a holistic solution to control the information leaks through its product portfolio.

We have uploaded some Video tutorials to Youtube, with English subtitles, to make it clear how easy to install and use they are. We have different videos for different solutions.

Metashield for IIS 

Server based solution for sanitizing documents on the fly as they are served to users by Microsoft IIS web server. It deletes or replaces documents metadata on the fly, offering a normalized public image of the organization.



Metashield for File Server

Sanitizes documents hosted on file servers (FTP servers, etc.), automatically deleting their metadata and hidden information and optionally replacing it with the desired one.


Metashield Forensics

Do you suspect you have a compromised system due to unauthorized access to internal files and need a forensic analysis? MetaShield Forensics extracts digital and time-stamped evidences available in metadata for a later forensic analysis.



Metashield for SharePoint

Cleans data served by Microsoft SharePoint Servers. If your company provides ECM (Enterprise Content Management) services based on SharePoint this server based solution helps you prevent inadvertent information leak.




Metashield for Client

Professional solution for workstations. It allows to remove metadata from files, just right clicking on them. Ideal to clean files before sharing them with someone else.


How to bypass antiXSS filter in Chrome and Safari (discovered by ElevenPaths)

Monday, January 20, 2014

Modern browsers usually have an antiXSS filter, that protects users from some of the consequences of this kind of attacks. Normally, they block cross site scripting execution, so the "injected" code (normally, JavaScript or HTML) is not executed inside victim's browser. Chrome calls this filter XSSAuditor. Our coworker Ioseba Palop discovered a way to bypass it months ago. Since it is already resolved in the "main" version of Chrome, we are publishing technical details now.

In ElevenPaths, we just found a way to evade XSS filter in Chrome. This means, if the victim visits a website with an XSS problem that an attacker is trying to take advantage of, it would not be fully protected. The  bug  is  based  on  a  misuse  of  srcdoc  attribute  of  IFRAME tag,  included  in  HTML5 definition.  To  perform an  XSS  attack  on Google  Chrome  Browser  using this  bug,  the website must  include an IFRAME and must be able to read any attribute of this element from HTTP parameters (GET/POST) without applying any charset filter. Then, in the IFRAME parameter,  the  srcdoc  attribute  may be included with JavaScript  code. Chrome cannot filter it and will be executed.

To reproduce the PoC, there should be a webpage with some IFRAME tag like this:



And an HTML injection on src parameter would be:


and XSS filter will fail and let the script run.


Google derived this to Chromium, who does not treat this bypasses as a security problem, since XSSauditor is considered a second defense line.

The problem was reported in October, the 23rd. They fixed it two days later, making XSSAuditor catch reflected srcdoc properties even without an "IFRAME" tag injection. Chrome has just fixed it in recent 32.0.1700.76 version.

Some other bug

A few weeks ago, in this post, someone took our PoC as an inspiration and developed another way of bypassing the filter. This one is still not fixed. The trick is to inject an opening "script" tag inside a parameter that is written directly in the HTTP request output stream. This is, without filtering any character just as our case. In this writing there should be content inside scripts tags that belongs to the web itself.



The browser will include our injection (remember, without closing the tag), omit the "script" opening tag from the web itself, and now, use the closing one from the web to create a well formed script and execute it... this is the bypass.




Safari, still vulnerable

Safari for Mac and iPhone is vulnerable as well. They confirmed our email, and told us they were working on it. And seems that they still are, since the program is still vulnerable. Everytime we have tried to contact back with them again, they reply back telling there is no news, but they are working on it. Internet Explorer filters it with its own filter, and Firefox does not implement an XSS filter by itself.

Banking trojan I+D: 64 bits versions and using TOR

Tuesday, January 7, 2014

Malware industry needs to improve and keep on stealing. So they research and invest. There are two different ways of investing if you are "in the business": one is investing in new vulnerabilities so you can infect more efficiently. This is complex and will not talk about that in this post. The other side to invest in, is how to steal more efficiently once the victim is infected. What have they done about it lately?

Which is the most lucrative banking trojan?

There are millions of banking trojans. More that you can probably imagine, and more than the antivirus companies can handle. But most of them have quite a lot in common. Basically in their targets (stealing, the more the better) and in the way they break into a system and keep the infection. 


If we simplify a lot, the most lucrative banking trojan is the one we call "ZeuS" or "Zbot", born in late 2005. Zeus, depending on who you are talking to, is one thing or another. Its story is long enough to cover code leakages, mutations, copycats... For this article, ZeuS is basically a philosophy and a template. A "template" because it allows, with a program, to create a banking trojan targeting bankings on demand, with its own syntax and some rules. A DIY kit with very advanced features. It is also a "philosophy" because of the way it steals, that may be considered a standard nowadays. ZeuS consolidated a style in banking trojan. What it does, and the basis of its success is (among mucho more things): 
  • It injects itself in the browser, so it can modify what the user actually sees in the screen. It injects new fields or messages and modifies the behavior or sends the relevant data to the attacker. 
  • If not injecting anything, it captures and sends all the outgoing https traffic to the attacker.
In this way and with this basic structure, ZeuS (as a concept) is alive and kicking for 8 years now. There is some more malware with different names, but fundamentally, they follow some of this style patterns.

Browser usage. 64 bits Chrome version is under developing in Windows. 64 bits version for Firefox for Windows was even cancelled for a while.
What are they investing in?

ZeuS has evolved technically, but maintaining same basic structure. Is there an "official"  ZeuS branch? Yes, you can buy it, but there are forks and other variants that became standard. Some features appear from time to time and some group of attackers adopt, copycat or buy them.

Focusing on latest changes, the most significant observed are:  Using TOR to communicate to Command and Control Servers and Zeus compiled directly for 64 bits. Although not seen "in the wild", this improves dramatically ZeuS capabilities.

One of the weak points (and advantages, in a way) of ZeuS (and malware in general these days) is that it strongly depends on external servers. Once these servers are down, the trojan becomes mostly useless. To solve this, so far they have used dynamic domains, domain random generator, fast flux playing with DNS, bulletproof hosting... and all these techniques are ok but they result expensive. Using TOR and .onion domains gives them "inexpensive" strength. Shutting down this servers will be very difficult for the good guys, and easier for the attacker to keep than any other "resilient" infrastructure used so far.


On the other hand, creating a 64 bits native version requires some clarification. Today, most of Windows system are 64 bits. In this architecture, 64 and (most of) 32 bits applications (except drivers) can run without problems. That is way today most of programs are compiled for 32 bits, so they can run in XP (with a not very used 64 bit version) and any other Windows (mostly 64 bits). So developers create 32 bits versions for all of them to ease compatibility. So does malware. Today, even with a 64 bits OS, browsers are still 32 bits (even IE, that comes in this two flavors in latest Windows). The reason is being compatible with plugins and extensions that are still 32 bits. So, why creating a 64 bit version of malware? Just because they can. They are maybe experimenting right now, for the near future. In fact, the 64 bit version have been detected "inside" a 32 version. This means that, once infected, it uses one or another depending on the browser. They will find very few people using a 64 bits browser (Kaspersky says only 0,01% of desktops are using native 64 bits IE), but that few is a market they do not want to refuse to, and when it raises (browsers are making efforts to have native 64 bits versions that will end up imposing) they want their software to be ready.

There is maybe another reason. Using 64 bits versions makes them even more unnoticeable for sandboxes in antivirus companies. This is the first step for most of AVs that goes through this detection circuit: sandbox, and, if suspicious, deeper analysis and, if even more suspicious but not classified yet... manual analysis. XP is still very used as a sandbox. 64 bits version of malware will not work there, and will go probably as a corrupted file. But this depends much on their resources and the way they work.

What that this changes mean?

That banking trojan developers do not fear users and just a little bit the AV companies... Their only limitations are their own technical skills. If they want to, they can be even more proactive than any other industry. And that they want the whole cake of users with every single nickel they have.

Sergio de los Santos