Detectify

How to: Protect your users with HTTP-Only cookies

Almost all web pages today use cookies in order to store small amount of data on the visitors computer. In most cases this data only stored temporarily and is removed when you close the browser and in some cases even sooner.

Websites can use this feature to keep track of temporary user preferences, for example in what language the visitor wants to view the website. In this example the data is not very sensitive and would normally not hurt the visitor if the data was stolen or leaked.

When visiting a website that offers features such as logging in and other feature that require the website to “remember” who you are even if you refresh the page, more sensitive data is needed to be stored. More precisely Session IDs, think of this as temporary passports for your browser. It identifies your browser as a visitor of the website. Every time you refresh the webpage this ID will be verified and used to identify the visitors browser. Naturally, as with a normal passport, it would be very bad if it were to fall into the wrong hand.

Since a cookie is stored on the visitors computer it’s not very easy for an ill-intended person to steal it. However it can be done using an XSS attack if the website is vulnerable to such attacks.

An XSS attack revolves around injecting malicious javascript code on the website that will affect all users. Malicious javascript code runs on the visitor’s computer and it’s intent is often to steal Session IDs from the cookies stored on the visitors computer.

In order to stop this from ever happening, websites should first and foremost make sure that they are not vulnerable to XSS attacks. Secondly enable HTTP-Only on cookies that store sensitive data.

What HTTP-Only does is limiting what mechanisms can read the cookie. With HTTP-Only activated the webpage could still use the Session IDs as passports to identify the visitors browser. But client-side scripts (scripts that run on the visitors computer) would not be able to read it. This will in almost all cases nullify an XSS attack aimed at stealing the Session IDs.

The only negative effect of using HTTP-Only cookies is that this will block javascript that for some legitimate reason needs to read the cookie as well as javascript without a legitimate reason. However this is not very common.

In order to enable HTTP-Only cookies in PHP for all Session IDs, this is all the code you need:

//Set the session cookie to httponly.
//This needs to be done before calling session_start();
ini_set('session.cookie_httponly', true);

You could also edit this directly in php.ini by changing:

session.cookie_httponly = “”

into

session.cookie_httponly = true

For more information read OWASPs article about HTTP-Only cookies.

Verify that we’re the ones pentesting your site

To help you determine if traffic is from our bot, and not someone else, we have now added a link in our user agent. A log entry could look something like this:

54.216.20.194 - - [24/Apr/2013:15:34:46 +0000] "GET / HTTP/1.1" 301 178 "-" "Mozilla/5.0 (compatible; Detectify/1.6; +https://detectify.com/bot/5c91126a8acfcea83263803571c0b6a2d5956f3b)"

The link is unique per scan and if visited you’ll see information about when the scan started and from which IP it’s running.

An Introduction to Cross-Site Request Forgery (CSRF)

Cross-Site Request Forgery (CSRF or XSRF) is a type of attack that is used by an attacker to “trick” the victim into visiting an URL without their knowledge. The attacker pulls this off by planting an object, for example an <img> HTML tag, that can make use of the victim’s session cookies to perform a malicious action, such as a bank transfer. CSRF is also known as Session Riding.

A standard example of CSRF

Pete is happily browsing the web when his mischievous friend Alan sends him a link to a web site he made. Pete clicks the link, not knowing anything about the malicious <img> tag that Alan included in his web site. Pete goes back to his casual browsing. A few days later, Pete checks his bank account, and is astonished to find that it is empty. A transfer was made a few days ago from his account to Alan’s.

What happened?

When Pete’s web browser loaded Alan’s page, it tried to load the <img> tag, which read like this:

<img src="https://www.bank.com/transfer.php?to=391749275&amount=10000"> 

Let’s say 391749275 is Alan’s bank account number. If Pete had opened www.bank.com in his browser normally, he would be automatically logged in because of the session cookies. This is exactly why Cross-Site Request Forgery works. It is important to note that banks often have taken these kinds of vulnerabilities into account by issuing session cookies that last a very small amount of time. So, when the attack is performed, the session may very well have expired and you are no longer logged in. Unless you are using your bank’s website the moment you are attacked, of course. If you are using an online bank that does not employ short-lasting session cookies, you might want to log out after every use. So when Pete loads Alan’s web page, his browser attempts to fetch the image by requesting it. The browser’s attempt to fetch the image and is interpreted the same as if Pete deliberately tried to visit www.bank.com/transfer.php?to=391749275&amount=10000 , therefore the transfer is made and 10 000 are moved from Pete to Alan’s account.

