Yassine ABOUKIR

Security Analyst at HackerOne Inc


CORS Exploitation: Data exfiltration when allowed origin is set to NULL

On septembre 15, 2017, by Yassine ABOUKIR, 0 Comments

The present article will be discussing a particular case regarding exploitation of CORS misconfigurations which I stumbled across during a security audit so I had to dig and research about it in order to finalize a working proof of concept for the client. If you do not have knowledge in this matter I would advise you to read first my previous article in this regards that you can find here.

Each time we test for CORS security flaws we usually fuzz the Origin header in the HTTP request and then inspect the server response to see if they does domains whitelist check or not, otherwise cross-domain requests would have been allowed from any origin, thus opening them to content exfiltration attacks.

In a typical test, this would look something like:

GET /apiakey HTTP/1.1

Host: example.com

Origin: evil.com

Connection: close

 

HTTP/1.1 200 OK

Access-control-allow-credentials: true
Access-control-allow-origin: evil.com

Above response indicates that evil.com has full access to authenticated content. A hacker would then simply send a cross-domain request from evil.com to exfiltrate the APIKey as a result.

However, our particular situation is when you change the origin header similar to the above example but the allowed origin as stated in the response would be different. See:

GET /apiakey HTTP/1.1

Host: example.com

Origin: evil.com

Connection: close

 

HTTP/1.1 200 OK

Access-control-allow-credentials: true
Access-control-allow-origin: null

 

If you carefully noticed, this time our origin was not reflected back in the whitelisted origins so we instead got : null.

Exploiting this particular one is not straightforward and pretty tricky because sending null in the origin header is not practically possible except in two instances:

The request is issued from a file on a user’s computer rather than from a hosted web page which is not very helpful in our case since an attacker would need to upload the exploit page to a server he owns and send out the link to the victim.

 

If a cross-origin resource redirects to another resource at a new origin, the browser will set the value of the Origin header to null after redirecting.

We are interested in the latter. Let us break down the statement for clarification purpose:

Attacker.com sends cross-domain request to http://www.attacker.com/302.php

302.php has whitelisted the attacker and then responds with Temporary Redirection 302 to http://www.example.com/apikey

Cross-domain request from Attacker.com follows the redirect to example.com and sets Origin to null.

Last thing we know, our targeted APIkey will be extracted from the victim’s end and sent back to http://www.attacker.com

Briefly, exploiting similar situations requires passing through a 302 redirection in order to set Origin as null. I hope reading this short article was valuable and helpful to you and if you have any feedback please feel free to express yourself in a comment.

UPDATE: It appears there is as well another way around this particular situation thanks to a friend of mine Arbaz Hussain. It is quite simple and easy than the one I described above. Exploitation would be using an iframe combined with data: just as follows:

This is a pretty cool trick and it does not require much of an effort to carry out. I knew it works for disabling referer header but I had not idea it could work in the case of Origin. It’s not until I published the article that Arbaz reached out to me to share his knowledge, so please feel free to post any feedback or additional information you have below.

 

 

 

 

 

A tale of three bug bounties

On décembre 12, 2016, by Yassine ABOUKIR, 3 Comments

I have been lately shiftless regarding publishing and my recent articles on Infosec Institute were more descriptive than technical. Thus, I decided to write this blog post about three interesting security vulnerabilities I discovered in three programs : (1) PayPal, (2) and (3) are private programs on HackerOne that I will not be disclosing. The security flaws will be in the following order :

  1. Insecure Direct Object References : Partial disclosure of users payment information.
  2. Sensitive Information Disclosure : Users PII disclosure (Including hashed passwords)
  3. PayPal Unvalidated Redirect leading to Potential Cross-Site Scripting (XSS)

—————-

The first vulnerability was found two days before heading to DefCon 😀 The bug affected a recent acquisition of a quiet renowned U.S corporation. It was an Insecure Direct Object References which occurs when there are insufficient authorization checks performed against object identifiers used in requests. However, the vulnerable endpoint was an internal API that was used to retrieve data and the API edge in question was not visible to the naked eye which required me to perform a quick manual bruteforcing against the endpoint using common API edges.

The API endpoint you can spot while capturing HTTP requests was :

https://www.company.com/api/users/<User_ID>/

This would return user profile information. The invisible edge was credit_cards followed by Node ‘CC_ID which identifies the user’s credit card information :

https://www.company.com/api/users/<User_ID>/credit_cards/<CC_ID>

