Google Gears has two important modules, the LocalServer and the Database. The Database module is used to store data in a relational database stored on the user’s hard disk and accessible via JavaScript. The LocalServer is like an advanced cache, where files can be stored and served locally.
In a browser phishing attack the attacker might be able to serve content as an 'http' site that is permitted by the victim to use Google Gears. By running JavaScript as mail.google.com for example, an attacker can read the entire inbox of a Gears enabled user, same goes for MySpace private messages as well. Both these sites use ‘http’ for Google Gears which makes these kind of attacks possible. The Google Gears implementation of MySpace is flawed, the data stored in the Google Gears database is returned to the user without proper encoding, resulting in a persistent XSS. This is probably the first publicly disclosed vulnerability where Google Gears is involved in a XSS.
The LocalServer allows an attacker to cache any file on the browser of the victim for a specific site. For example he could cache a file like 'http://mail.google.com/gearsBackdoor.html' in the LocalServer of the victim with malicious content. The attacker can call this page either by sending a link to the victim or by loading it in an iframe when the victim visits his website. When that happens the page is served from the LocalServer and the malicious content is executed in the context of mail.google.com. A more advanced attack would be to place a backdoor in the same name as a file that is part of the website. This way every time the user logs in to the website the backdoor would be called automatically. Obviously this kind of an attack can have serious consequences for the victim.
I have enumerated seven different types of backdoors that can be placed with Google Gears. Details of these techniques will be available in a whitepaper that I would release soon. Imposter can be used to both steal database contents and place backdoors.
Sunday, November 29, 2009
Breaking the Browser Sandbox and stealing some files
If you are using Internet Explorer and if it has the flash player plug-in installed then an attacker can steal files from your local file system through the browser. For this attack to be performed the victim and attacker should be part of the same private network, the best candidate for this is unsecured WiFi hotspot.
The attack is possible because of some unique characteristics of Internet Explorer and Flash player which in isolation don’t create so much of a problem. But you put them together and you end up with a real killer.
Internet Explorer will automatically load any resources from network shares with anonymous read access, it does not prompt the user for permission. If any website includes an iframe to a resource from a network share then it is loaded.
Flash files loaded from network shares can read files from the local file system even if they run within the browser. Such files must have the "Access local files only" setting for "Local playback security".
Though they can read files all networking capability for these files are restricted, well almost. Since the flash player considers network shares as local file system, flash files can read files placed in network shares as well. Reading a file from a network share requires making a SMB request over to the server containing the share. This request carries the name and location of the file to open, this can be of a maximum length of 259 bytes.
This feature can be used to send data as well by putting the data in the SMB request. For example a flash file from an anonymous share on the attacker's computer loads in the victim's browser in an iframe. This reads files from the victim's local file system and breaks down the file contents in to smaller chunks less than 259 bytes each. Now the flash file attempts to read files from the attacker’s anonymous share but instead of specifying a valid filename it gives one of the chunks as the filename. Now this chunk goes to attacker's system in a SMB packet. The attacker can sniff these packets, extract the chunks and assemble them together to get the entire file content out. It is possible to transfer data at the rate of 234.24 kbps using this technique.
Imposter can perform this attack but it has a slightly lower transfer rate since it includes some metadata in the request to help in reassembly. The whole attack is silent with no user interaction or alert. I would be giving more details on this attack in a whitepaper, should be out soon.
The attack is possible because of some unique characteristics of Internet Explorer and Flash player which in isolation don’t create so much of a problem. But you put them together and you end up with a real killer.
Internet Explorer will automatically load any resources from network shares with anonymous read access, it does not prompt the user for permission. If any website includes an iframe to a resource from a network share then it is loaded.
Flash files loaded from network shares can read files from the local file system even if they run within the browser. Such files must have the "Access local files only" setting for "Local playback security".
Though they can read files all networking capability for these files are restricted, well almost. Since the flash player considers network shares as local file system, flash files can read files placed in network shares as well. Reading a file from a network share requires making a SMB request over to the server containing the share. This request carries the name and location of the file to open, this can be of a maximum length of 259 bytes.
This feature can be used to send data as well by putting the data in the SMB request. For example a flash file from an anonymous share on the attacker's computer loads in the victim's browser in an iframe. This reads files from the victim's local file system and breaks down the file contents in to smaller chunks less than 259 bytes each. Now the flash file attempts to read files from the attacker’s anonymous share but instead of specifying a valid filename it gives one of the chunks as the filename. Now this chunk goes to attacker's system in a SMB packet. The attacker can sniff these packets, extract the chunks and assemble them together to get the entire file content out. It is possible to transfer data at the rate of 234.24 kbps using this technique.
Imposter can perform this attack but it has a slightly lower transfer rate since it includes some metadata in the request to help in reassembly. The whole attack is silent with no user interaction or alert. I would be giving more details on this attack in a whitepaper, should be out soon.
Browser Phishing Explained
With SecurityByte and OWASP AppSec Asia behind us, it’s time to publish the technical details of my talk. I will be doing it over a few blog posts. In this post I will explain what Browser Phishing is and why this particular term was chosen.
Any attack that exploits the browser's reliance on the ‘SameOriginPolicy’, to extract data controlled by the browser or compromise any feature of the browser without need for any user interaction or input can be called as Browser Phishing. Typically this would mean attacks on browser components that use ‘SameOriginPolicy’ as a means of access control. This includes, cookies, LocalSharedObjects, remember password feature, browser cache, Google Gears Database and LocalServer modules, HTML5's Session, Global, Local and Database Storage and Application Caching and other similar components. Browser phishing can be performed normally when the attacker is able to manipulate the victim’s DNS or HTTP traffic.
There are three primary circumstances under which browser phishing can be performed, these are:
1) Attacker has performed DNS cache poisoning on the DNS server used by the victim.
2) Attacker is able to perform MITM on the victim's HTTP traffic. Active MITM attack would fall in this category.
3) Attacker has control over the victim's gateway, typical example is an attacker controlled wireless access point. Karmetasploit and Imposter make use of this technique.
4) Attacker is able to poison the proxy’s cache through HTTP Response Splitting
The term ‘Browser Phishing’ is apt because this is a phishing attack against the browser. In a traditional phishing attack the user is duped in to believing that an attacker controlled site is the legitimate site. Attacker achieves this by designing a fake site that looks exactly like the original site and suitably masks the URL. Users identify a website based on its looks, this trust is abused to extract information like username, password and credit card details from the victims. Browser trust a site based on its domain name, when an attacker is able to make use of this trust and serve his malicious content under the legitimate domain name and extract data from the browser or abuse other features of the browser like placing backdoors then it’s a phishing attack performed against the browser and hence browser phishing.
This is a very old attack and Karmetasploit, which was released in 2008 can perform the cookie stealing and saved form data stealing attacks out of the box. It can be extended to perform attacks on the other components as well. Inspite of this there is very little attention given to this vector, largely due to the assumptions of limited impact and less probability of execution. In today's scenario such assumptions are completely misplaced. With Google Gears' and HTML5's client-side features, the impact of such an attack is equivalent to that of an account compromise if not greater. The extremely frequent use of public Wi-Fi based network access trend has greatly increased the probability of this attack being executed successfully. This vector should be taken into consideration when designing and developing applications and during security audits.
Any attack that exploits the browser's reliance on the ‘SameOriginPolicy’, to extract data controlled by the browser or compromise any feature of the browser without need for any user interaction or input can be called as Browser Phishing. Typically this would mean attacks on browser components that use ‘SameOriginPolicy’ as a means of access control. This includes, cookies, LocalSharedObjects, remember password feature, browser cache, Google Gears Database and LocalServer modules, HTML5's Session, Global, Local and Database Storage and Application Caching and other similar components. Browser phishing can be performed normally when the attacker is able to manipulate the victim’s DNS or HTTP traffic.
There are three primary circumstances under which browser phishing can be performed, these are:
1) Attacker has performed DNS cache poisoning on the DNS server used by the victim.
2) Attacker is able to perform MITM on the victim's HTTP traffic. Active MITM attack would fall in this category.
3) Attacker has control over the victim's gateway, typical example is an attacker controlled wireless access point. Karmetasploit and Imposter make use of this technique.
4) Attacker is able to poison the proxy’s cache through HTTP Response Splitting
The term ‘Browser Phishing’ is apt because this is a phishing attack against the browser. In a traditional phishing attack the user is duped in to believing that an attacker controlled site is the legitimate site. Attacker achieves this by designing a fake site that looks exactly like the original site and suitably masks the URL. Users identify a website based on its looks, this trust is abused to extract information like username, password and credit card details from the victims. Browser trust a site based on its domain name, when an attacker is able to make use of this trust and serve his malicious content under the legitimate domain name and extract data from the browser or abuse other features of the browser like placing backdoors then it’s a phishing attack performed against the browser and hence browser phishing.
This is a very old attack and Karmetasploit, which was released in 2008 can perform the cookie stealing and saved form data stealing attacks out of the box. It can be extended to perform attacks on the other components as well. Inspite of this there is very little attention given to this vector, largely due to the assumptions of limited impact and less probability of execution. In today's scenario such assumptions are completely misplaced. With Google Gears' and HTML5's client-side features, the impact of such an attack is equivalent to that of an account compromise if not greater. The extremely frequent use of public Wi-Fi based network access trend has greatly increased the probability of this attack being executed successfully. This vector should be taken into consideration when designing and developing applications and during security audits.
Saturday, November 21, 2009
The SecurityByte and OWASP AppSec Asia 2009 hangover
Got back from India's biggest security conference and I have to say it was nothing like what I had expected. The scale was huge, the venue was grand, the talks were informative, the food was excellent, the speakers were great and the crowd was enthusiastic. All of this I expected, I will come to the unexpected part in just a bit. A little about my talk first, there were three parallel tracks and my talk was slotted on the first day with two other very interesting talks by bigger guys (wanted to attend those talks myself but couldn't). Being a relatively lesser-known speaker, I was a little skeptical about attracting enough folks over to my talk. But surprisingly there were quite a lot of people, I think the confusingly framed title of my talk worked in my favor ;). The talk went well, there were a lot of questions. Folks were generally impressed with Imposter and were looking forward to getting their hands on it. I attended most of the talks on the first day, hip-hopping from one to another. The talk from MSRC was very interesting. On the second day, myself and Venky were busy getting things set-up for WWIII, India's first Web Application CTF event. It was scheduled to happen after lunch but we weren’t getting the kind of participation we expected. Probably because most folks were very new to Security Conferences and CTFs. After sometime, we packed up WWIII and both of us headed out to attend the talks. Fyodor's 'From Russia With Love' was very interesting, he has a nice way of presenting things. Also attended the SANS training on Secure J2EE coding, Frank handled the subject extremely well and it was easily one of the best training programs I have taken part so far. Though most of the content was already familiar to me there were a few points to take home. Coming to the unexpected part, naively I was expecting the conference to be a serious affair and speakers to be serious folks. Couldn’t have been more wrong, without revealing too much, I would say that the post conference 'activities' were more fun than the conference itself. Overall it was a great event, I have to congratulate the organizers Nish, Puneet, Dhruv and Bithal on the excellent work done. Nish says it’s going to be bigger in 2010, I can hardly wait!
Tuesday, November 10, 2009
Lust 2.0 talk @ SecurityByte and OWASP AppSec Asia 2009
India's largest security conference, SecurityByte and OWASP AppSec Asia 2009 is happening this November in Gurgoan. It’s being organized by Nish Bhalla of Security Compass along with OWASP Delhi's dynamic duo of Puneet Mehta and Dhruv Soi. They have got a very impressive line-up of speakers pulled in from across the world, many of them are regulars at BlackHat and other big conferences. The exciting part is that my talk has got selected and I would be releasing my research on ‘browser phishing’ there. My talk is titled 'Lust 2.0 – Desire for free Wi-Fi and the threat of the Imposter'.
The talk will primarily cover two attacks:
- Stealing files through Flash and Internet Explorer
- Stealing data and placing backdoors on sites using Google Gears
I would also be talking about the very first Google Gears Database based persistent XSS vulnerability which is still open after private disclosure, yes it would be an 0-day.
Subscribe to:
Posts (Atom)