Does this mean that I should never ever, ever open a link?

No. Not at all. To avoid getting attacked, you could read the source of every web page you are visiting, but that would take some time. To fully protect yourself from CSRF attacks, you should make sure that the web sites you are logged in to (or rather, the ones that store cookies on your computer) don’t have CSRF vulnerabilities.

How do I know if a site I am visiting has CSRF vulnerabilities?

This is hard to avoid oversimplifying, but your warning lights should blink if you can do something critical just by visiting a link without using the mouse(or the keyboard) at all. For example, the URL http://example.org/changepassword.php?to=newpassword is very unsettling.

Also, it may be nice to remember that this concept is to be found in several major web sites. For example, if you are logged into Google, try visiting: https://mail.google.com/mail/u/0/?logout

Written by Håkon Vågsether

Scanning custom ports now supported

People have been asking if it’s possible to scan a website hosted on a non-standard port. As of today, it is possible!

To choose which port to scan simply add : after your domain name when registering. For example yourdomain.com:9001. This will scan yourdomain.com on port 9001.

If no port is specified, we will try to scan port 80 and port 443.

Minor easter updates

We know that we sometimes are better on updating the features than telling you about it so here is a brief overview of today’s new features.

Crawl files found using the IIS tilde vulnerability
In some cases when running Microsoft IIS the tilde (~) character can be used to find files and folders, or parts of files and folders, that is not supposed to be public.

If we find parts of a filename or folder we now try to figure out the full name. For example, if we find “uplo*~1*” we assume the full name is “upload” or “uploads”. We then browse/crawl this folder or file.

For a better understanding of what the IIS tilde vulnerability is and how it’s done, I’d recommend the original research document.

Typo-Squatting XSS
We now find typo-squatting XSS, or in english; misspelled calls to resources. A while ago, we wrote about Typo-Squatting and other types of unexpected XSS vulnerabilities.

Improved DNS resolver
This allows us to do lookups we haven’t been able to do before. Before we were limited to just A, AAAA and PTR records, now we can do MX, NS, SOA, TXT and CNAME.

SOA and hosting provider are two new messages available in logs. Those are not vulnerabilities but might be interesting for some and is therefore logged as a notice the reports.

The caching is also improved, making it faster and generating less traffic.

How I got the Bug Bounty for Mega.co.nz XSS

Last week Mega.co.nz released a Bug Bounty Program. Of course I set out to see if I could find something.

I noticed quite early in my digging that Mega had hijacked the alert-function. You could see that by typing javascript:alert(/XSS/) into the address field when you’re visiting Mega.co.nz. The confirm and prompt-functions are not affected. I also noticed that the download behaviour depending on browser were quite different. In Chrome, the download happened automatically, but in Safari, a flash-segment was visible with a “Save File”-link:



When going through their source code, I started to check if I could inject flashparams into this flash file called downloader.swf to simulate a download. I found a nice tool called JP ActionScript Decompiler that made it possible for me to examine the source code of the SWF-file. I was not able find anything insecure with the file though. However, as I was searching for what flashparams that was being used for this SWF I saw another include that took my attention:



Cool, a SWF getting the filename and saving it into your clipboard. I downloaded the SWF and opened it with ASDec. I immediately saw a ExternalInterface.call inside the constructor:


And behold, it sent the flashparam called “id” directly back to the function clipboardcopyready. I created a local testfile simulating the initiation of the OneClipboard.swf:



It worked, I got the variable back to the JS-function. Great! I started googling on how to inject code directly to the SWF without modifying any JS-function. I found an article by Soroush Dalili explaining the ExternalInterface.call() JavaScript Injection. An input to the ExternalInterface.call with a try-catch could actually trigger your own Javascript if the function that was being called did not exist.

Opened up Safari, called this address:
https://mega.co.nz/OneClipboard.swf?id=%5C%22));%7Dcatch(e)%7Balert(document.domain)%7D//



BAM! The injection worked, and my Javascript was executed.

If you’re curious about what could be done with this vulnerability, you should check out our post how to: exploit an XSS.

Anyway, I moved on to Mega’s blog to find where I should report this, a blog entry had recently been written explaining all the different levels of injections that they had, and what had been found during this week, and I noticed this:



So.. Another SWF issue had already been reported, on a SWF called ZeroClipboard.swf, almost the same as the one I found. As my injection still worked, it looked like Mega had replaced their old third-party solution for the clipboard saver with a self-written one, that had the same vulnerability.

At 10:16 PM GMT+1 I sent the report to mega.