<CC_ID> was sequential, so altering it to any integer value would return either partial credit card information in case the user used it as payment method :

Otherwise the address mail associated with user PayPal account will be revealed

PRO-TIP: If you ever come across undocumented or internal API, always try to a conduct a comprehensive mapping and recon to uncover all edges that might lack sufficient authorizations.

July 24th, 2016 : Discovered, reported then fixed at the same day.

July 25th, 2016 : Bounty awarded $2000

—————-

The second security vulnerability was recently identified in another private program particularly in obsolete login endpoint. When you try to login using an invalid password, the application is likely to display a basic authentication login error, however the secret to finding bugs is by capturing and analyzing HTTP traffic in which you will notice that the login HTTP response, formatted in JSON, reveals users’ Personal Identifiable Information (PII) as well as hashed password (Salted SHA-1, Bycrypt) as you can see in the below screenshot :

The service is used by over than six million IT professionals and it was very sufficient to enter any e-mail in order to disclose the account’s hashed password and important information. The security team quickly handled the report, but unfortunately the payout was not as expected.

December 4th, 2016 : Dicovered and reported

December 7th, 2016 : Bounty of $1000 Awarded

—————-

The third security flaw was a bypass of redirection protection in PayPal Authentication flow, which would allow execution of malicious Javascript in a specific old browsers. The vulnerable endpoint is as follows :

https://www.paypal.com/authflow/entry/?returnUri=https://www.paypal.com/

If you try to redirect to an external domain such as :

https://www.paypal.com/authflow/entry/?returnUri=https://evilzone.org

it would not succeed and you are likely to be taen back to PayPal homepage.

However, I found that three forward slashes would bypass the validation in place, so the exploitation will be as follows :

https://www.paypal.com/authflow/entry/?returnUri=https:///evilzone.org

Or

https://www.paypal.com/authflow/entry/?returnUri=///evilzone.org

First thing I did was to try and escalate this unvalidated redirect to an exploitable Cross-Site Scripting (XSS). I used the Data: trick

https://www.paypal.com/authflow/entry/?returnUri=data:text/html;base64,PHNjcmlwdD5hbGVydChsb2NhdGlvbik8L3NjcmlwdD4=%23//

But the javascript did not execute in the context of PayPal, hence no access to cookies – Failed ! I tested with another payload :

https://www.paypal.com/authflow/entry/?returnUri=%2F%2F%2Fjavascript:alert(document.domain);

Unfortunately, modern browsers don’t execute Javascript in Location header and Mozilla Firefox, for instance, would display a corrupted content error. Still, this was exploitable in old browsers such as Mozilla Firefox 3.0.8, IE 6 and previous versions.

October 22th, 2016 : Discovered and Reported to PayPal

November 2nd, 2016 : Confirmed by PayPal

November 22th, 2016 : Initial bounty of $750

December 7th, 2016 : Vulnerability patched and a final payment of $750 ($1500 total)

 

The article came to its end, hoping that the minutes you spent reading it were very worth it. Please do not hesitate to post a comment shall you have any question, remark or suggestion.

Everything to know about EC-Council, CEH and LPT

On novembre 3, 2016, by Yassine ABOUKIR, 0 Comments

The International Council of E-Commerce Consultants, also known as EC-Council, is a cyber security technical certification organization supported by its members. EC-Council has headquarters located in Albuquerque, New Mexico, but also operates in over 130 countries globally.

The EC-Council is known primarily as a professional certification body offering numerous certifications in a variety of fields related to IT security. However, EC-Council is the developer of the world-famous Certified Ethical Hacker (CEH), The
Licensed Penetration Tester certification (LPT).

Read More : http://resources.infosecinstitute.com/ec-council/

Penetration Tester – Resume and Interview Questions

On novembre 3, 2016, by Yassine ABOUKIR, 0 Comments

Looking for a job as a penetration tester? If so, this article is for you. Searching for a job is a process which can sometimes be a lengthy one as it involves drawing on skills you have developed over time. You can successfully find a job as a penetration tester, but it will take a reasonable investment of time and energy.

In the present article, we aim to give you practical advice to help you professionally set yourself up for your first job pursuit as a pentester.

Read More : http://resources.infosecinstitute.com/how-to-become-a-penetration-tester-resume-and-interview-questions/

Penetration Testing – Jobs, Certifications, Tools, and More

On novembre 3, 2016, by Yassine ABOUKIR, 0 Comments

