iOS Safari Self DOS Attack

Posted on by aarvee

A security researcher with the github handle pwnsdx has found a way to crash and restart any Apple device using Safari by just rendering a webpage !

POC Code: https://gist.github.com/pwnsdx/ce64de2760996a6c432f06d612e33aea
CLICK ON THIS LINK ONLY IF YOU ARE NOT USING SAFARI BROWSER ON AN APPLE DEVICE

Sabri Haddouche tweeted a proof-of-concept webpage with just 15 lines of code

The code exploits a weakness in iOS’ web rendering engine WebKit, which Apple mandates all apps and browsers use.

Anything that renders HTML using Safari on a Apple device is affected

That means anyone sending you a link on Facebook or Twitter, or if any webpage you visit includes the code careful before opening it !

Hits: 112

IDOR – PayTM as an example !

Posted on by aarvee

What is an IDOR?

Attacker, who is an authorised system user, simply changes a parameter value that directly refers to a system object to another object the user isn’t authorised for and if gains access to it defines an Insecure Direct Object Reference or IDOR.

Lets say User A logs in to the system and accesses “https://affectedsite.com/month/report?user=A” to fetch a monthly report.

If the User changes the parameter “user” value to “B” as in “https://affectedsite.com/month/report?user=B”  and is able to download User B Monthly report, then the site is vulnerable to IDOR attacks.

OWASP References:

We can refer more on IDOR from OWASP Website.

Please note that IDOR is merged into “A5:2017-Broken Access Control ” in OWASP Top 10 2017 (latest release). You can find more about OWASP Top 10 here!

Vulnerability in PayTM:

PayTM uses short URLs to send SMS to the end users who book movie tickets from the app to download it. These short URLs for example will be “http://p-y.tm/15sTB”

When we brute force the 5 digit alphanumeric token in the URL, we are able to access other tickets that were also booked in the same period of time which calls it to be IDOR. For example:

Short URL : http://p-y.tm/15sTB
Ticket : https:/apiproxy.paytm.com/v1/movies/summary?ticket_key=403108205b1a1c28c8ef8eaeefd58129
Short URL : http://p-y.tm/15sTF
Ticket : https:/apiproxy.paytm.com/v1/movies/summary?ticket_key=6dbd33e14c794cd1c85a3f47ed757332
Short URL : http://p-y.tm/15sTG
Ticket : https:/apiproxy.paytm.com/v1/movies/summary?ticket_key=b371e71e0519b5d197b1b96b179a75e2
Short URL : http://p-y.tm/15sTI
Ticket : https:/apiproxy.paytm.com/v1/movies/summary?ticket_key=01eb61d6e58894c9fa729bd3411961ff
Short URL : http://p-y.tm/15sTJ
Ticket : https:/apiproxy.paytm.com/v1/movies/summary?ticket_key=b3525e193b0b6e43394dcc95f65b3f67
Short URL : http://p-y.tm/15sTK
Ticket : https:/apiproxy.paytm.com/v1/movies/summary?ticket_key=163c4afb5ec084d300a63bb2408dc1e2
Short URL : http://p-y.tm/15sTL
Ticket : https:/apiproxy.paytm.com/v1/movies/summary?ticket_key=7c3bc74af4a602bc89c01fd598e9df7a
Short URL : http://p-y.tm/15sTM
Ticket :https:/apiproxy.paytm.com/v1/movies/summary?ticket_key=86b6c23a5c987383b32fdbff51fcd042
Short URL : http://p-y.tm/15sTU
Ticket : https:/apiproxy.paytm.com/v1/movies/summary?ticket_key=4838e426bd56b6afb640478a1ed613ed
Short URL : http://p-y.tm/15sTV
Ticket : https:/apiproxy.paytm.com/v1/movies/summary?ticket_key=1e204cf11622c8563573bfd78cfd60df

Although the discovered URLs are not revealing the end user details, we are able to grab the QR Code, Movie Name, Theatre and the Show timing details!

Bug Bounty Process

Last year around March 2017, our team had reported an issue with PayTM’s short URLs that was vulnerable to IDOR attacks as per PayTM Bug Bounty process as shown below:

PayTM Team replied back to us stating that it is “DEFINED FUNCTIONALITY” and NOT A SECURITY BUG! 

Please find the email screenshot below:

We tried our best to convince them that it is a Security issue and not a good design but in vain.

Current Status