Then I moved on to try the vulnerability on other browsers. Suddenly it stopped working, so I went back to Safari and tried it. It didn’t work anymore. The file was removed. So I sent Mega another email to Mega 10:53 telling them that the vulnerability was gone. 5 minutes later I got this:




Nice, Mega fixed it in just 35 minutes! That was the fastest fix I have ever seen and a really nice bounty for my findings. Later that night they also replaced the SWF with a fixed one, removing the id being sent back over to the JS-function. Quite impressive I must say.

Two days later, after some buzz around Mega’s Bug Bounty Program and after Adam Crouchley made an interview with me, Kim actually wrote to me on Twitter:


What can I say. Well done to you aswell, Kim.

Written by Frans Rosén

How to: Prioritize security patches using CVSSv2

CVSS (Common Vulnerability Scoring System) is a system created to help expressing the severity of vulnerabilities. This makes it easier for developers and maintainers to get a clear overview over the current known vulnerabilities and help to prioritize them. This results in them being able to create the “right patches at the right time” to a greater extent than they would’ve been able to without such a tool. Detectify uses CVSSv2 (which is the latest version of CVSS and also the standard classification system for PCI DSS) and CWSSv0.8 (Common Weakness Scoring System) for the same reason.

The CVSSv2 consists of the following metric(measurement) groups:

• Base Metrics
• Temporal Metrics
• Environmental Metrics

The Base Metrics describe the fundamental qualities of the vulnerability, namely the exploitability and impact, and can not change over time. The Temporal Metrics deal with time-related details, and are likely to change, for example when a PoC (Proof-of-concept) has been released. These metrics are optional, but often included. The third and last group are the Environmental Metrics. These convey information on how serious a vulnerability is to a specific company, individual or organization.

After figuring out the metrics of a group, you can put their abbreviations into a list, called a vector. This is just a summary of the metrics. What is interesting, is the score. If you have the metrics all sorted out, you can calculate the vulnerability score of each group or overall. A CVSS score is a number from 0 to 10 where 10 is the most critical. To calculate the score of a vulnerability you have to insert the numbers in the CVSSv2 equation. This, however, takes time, and you’ll probably be better off using a calculator like this.

Calculating a vulnerability

A few months ago we wrote about a new Universal XSS (UXSS) in Opera. To calculate the CVSS score of that, we need to look into each and everyone of the metrics types. We have exemplified this below by going through all metrics. (Below the example you find a table with the scoring for each metrics.)

The base metrics

Access vector
The Opera bug is most likely to be exploited over the internet, so we chose the metric AV:N (Access Vector: Network).

Access complexity
The bug got a few requirements (like the Opera browser) and requires in-depth knowledge about how to (ab)use it, and how to put the bug in practice, so we choose to classify it as a moderately complex attack, AC:M (Access Complexity: Medium).

Authentication
There is no need to be authenticated to any system to use the bug, therefore we choose to rate it as: Au:N (Authentication: None).

Confidentiality Impact
One can argue how much confidential information is lost by this bug (through the said XSS vulnerability). The classification is of course dependent on what systems that is affected and so forth. However, the risk of documents stored on the local machine getting leaked is close to zero. What is more likely to happen, is session information stored in cookies, or other browser information to be leaked. With that said, we chose to classify the confidentiality metric as: C:P (Confidentiality Impact: Partial).

Integrity Impact
Same applies with the integrity, the most likely effect would be modification of say, cookies or your user profile (on say, a vulnerable forum), but not physical files on your hard disk. With other words, I:P (Integrity Impact: Partial).

Availability Impact
Lastly, the availability factor. How likely is it to disrupt the systems operations? Well, I argue like this: XSS’es tend to run JavaScript, the worst availability impact JavaScript can do is either to eat RAM or to make CPU spikes. However, by closing the tab in the browser the system will (hopefully) be restored to a more stable state. A:P (Availability Impact: Partial).

Summary of the Base metrics
So to summarize, with that evaluation, we’ll end up with the base metric of: AV:N/AC:M/Au:N/C:P/I:P/A:N, and by applying the CVSSv2 algorithm on the metrics, we’d see that the final score, in turn, would become 5.8. Although, CVSSv2 algorithm supports two more “groups”, used to make finer adjustments, namely the temporal and environmental groups.

The environmental group
The environmental group is used for explaining the target distribution (in this case the amount of vulnerable internet users) and the collateral damage that the bug may cause. Whilst the environmental group tries to explain the likelihood of exploitation versus what patches and solutions that are available to solve the issue.