As technologies have increasingly advanced over the past few years, more complex cyber attacks have also emerged. Thus, data security has become the need of the hour as far as using these latest technologies. Penetration testing is not only an integral part of a security review process for any organization, but also a compliance obligation for standards like PCI-DSS.

In this article, we will discover what penetration testing means, who does it, who needs and how to do it.

Read more : http://resources.infosecinstitute.com/penetration-testing-jobs-certifications-tools-and-more/

Mozilla SUMO cache poisoning and open redirect

On juillet 12, 2016, by Yassine ABOUKIR, 0 Comments

The present article covers a security vulnerability I previously discovered in one of Mozilla web services. The discovery goes back to April 2016, a period in which I was enrolled in a bug bounty challenge with two of my friends. The challenge was quiet competitive and each one of us had a pretty productive month. It is a recommended method for my bug hunting fellows in order to stay motivated and boost their productivity.

Over the past years, Mozilla has always been my favorite bug bounty program and you can notice my name is repetitively listed in their Hall of Fame. They handle security reports seriously and tackle them professionally as well as their attractive payouts. The web service in question is SUMO (SUpport.MOzilla.org) which is « a global gathering of many enthusiastic and dedicated people whose passion is to help all users of Mozilla’s software and products. SUMO ». As a matter of fact, the web service is not actually in the scope of the program, however Mozilla encourages researchers to report every potential bug even if it is out of scope and they sometimes, based on my experience, make exceptions by awarding reports if the vulnerability presents certain risk for their users.

Back in 2015, I was testing SUMO and found a minor bug that was leading to an invalid redirection. When you add a second forward-slash to the end part of the following URL :

https://support.mozilla.org/en-US//test

You will be redirected to :

https://en-us/test

This was an invalid URL. The bug is still reproducible and you can make sure of the behavior I am describing.

I couldn’t find a way to exploit the bug because the language part en-us preceds the arbitrary input which makes a valid open redirection impossible to conduct. It is not until April 2016 that I revisted the issue in order to figure out a way to exploit this bug. I found that we can set arbitrary language via the following endpoint :

https://support.mozilla.org/en-US/locales?lang=test

Once you browse to the above url, a GET request is sent to the server and ‘test’ is set as default language. Consequently, when you browse again to support.mozilla.org, you were likely to be redirected to :

https://support.mozilla.org/test/test/test/test/test/test/test/test/test/test/test/test/test/test/test/test/test/test/test/test/

Now, the second thought was to chain both bugs in order to elaborate a full exploitable vulnerability. So, instead of ‘test’ I set the language to /evilzone.org. Note that the slash is required in order to exploit the first bug.

The final proof of concept would be :

https://support.mozilla.org/en-US/locales?lang=/evilzone.org

When a legitimate user browses to the link, the language will be set to /evilzone.org so when the victim visits https://support.mozilla.org he/she will be redirected to https://support.mozilla.org//evilzone.org and due to our first bug the victim will be taken to https://evilzone.org.

The vulnerability will not only lead to a simple open redirect, but the browser cache is poisoned. Thus, each time the user visits support.mozilla.com he/she would be automatically taken to our malicious domain which causes a temporary denial of service for the victim since SUMO is impossible to reach until the cache is cleared again.

The user may be subjected to phishing attacks by being redirected to an untrusted and attacker controlled web page that appears to be a trusted web site. The phishers may then steal the user’s credentials and then use these credentials to access the legitimate web site. Because the server name in the modified link is identical to the original site, phishing attempts have a more trustworthy appearance.

This issue was reported to Mozilla security team on 2016-04-27; confirmed the same day to be fixed later on 2016-06-27. Mozilla implemented a check to not redirect unless lang is in SUMO_LANGUAGES. However, the first described bug is still reproducible, but without the second one there is no security risk whatsoever. You might wanna have another look at it and find a way to bypass the protection in place.

Mozilla appreciated the report and decided to award a bounty of $500 USD for it which is their minimum since the web service was out of scope.

Mozilla bug bounty

Thank you for taking the time to read my disclosure and kindly let me know about your thought in a comment below. I hope this was a useful article and interesting discovery.

Two security flaws in Microsoft online web services

On mars 5, 2016, by Yassine ABOUKIR, 5 Comments

This article is reserved to disclose the two security vulnerabilities I discovered in Microsoft web services. As you may know, Microsoft has started offering monetary rewards that range from $500 USD up to a maximum of $15,000 USD. So, without any kind of bullshit, making some quick cash was my main motivation this time especially that I am already listed in their Hall of fame twice but that was before they officially launch their bug bounty program.