As of today as in 1st March 2018, 1 year later, the vulnerability still exists, so don’t be surprised if there is another visitor at the movie hall with the same ticket as you have if you have booked the ticket using PayTM!

Why a Public Post?

We published this post to public in order to make all the PayTM users aware of this functionality (as declared by PayTM’s Security Team). If you think this is a valid SECURITY BUG, please go ahead and share this post on your social networks using the tool below!

Hits: 134

Content Security Policy – LinkedIn as an Example!

Posted on by aarvee

CSP – Content Security Policy

CSP is a W3C specification offering the possibility to instruct the client browser from which location and/or which type of resources are allowed to be loaded/ executed.

The supported directives are:

  • default-src : Define loading policy for all resources type in case of a resource type dedicated directive is not defined (fallback),
  • script-src : Define which scripts the protected resource can execute,
  • object-src : Define from where the protected resource can load plugins,
  • style-src : Define which styles (CSS) the user applies to the protected resource,
  • img-src : Define from where the protected resource can load images,
  • media-src : Define from where the protected resource can load video and audio,
  • frame-src : Define from where the protected resource can embed frames,
  • font-src : Define from where the protected resource can load fonts,
  • connect-src : Define which URIs the protected resource can load using script interfaces,
  • form-action : Define which URIs can be used as the action of HTML form elements,
  • sandbox : Specifies an HTML sandbox policy that the user agent applies to the protected resource,
  • script-nonce : Define script execution by requiring the presence of the specified nonce on script elements,
  • plugin-types : Define the set of plugins that can be invoked by the protected resource by limiting the types of resources that can be embedded,
  • reflected-xss : Instructs a user agent to activate or deactivate any heuristics used to filter or block reflected cross-site scripting attacks, equivalent to the effects of the non-standard X-XSS-Protection header,
  • report-uri : Specifies a URI to which the user agent sends reports about policy violation

HTML5Rocks has a very good explanation of CSP.

The main aim of this post is to explain the CSP in a Real Time Example which shall explain the importance of it and how to mitigate attack vectors like XSS, ClickJacking, Code Injection etc.

Real Time Example:

In order to understand CSP in a real time, I shall be referring LinkedIn.

Scenario:

Before Jan 2018, LinkedIn Publishing Platform, also popularly knows as the Articles/ Posts feature for every user in LinkedIn had a HTML Code Injection Vulnerability/ Flaw.  The vulnerability enables an attacker to inject another website’s code as a frame in it resulting in the users viewing the article to be easily deceived.

The vulnerability was RESPONSIBLY disclosed to LinkedIn’s Security Engineering Team through their Bug Bounty Program. Even though LinkedIn DID NOT AWARD us a BugBounty, they did acknowledge the issue and assured the fix back in March 2017.

NOTE: LINKEDIN DOES HAVE A BUG BOUNTY PROGRAM THOUGH IS CURRENTLY NOT OPEN TO PUBLIC. BELOW IS THE MAIL ACKNOWLEDGING THE SAME.

Please find the Vulnerability Execution in the Video Below:

Email Acknowledgement:

Exploit Steps:

Step#1:

We created 2 webpages as shown below:

Page#1: log.html
========================
<html>
<title>
<script>alert(1)</script>
</title> 
<head>
<script>alert(“You are logged out of LinkedIn! Please login now”); location=”/login.html”</script>
</head>
</html>

Page#2: login.html

================

<html>
Login : <input name=”user”>Password : <input name=”pass”>
<button>Submit</button>
</html>

================

Step#2:

In the Article, embed the link which is https://amisafe.secops.in/log.html and automatically <head> data is parsed and displays it on the page as shown below:

Step#3:

When a User clicks on the page, it first gives the Alert “You are logged out of LinkedIn! Please login now“:

Step#4: Automatically follows:

When the User clicks “OK”, the article is displaying the next page that has the login credentials as shown below. Since there is is no sign of user being logged in on the page on the right hand side corner as per LinkedIn standard display pages, the possibility of a user to input their username/password to view the secure content is very high!

FIX? Content Security Policy (CSP):

CSP Enabled LinkedIn to whitelist all the resources from which a script/ frame or any content from a 3rd party domain can be rendered/ parsed on their site ensuring that such evil cases described above do not get executed. They successfully implemented CSP in the month of January 2018 (LinkedIn Team to confirm the exact timelines)

Current Status:

Implemented CSP:

Testing:

 

Hits: 1293