Collateral Damage Potential
So let’s take a look at the environmental group. One may ask: what collateral damage is most likely to happen if someone were to run an attack using this bug? To be honest, I have no clue. It’s system dependant, and it highly depends on what party/parties that’s get involved. Therefore we choose to classify it as: CDP:ND (Collateral Damage Potential: Not Defined).

Target Distribution
All right. This one is simple. How many users (internet users in this case) are likely to be vulnerable? According to wikipedia Opera represented about 4.5% of all internet users September 2012. If we look at the metric, we’ll see that the Low factor fits perfect (0%-25% target distribution). That means the metric in turn is: TD:L (Target Distribution: Low).

Security Requirements
The Security Requirements metric is calculated from three sub-metrics, Integrity Requirement, Availability Requirement and Confidentiality Requirement. Namely IR, AR and CR. The CVSSv2 documentation found at first.org states the following: “These metrics enable the analyst to customize the CVSS score depending on the importance of the affected IT asset to a user’s organization, measured in terms of confidentiality, integrity, and availability, That is, if an IT asset supports a business function for which availability is most important, the analyst can assign a greater value to availability, relative to confidentiality and integrity. Each security requirement has three possible values: “low,” “medium,” or “high.””. With that said, we don’t know what may be affected or not, or what other vulnerabilities the individual or corporation have. We cannot classify any of these vectors in a reasonable manner without further information of the target. Therefore: CR:ND (Confidentiality Requirement: Not Defined), IR:ND (Integrity Requirement: Not Defined) and AR:ND (Availability Requirement: Not Defined).

Lastly, we have the Temporal group.

Exploitability
On what level is the exploit available? CVSSv2 have several variants on how to tackle this issue, namely: “Not Defined”, “Unproven that exploit exists”, “Proof of concept code”, “Functional exploit exists” and “High”. As far as I know, there only exists proof of concept code, as seen in our previous post about Opera UXSS. With that said, the metric in turn would become something like: E:POC (Exploitability: Proof of concept code).

Remediation Level
Is there an official patch available? Why, yes there is, over at opera.com: “Opera Software has released Opera 12.10, where this issue has been fixed.”. The metric? RL:O (Remediation Level: Official fix).

Report Confidence
Is this bug for real? Has there been any research on it? Yes, Opera did release a patch. The threat is (was) very real. So the last metric: RC:C (Report Confidence: Confirmed).

So to summarize, we put all the individual metrics through the algorithm, and we’ll end up with the following:

CVSS Base Score
5.8
Impact Subscore
4.9
Exploitability Subscore
8.6
CVSS Temporal Score
4.5
CVSS Environmental Score
1.1
Modified Impact Subscore
4.9
Overall CVSS Score
1.1

With the resulting vector
AV:N/AC:M/Au:N/C:P/I:P/A:N/E:P/RL:O/RC:C/CDP:ND/TD:L/CR:ND/IR:ND/AR:ND.
The score to use in this case would become 1.1. Remember the base vector of 5.8? The point of the temporal and environmental groups is to better classify the real threat about this specific bug, to help developers, analysts and other staff to rank how important the threat really is. With our argumentation on the additional vectors above, we’ve successfully reduced the threat by -4.7 to 1.1.

The whole point of bug classification is to help the managing staff to get a hold on the importance of specific bugs, to help prioritizing what to patch. CVSSv2 is not an exact and perfect magic thing, but rather a tool to help developers see what to focus on.

A comprehensive and correct reference of each metric can be found here, or you can check them out in the table below.

Please note that the Security Requirements metric is calculated from three sub-metrics, Integrity Requirement, Availability Requirement and Confidentiality Requirement.

Read more:
www.first.org/cvss
www.first.org/cvss/cvss-guide.html
www.first.org/cvss/cvss_basic-2.0.pdf

By: Håkon Vågsether & Fredrik Nordberg Almroth

Details on the Java 0day - Yet another way to hack your system

This Thursday, the security blogger Kafeine posted a blog post where he disclosed information about a severe 0day for Java. According to security researchers, this vulnerability has been exploited since mid December. Java has had quite a few problems with security vulnerabilities for the last 12 months, and ironically, the new 0day appears to be introduced by an incomplete patch from October, meant to fix one of these security bugs. The vulnerability is present on all platforms and browsers and could let an attacker to execute code on your computer with administrator privileges. This can be considered as the attacker having full control of your system.