The first security flaw was a Cross-site request forgery (CSRF) which affected a sensitive endpoint and actions. I have been testing the developer endpoint : https://account.live.com/developers/applications/index and noticed that all the actions were protected against CSRF attacks using an authenticity token named Canary. After some further digging, I noticed that the action of generating a new secret key and activating it are both vulnerable because they lack of the aformentioned security token.

Capture d’écran 2016-03-05 à 01.13.39(App Secret key and ID were created for testing purposes only)

Obviously, the exploitation was pretty easy and any attacker could target popular application developers to lure them to unintentionally change the application secret key by simply visiting a web page with the below codes.

1. Generate a new secret key :

2. Activating the newly generated key :


 

I reported the issue to Microsoft security team on 12/23/2015. They had some hard time reproducing it, I was obliged to record a video as a proof of concept. Microsoft confirmed the vulnerability to be fixed on 02/10/2016 and rewarded $2000.00 USD for it.

As for the second vulnerability, it was a very ugly stored Cross-Site scripting (XSS) that affected most of Yammer.com functionalities including : Chat, comments, feed etc.. I still did not figure out how many bug hunters missed it but I suppose it may be due to a recent code change and I got lucky to be the first one to stumble upon it.

The XSS was due to that fact that Yammer does not properly escape URLs. Using the onmouseover attribute I was able to execute arbitrary javascript. For example, the following link is posted to the company’s feed

Yammer treats this as the URL. When it is parsed Yammer wraps a link around that code, so the HTML now looks like:

You can see that by putting in the URL and the trailing slash, Yammer thinks it has a valid URL even though it contains a quote mark in it which allows it to escape (ie. terminate the href attribute, for the pedants out there) the URL attribute and include a mouse over.

For demonstration purpose but especially to keep it as a memory I recorded the below video :

 

I quickly escalated the issue to Microsoft security team 02/05/2016 and they handled it very quickly. The patch was confirmed on 02/10/2016 and the reward was $2000.00 USD.

I kept digging their web services believing that I may come across something new and, luckily, I found out this open redirect in an eligible endpoint, but I first had some doubts about if they are going to accept it or not. The open redirect resides in *.safelinks.protection.outlook.com because the ‘url’ parameter is not fully validating the input.

The impact is obvious as any user may be subjected to phishing attacks by being redirected to an untrusted and attacker controlled web page that appears to be a trusted web site (outlook.com)

Proof Of Concept :

Unfortunately and as pridected, Microsoft confirmed that it was by design, due to the nature of safe links feature.

Finally, I must to admit that I enjoyed the security team collaboration and Microsoft has, indeed, a good bug bounty program which is not only well managed but also pays very well. I must thank, Microsoft bounty payments processor, Holly for its kind words and good handling of payment processing. Thank you too for taking time to read this and I hope it was not a wasted 😉 Stay tuned for next posts!

See you in February « Security aknowledgment » and the « Honor Rolls » page

Further reading :

  • https://technet.microsoft.com/en-us/security/dn800983
  • https://www.owasp.org/index.php/Cross-site_Scripting_%28XSS%29
  • https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29

Security impact of a misconfigured CORS implementation

On novembre 1, 2015, by Yassine ABOUKIR, 12 Comments

It has been quiet some time I have not blogged about anything new, so I hope this blog post is sufficient to catch up my inactivity 🙂 It is also worth mentionning that this vulnerability has earned me quiet few good rewards from bug bounty programs.

HTML5 brought us some great new features to power the web by providing support for latest multimedia and server communication. Besides, all the latest versions of modern browsers have their support for HTML5. The features are designed to make it easy to include, and handle multimedia and graphical content on the web without having to use any third-party plug-ins or APIs. Cross Origin Resource Sharing is one of the implementations that HTML5 brought into light.

Wikipedia defines Cross-origin resource sharing (CORS) as «  a mechanism that allows restricted resources (e.g. fonts) on a web page to be requested from another domain outside the domain from which the resource originated. ». So, CORS came essentially to eliminate some restrictions imposed by the Same-origin policy which would block a AJAX requests from accessing data on a web page unless it is coming from the same origin.

In simple words, Imaging the example.com wants to access some data on another website, suppose site.com. This type of request traditionally wouldn’t be allowed under the browser’s Same Origin Policy. However, by supporting CORS requests, site.com can add a few special response headers that allows example.com to access the data.

I would love to explain how CORS is implemented but, unfortunately, the topic of this blog post will not cover that particular point. We would rather focus on the security aspect of this functionnality.

You can use Curl to check if the website has CORS enabled or not. You can simply type the following command :

The -H « Origin: http://evil.com » flag is the third party domain making the request. Substitute in whatever your domain is.

The –verbose flag prints out the entire response so you can see the request and response headers.

Capture d’écran 2015-10-30 à 23.58.36

The server may respond with:

  • An Access-Control-Allow-Origin header in its response indicating which origin sites are allowed. For example:

  • An error page if the server does not allow the cross-origin request :

  • An Access-Control-Allow-Origin (ACAO) header with a wildcard that allows all domains:

Now, a wildcard same-origin policy is appropriate when a page is considered completely public content and it is intended to be accessible to everyone such as assets on CDN. However, the security misconfiguration that most developers skip is allowing cross-domain requests from all origins to pages that contains sensitive content. For example, setting Access-Control-Allow-origin response header with a wildcard in a page where user API key is stored, which means that all websites are allowed to access that page via ajax calls. Consequently, any attacker can retrieve the content of the page and particularly extract the API Key from the source code.

To illustrate how a misconfigured CORS can be exploited, we will take the example of a web application that stores user authenticity token in meta tag.

CSRF token

After I have intercepted a few http responses I noticed that the application have CORS enabled and set Access-Control-Allow-Origin header with a wildcard *

To extract the CSRF token, we are going to send the website an AJAX request that will crawl the code and copy the token.

You can insert the above code in an HTML page and send the link to the victim. The extracted value will be sent in the background to a PHP file grab.php that will catch the token and store it in a text file (Scenario 1). Don’t forget to modify the name of the meta tag, length of the token, PHP file link.

You can either store it in a text file and later craft a CSRF attack against the victim. Otherwise, the attacker could have already set up a page that will catch the token and, simultaneously, send a forged request to the application on behalf of the user (Scenario 2)

Scenario 1 : The Php file will catch the token and store it in pwn.txt

 

Scenario 2 : The php file will catch the CSRF token and imediately send a forged request to the application in order to add the attacker’s address mail.

The most interesting capability exposed by both XmlHttpRequest and Access Control is the ability to make « credentialed » requests that are aware of HTTP Cookies and HTTP Authentication information. But, when responding to a credentialed request,  server must specify a domain, and cannot use wild carding. Consequently, You should also note that if the CSRF token is associated with user session, then the extracted token will not be authenticated and cannot be used to craft a working CSRF exploit. However, based on my experience in penetration testing and bug hunting there are some web application that lacks best security practices and do not regenerate the token once the user is authenticated. Consequently, the previously extracted token can be reused to attack the user.

The following video is the proof of concept of a similar vulnerability discovered on Maximum.com and that I successfully exploited to grab the users’ authenticity token :

Although CORS can be very useful, its use carries some security implications that users should be aware of. A few tips on the use and configuration of CORS extracted from the OWASP website.

  • Ensure that URLs responding with Access-Control-Allow-Origin: * do not include any sensitive content or information that might aid attacker in further attacks.
  • Allow only selected, trusted domains in the Access-Control-Allow-Origin header. Prefer whitelisting domains over blacklisting or allowing any domain (do not use * wildcard nor blindly return the Origin header content without any checks).
  • Don’t rely only on the Origin header for Access Control checks. Browsers always send this header in CORS requests, but it may be spoofed outside the browser. Application-level protocols should be used to protect sensitive data.

References :

https://en.wikipedia.org/wiki/Cross-origin_resource_sharing

http://www.html5rocks.com/en/tutorials/cors/

https://www.dionach.com/blog/a-case-of-a-misconfigured-cors-implementation

Price manipulation vulnerability in e-commerce platforms

On juillet 27, 2015, by Yassine ABOUKIR, 0 Comments

The tremendous increase in online transactions and the development of e-commerce in the world has been accompanied by an equal rise in the number and type of attacks against the security of online payment systems. From SQL injection vulnerability that targets databases to XSS (Cross-Site scripting) flaws aiming to hijack users’ sensitive information (Session cookie, CSRF tokens etc.). However, this article will focus on another type of issus that I have came across multiple times in different platforms while doing security testings. We will essentially talk about price manipulation vulnerability that is almost completely unique to online shopping carts and payment gateways.

Paying 1$ for a product which in fact costs 200$ is a great opportunity for the customer but terrible for the business owner. In the absence of a fraud detection system, hackers are likely to exploit some web developers mistakes to purchase products at a very cheap price. This is most likely to occur when developers store the price in an HTML hidden field of a dynamically generated web page or in the cookies.