The folks over at Metasploit and Rapid7 have already created a module for exploiting this vulnerability. You can download the framework over at metasploit.com or read the CVE report of the vulnerability here.

According to Dan Goodin of Ars Technica, “Exploits of the latest Java vulnerability are the combination of two bugs. The first involves the Class.forName() method and allows the loading of arbitrary (restricted) classes. The second bug relies on the invokeWithArguments method call and was also a problem with Issue 32 that Oracle purportedly patched in October.”

Adam Gowdiak says that the patch Oracle issued in October only partly addressed the bug, and that it was still possible to exploit it using a trusted system class as a target method caller. However, the other bug allows the attacker to use members of the new Reflection API, which was introduced in Java 7.

The result of this is that Java applets with normal security privileges can access restricted classes. By combining these exploits, the applet can employ the setSecurityManager() function to escalate its privileges freely. This means that the attacker will be able to execute code on your computer with administrator privileges, and this can be considered as the attacker having full control of your system. This type of vulnerabilities is often used for distribution of Ransomware. It affects all versions of Java 7 (Update 10 and earlier).

Older versions of Java are vulnerable from other exploits, if not from this, which makes downgrading useless. In other words, the best thing to do until Oracle releases an update, is to disable Java.

Update:

Oracle has released Java 7u11, which fixes the bug. The security update can be found at java.com. Oracle’s Eric Maurice wrote a post at Oracle’s security blog regarding this update, where he can tell that the default security settings are now set to “High”. This means that self-signed and unsigned Java applets now require authorization from the user to run. He also informed of the fact that Java 7u10 introduced the ability to disable Java in browser through the Java Control Panel. If you don’t know whether you have the latest version of Java or not, you can visit this link to verify your Java version.

So, I suppose we are safe. For now.

How to disable Java:

If you can’t find any Java plugins following these instructions, you don’t have any.

Firefox:

• Write about:addons in the address bar and hit enter.
• You are now viewing the Add-on Manager. Click Plugins to the left.
• These entries are your Plugins. Navigate to the ones whose names contain Java, and click the Disable button on the right. 
• You have now disabled use Java in Firefox.

Chrome:

• Write chrome://plugins in the address bar and hit enter.
• These are your plugins. Find Java and click the disable link. 
• You have now disabled use of Java in Chrome.

Internet Explorer:

• Go to Tools -> Manage Add-ons.
• If you can’t find Tools, try hitting the Alt key.
• In the Add-ons window, select Java and click Disable down to the right.
• You have now disabled use of Java in Internet Explorer.

Opera:

• Write opera:plugins in the address bar and hit enter.
• Find the entries related to Java, and click Disable to the right.
• You have now disabled use of Java in Opera.

Safari:

• Click Safari -> Preferences.
• Select the Security tab.
• Uncheck Enable Java.
• You have now disabled use of Java in Safari.

By: Håkon Vågsether

Launching early access

During the last two months, we’ve been working hard on the development of new vulnerability checks, smoother GUI, and a better user experience. And a few days ago, we left our closed beta period and are moving onwards to early access at Detectify.com

Now we need your help to get even further with our development process. All we ask for is that you create and account and try the service. And if you have the time, send us your thoughts and comments.

So what’s new?

The bigger changes is a better support for finding SSL misconfigurations and CMS focused attacks.

SSL misconfigurations
Ever heard of SSL? HTTPS perhaps? (It’s that lock you see sometimes on sites which means that the traffic is supposedly encrypted) A lot can go wrong even though you might have encrypted traffic. There has been major breakthroughs during the past few years regarding various weaknesses found in seemingly strong encrypted channels. There is a problem though; major parts of the web remains insecure today. With that in mind, we’ve of course improved Detectify to notice you whenever it stumbles upon misconfigurations, deprecated ciphers or otherwise weak implementations in order to keep your traffic secret and secure.

CMS focused attacks
Do you run a blog? WordPress perhaps?
Running a community or e-commerce website? Does it happens to be Joomla?
Detectify is now capable of finding patterns in the data your web servers provide, disregarding design, templates and SEO voodoo.

You may ask; ”how will that help me”?
To answer your question, if we are capable of gaining in depth information of what platform you’re running, we will be able to probe for obscure vulnerabilities and misconfigurations which only may occur on rare occasions on similar setups as your own. To put it short, each and every scan will be tailored for your site - and your site only.

Also,  The scans are faster (though they are far from how fast they will eventually be, bare with us here). And finally, you’ll get real-time feedback, exploits, warnings and notices the very second they are discovered (If you are viewing your report).