Hidden HTML form fields are a common mechanism for transmitting data via the client in a superficially unmodifiable way. If a field is flagged as hidden, it is not displayed on-screen. However, the field’s name and value are stored within the form and are sent back to the application when the user submits the form. Hence, web parameter tampering attack is possible by manipulating the price using a simple web proxy tool (Tamper data, burpsuite etc.) or by editing the amount using the browser’s web inspector tool.

Notice the form field called price, which is flagged as hidden. This field is sent to the server when the user submits the form and the value can be altered by intercepting this request.

Now, I would like to share a proof of concept illustrating how I managed to buy a premium licence that costs 16$ for as little as 0.10$ (Hilarious, isn’t ?) Well, I opted for this case because it’s not as simple as it looks and altering the price value via the source code does not change the real price when you order it.

Purchasing licenseI choosed to purchase 1 license for 16.80$ as you see in the above photo. So, when I click to pay using PayPal a POST request is sent and contains the option and payment gateway we opted for. See:

POST reuqestI kept my burpsuite interception ON and I remarked that after the above request was sent another POST request to PayPal which contains information about the concerned purchase including the price. See:

PayPal paymentWithout any hesitation, I tampered the price value and put 0.10$ instead of 16.8o$ then forwarded the HTTP request. Next, I was redirected to PayPal payment page, entered my credentials and then completed the payment as you can see below.

Payment complete

Next, I recieved a confirmation via my email stating that my premium pass is activated. I had that DEVIL smile again :v !

Premium license

Generally, this type of attack works best against high volume websites where each order isn’t getting carefully checked. On a website that gets ten orders a day, most likely someone’s going to look at each order at some point in the day. On the other hand, a site that gets 300 orders a day is much more likely to let the order through. Besides, some purchases cannot just be undo especially when it comes to purchasing a software, an application, digital books etc. while a premium licence may be revoked once the fraud is detected.

Securing your platform from this type of attack is quite simple once you know to look out for it. First, you must remove the price variable from the HTTP headers and cookies entirely. Just have the item number in the HTTP headers and pull up the price from your databse and setup some sort of double-check system, so the price is validated back by the server making sure that the price user paid was actually the price they’re supposed to pay.

PayPal offers some secure solutions for developers. For example, PayPal supports public-key button encryption, so that the relevant details can not be easily altered. This is the way it works:

  • You generate a public/private key pair with an appropriate program such as OpenSSL.
  • You log in to your PayPal account and submit the public key to PayPal, then store the private key securely on your Web server. You will also need to download PayPal’s certificate and store it on your server as well. It is also highly recommended to tell PayPal not to accept unsigned/unencrypted transactions.
  • Each time you need to generate a PayPal button, you encrypt the data using PayPal’s public key and sign it with your private key, then you display the result on your Web page. When the user clicks the button, PayPal will decrypt the details and check they have not been tampered with since their generation on your server.

This way, as long as your private key is uncompromised, no one will be able to alter the transaction’s details.

For extra security of your protected and encrypted buttons, update your PayPal account profile to block unprotected and non-encrypted payments.

 

Also, you can detect and manage Fraud Management Filter results using IPN and the PayPal API. All merchants using IPN or the PayPal API must ensure that their systems can handle transactions pended by Fraud Management Filters.

Instant Payment Notification (IPN) is a message service that notifies you of events related to PayPal transactions. You can use IPN messages to automate back-office and administrative functions, such as fulfilling orders, tracking customers, or providing status and other transaction-related information. Source : https://developer.paypal.com/webapps/developer/docs/classic/ipn/integration-guide/IPNIntro/

I hope this article was helpful and covered all the aspects of the attack. For futher information, I selected some links that I believe will be of a great assistance.

Securing Your PayPal Payments Standard Buttons : https://developer.paypal.com/docs/classic/paypal-payments-standard/integration-guide/encryptedwebpayments/#id08A3I0N30Y4

PayPal Payments Standard Button Manager API Overview : https://developer.paypal.com/docs/classic/button-manager/integration-guide/NVP/ButtonMgrAPIExamples/

Customizing Websites to use Fraud Management Filters : https://developer.paypal.com/docs/classic/fmf/integration-guide/FMFProgramming/

Web Parameter Tampering : https://www.owasp.org/index.php/Web_Parameter_Tampering

Python module UrlParse – Improper input validation leads to Open Redirect

On mars 3, 2015, by Yassine ABOUKIR, 2 Comments

Title : Python module UrlParse – Improper input validation leads to Open Redirect
Credit : Yassine ABOUKIR
CVE : CVE-2015-2104 (Reserved)
Disclosure Date : 02/24/2015
Vendor : Python Software Foundation (http://www.python.org)
Affected versions : Python 2.7/3.2/3.3/3.4/3.5/3.6
CVSS Score : 4.3 (Medium)

Urlparse module Overview :
URLparse defines a standard interface to break URL strings up in components (addressing scheme, network location, path etc.).

>>> from urlparse import urlparse, urlunparse
>>> urlparse(« http://www.example.com/connect/login »)
ParseResult(scheme=’http’, netloc=’www.example.com’, path=’/connect/login’, params= », query= », fragment= »)

urlparse.urlunparse() : this function combines the components of a URL returned by the urlparse() function back to form the original URL.

Vulnerability description and Impact :
The module urlparse lacks proper validation of the input leading to open redirect vulnerability.
URLs do not survive the round-trip through  urlunparse(urlparse(url)). Python sees ////foo.com as a URL with no hostname or scheme and a path of //foo.com, but when it reconstructs the URL after parsing, it becomes //foo.com.

Consequently, this bug can be practically exploited this way : http://www.example.com/login?next=////evil.com

The user may be subjected to phishing attacks by being redirected to an untrusted and attacker controlled web page that appears to be a trusted web site. The phishers may then steal the user’s credentials and then use these credentials to access the legitimate web site. Because the server name in the modified link is identical to the original site, phishing attempts have a more trustworthy appearance.

Proof Of Concept :

>>> x = urlparse(« ////evil.com »)

///evil.com will be parsed as relative-path URL which is the correct expected behaviour

>>> print x
>>> ParseResult(scheme= », netloc= », path=’//evil.com’, params= », query= », fragment= »)

As you see two slashes are removed and it is marked as a relative-path URL but when we reconstruct the URL using urlunparse() function, the URL is treated as an absolute path.

>>> x = urlunparse(urlparse(« ////evil.com »))
>>> urlparse(x)
ParseResult(scheme= », netloc=’evil.com’, path= », params= », query= », fragment= »)

This vulnerability can be practically exploited this way : https://www.example.com/login?next=////evil.com

Mitigation :
 This can be mitigated by checking if the path starts with double slashes and the URL encoding the two leading double slashes. Otherwise, it is recommanded to not use urlunparse(urlparse(url)) to validate a url.
References:
https://docs.python.org/2/library/urlparse.html
http://bugs.python.org/issue23505
https://github.com/reddit/reddit/commit/689a9554e60c6e403528b5d62a072ac4a072a20e
Greetz : Thanks to Reddit.com security team for their precious collaboration and help.

Neglected DNS records exploited to takeover subdomains

On février 20, 2015, by Yassine ABOUKIR, 7 Comments

In this write up I will be talking about a security issue identified in Redbooth platform which « is a communication and collaboration platform that provides a single place for shared tasks, discussions, file sharing, and more. » – Read more at: https://www.crunchbase.com/organization/redbooth

As you read in the title, exploiting the issue allowed me to takedown two of their subdomains. So what is this about ? Well, when I was checking out the website’s DNS records I noticed that there is a CNAME that points the subdomain blog.redbooth.com to teambox-redirect-to-new-blog.herokuapp.com but I when I verified the blog subdomain I discovered that it is not correctly set up yet because they still had not registered the username : teambox-redirect-to-new-blog as their heroku-app yet. See the below photo :

Herokuapp : no such app

Figure 1 : No such app

So my next step after is to sign up for the service and claim the domain as mine in Heroku.com besides that Herokuapp do not perform any kind of verification if you are the legitimate owner of the domain.

Herkuapp custom domain setup

Herkuapp custom domain setup

So now that the DNS records are already set and the subdomain is linked to the herokuapp, all I needed to elaborate a full Proof Of Concept is to upload a test web page as you can see below :

redbooth subdomain takendown

redbooth subdomain takendown

Following the same steps I was also able to takedown another subdomain : http://support.redbooth.com/ exploiting the fact that developers have neglected the DNS records.

Support subdomain takendown

Support subdomain takendown

I just want to point that this vulnerability is not a code bug but a result of neglect. The company could have been using the service and after a while stopped doing so but they forgot to remove CNAME from their DNS records which, by the way, are publicly visible. The vulnerability could be exploited in many ways inluding, for instance :

– Create fake login page similar the original one.
– Redirect users to malicious web pages.
– Inject malicious codes designed to steal cookies for example.
– Deface the webpage and destroy company’s credibility.
– etc.

The security issues were forwarded to their engineering team on 02/09/2015 and got fixed by 02/11/2015. Despite that their response was not much appreciated I have got a small token of thanks but overall I am glad to have contributed in the security of their web service.

If you want to further read about this attack vector then I recommand you to check out this great article : http://labs.detectify.com/post/109964122636/hostile-subdomain-takeover-using

Thank you for reading!

How I discovered a 1000$ open redirect in Facebook

On décembre 30, 2014, by Yassine ABOUKIR, 5 Comments

I am not really used to write about vulnerabilities I have discovered but this time is worth it since it is a bit exceptional for me as it is about a security issue found on Facebook.

As you have read in the title, Facebook is vulnerable to open redirect because some parameters do not fully validate the input allowing any attacker to redirect the victim to a malicious page. This vulnerability is used in phishing attacks to get users to visit malicious sites without realizing it.

Vulnerable endpoints:

https://www.facebook.com/ads/manage/log/?uri=xxxxx&event=view_power_editor&ad_account_id=1

https://www.facebook.com/browsegroups/addcover/log/?groupid=1&groupuri=xxxxx

Facebook has, indeed, implemented some protection against open redirection since I was not able to perform the attack using some common techniques like you the ones below :

https://www.facebook.com/browsegroups/addcover/log/?groupid=1&groupuri=http://www.evil.com/

https://www.facebook.com/browsegroups/addcover/log/?groupid=1&groupuri=../evil.com

https://www.facebook.com/browsegroups/addcover/log/?groupid=1&groupuri=https://l.facebook.com/l.php?u=http://evil.com

None of the above bypass techniques worked! I was about to give up then I noticed in my twitter updates feed some Facebook shortned links http://fb.me/7kFH9QAMH (redirects to evil.com) that are automatically generated if you link your facebook account with twitter. I quickly got back to my pentest work and tried to bypass the protection using the shortned link.Thanks god! The open redirection worked perfectly.

After reporting it to facebook on 13/12/2014 it was fixed on 17/12/2014 and Facebook rewarded me with a 500$ bounty.

Proof Of Concept 1:

https://www.facebook.com/browsegroups/addcover/log/?groupid=1&groupuri=http://fb.me/7kFH9QAMH (You would be redirected to evil.com)

https://www.facebook.com/browsegroups/addcover/log/?groupid=1&groupuri=https://l.facebook.com/l.php?u=http:// fb.me/7kFH9QAMH

https://www.youtube.com/watch?v=09vemLhJNCY

I went to back to check if somehow I could bypass again the protection. So, I took a deep look at the fb.me domain and I found some subdomains like http://on.fb.me/ for facebook pages and I tried to guess other valid subdomains. Result, I found this valid subdomain http://d.fb.me/7kFH9QAMH which worked perfectly allowing me to bypass the protection.

Proof Of Concept 2:

https://www.facebook.com/browsegroups/addcover/log/?groupid=1&groupuri=http://d.fb.me/7kFH9QAMH

https://www.facebook.com/browsegroups/addcover/log/?groupid=1&groupuri=http://d.fb.me/7kFH9QAMH

https://www.youtube.com/watch?v=Q5HIZCQVDoQ

I quickly escalated the bug to Facebook security team on 22/12/2014 and they fixed on 24/12/2014 but they decided not to reward it because it similar to the original one.

I was not happy with their decision, so I managed to find a way to bypass the protection again this way they may reconsider rising the bounty for my continuous efforts.

I tried again some new tricks but all failed then, unintentionally, I added the WWW to the shortned facebook link http://www.fb.me/7kFH9QAMH and the open redirect worked just fine. With other words, I bypassed Facebook previous fix once again.

Proof Of Concept 3 :

https://www.facebook.com/browsegroups/addcover/log/?groupid=1&groupuri=http://www.fb.me/7kFH9QAMH

https://www.facebook.com/browsegroups/addcover/log/?groupid=1&groupuri=http://www..fb.me/7kFH9QAMH

https://www.youtube.com/watch?v=zDkAr2gX4os

I followed-up with the security engineer who escalated the bug on 24/12/2014 and it got fixed on 30/12/2014 and, luckily, Facebook decided to reward 500$ for it.