So what are you waiting for? Go hack yourself!

How I got a $3,500 USD Facebook Bug Bounty

I recently found a Stored XSS on Facebook, which resulted in a Bug Bounty Reward. If you want to know how an XSS could be exploited, you can read my colleague Mathias’ blog post about it. Anyway, here’s how it went down.

I was actually working on finding flaws on Dropbox to begin with. I noticed that when using their web interface there were some restrictions on what filenames that were allowed. If you tried to rename a file to for example:
'"><img src=x onerror=alert(document.domain)>.txt
it was not possible. You got this error:

But, if you instead, connected a local directory, created a file there and synced it, you got it inside Dropbox without any problems. Using this method I was able to find two issues with their notification messages showing unescaped filenames. I reported these issues to Dropbox, they patched it really fast and I was placed on their Special Thanks page for the responsible disclosure.

It didn’t end here. As I was testing out this stuff on Dropbox, I also tried to figure out how this issue could be connected with other services. I noticed their Facebook-connection and got curious on how it worked. It turned out that they had a pretty nice function going on there:

“Dropbox has teamed up with Facebook so that you can do cool things like add files from Dropbox to your Facebook groups or send shared folder invitations to your Facebook friends.”

Nice! I created a group, and found the connection using the “Add File” icon on the Group wall:

 

I selected the file that I synced to Dropbox, it was called:
'"><img src=x onerror=alert(document.domain)>.txt
and shared it. Nothing awesome happened except the file being shared.

But then, I clicked the Share-link on the entry.

BAM! The title of the entry was not escaped correctly and I was able to get the Stored XSS triggered. By using the files in my Dropbox I could inject script code that was executed on Facebook.com.

I reported this to Facebook directly using their Whitehat Vulnerability Reporting system, told them it was an urgent issue and how I managed to get it executed. The issue was at that time only affecting the Share-popup inside the Group page and could only be triggered by user interaction, serious or not, it was clearly not affecting all users on Facebook.

At the same time I started looking on the URL of this Share-popup:
https://www.facebook.com/ajax/sharer/?s=44&appid=210019893730&p%5B0%5D=entry_id&p%5B1%5D=user_that_shared_it_first
This URL did not work if you tried it stand-alone. That was good, the XSS issue looked like it could only be triggered by user interaction. But then I started googling and found that you were able to create a Share-URL by using this format:
https://www.facebook.com/sharer/sharer.php?
So I changed my URL to that format:
https://www.facebook.com/sharer/sharer.php?s=44&appid=210019893730&p%5B0%5D=entry_id&p%5B1%5D=user_that_shared_it_first

BAM again! If you were logged in into Facebook, the code was executed as soon as you visited the link. Bad. Really bad.

I emailed Facebook again, explaining that you could actually trigger the XSS by only visiting a link.

I was also trying out if I could get other services to behave in the same way. Dropbox and Facebook had this special connection, so I was curious if this issue was isolated or if I could reproduce it by using another service.

Went to Pinterest. Created a Pin named:
'"><img src=x onerror=alert(document.domain)>
and shared it on Facebook using my test account. I pressed the Share button on it.

I was amazed – it had the same issue.

Facebook replied to me, asking me how I was able to place the files on Dropbox with that filename. I explained how this was done and also told them that the service that you shared from didn’t matter, it was a general issue with the escaping that created a vulnerable vector on the Share-page.

They responded and said that it was indeed the same issue and they should look into it ASAP.

In the meantime, I tried the link on different devices. My iPhone could not get the XSS executed. As soon as I visited the page, I was redirected to https://m.facebook.com and that page did not have the same issue. But I also realized that you could force Facebook to skip the redirect by using a parameter called m2w, so if I appended that to the URL:
https://www.facebook.com/sharer/sharer.php?s=44&appid=210019893730&p%5B0%5D=entry_id&p%5B1%5D=user_that_shared_it_first&m2w
I was able to trigger the URL on both mobile devices and on desktop. Another email to Facebook.

One day after that I noticed that the POC-link did not work anymore, it was finally patched. I told them I could not reproduce it anymore and it looked like it was fixed.

One day later I got this email:
 

Nice one!

Date range:

• Initial report and the POC-link executing the XSS just by visiting: Dec 22
• Explained the Dropbox-syncing and extended the scope regarding services and devices: Dec 27
• Vulnerability fixed: Dec 28
• Received message about the Bug Bounty: Dec 29

Frans Rosén

Also, if you want to check your own website for XSS vulnerabilities and a lot more, try our early access at Detectify.com