Let’s reload our article and see if our fake login embed loads.

Discussion, what is Coordinated Vulnerability Disclosure (CVD)?As you may remember from the previous IKEA report; coordinated disclosure can take some time. Today we run into the same problem with Medium.com.

The problem is communication; it took us 11 emails before we got in direct contact with one of their engineers. When communication was setup we quickly discovered that the initial bug was resolved but their caching servers still serve malicious payloads. After Medium invalidated their cache the vulnerability was resolved and we were able to publish this report; 86 days after the initial report.

New guideline from the National Cyber Security CentreOn 04–10–2018 the Dutch Governement published a new guideline for coordinated vulnerability disclosure. This guideline is a revision of the Responsible Disclosure Guideline, published in 2013. They changed the name from Responsible Disclosure to Coordinated Vulnerability Disclosure. The main reason for that is that they want to focus on the importance of clear communication, the coordination of it.

Direct communication between a bug reporter and the technical staff is required for a good functioning CVD. Also the last resort option, full disclosure, is now mentioned in the guideline:

The main intention of CVD is to mitigate the vulnerability, but ‘full disclosure’ of the vulnerability is always an option for a reporting party if it feels that the process will take too long. This measure is the proverbial ‘big stick’ available to the reporting party. Naturally, this situation must be prevented as much as possible.

As you remember from the IKEA report, this is something we should try to avoid.

One of the lessons learned from this report is that even though a company has a CVD program we sometimes still need to have patience and persistence in getting a bug resolved.

For a company it’s important to have easy to approach engineers that coordinate the reported vulnerabilities and update the bug reporter of any updates. This saves both parties plenty of time ;-)

ConclusionWe found a way to store our JavaScript and HTML code in such a way that it is executed by the browser of the victim when he visits our Medium post. We did this by manipulating an oEmbed tag by performing a MITM attack.

Our injected javascript is sandboxed in an iframe by Medium.com, this means that even though our Javascript is injected in their pages we can’t access the Medium.com cookies or manipulate their DOM. This greatly reduced the impact of our bug.

However this bug could still cause a lot of harm; a regular visitor won’t be able to see the difference between this fake login and a real login.

Impact of this attack- Perfect for phishing- Open redirect possible by using top.location.href. We may auto redirect users to another page after they have entered their credentials for example.- Attack visitors by embedding http://beefproject.com/- Allows an attacker to perform clickjack attacks

Do I forget anything? Leave a comment!

Solutions that prevent this attack- Improve oEmbed provider checks, disallow unapproved iframe sources- Don’t allow iframes to break out by using top.location.href- Always invalidate the caches (and that is hard)

Rewards$100, mention in the humans.txt and a Medium t-shirt

Timeline08–07–2018 Discovered bug, wrote this report, informed Medium by email11–07–2018 Requested confirmation, Medium confirmed20–07–2018 Requested update from support, reply that I got a reward of $100, mention in the humans.txt and Medium t-shirt, no updates on the bug itself08–08–2018 Requested update from support, about to publish another blog that describes the same type of attack, bug not fixed on Medium. So the other report is halted (responsible disclosure), no reply15–08–2018 Requested update from support15–08–2018 Medium support replied that they requested an internal update from engineers, will contact me later02–09–2018 Requested update from support, no reply04–09–2018 Sent LinkedIn message to a Full Stack Software Engineer at Medium (check if they are aware of the bug), no reply13–09–2018 Sent LinkedIn message to Executive Assistant of CEO at Medium (check if they are aware of the bug), no reply18–09–2018 Requested update from support, no reply19–09–2018 Sent LinkedIn message to Head of Legal at Medium24–09–2018 Reply from Head of Legal, will request security engineers to contact me03–10–2018 No updates from security engineer, just confirmed bug still exists, shared this report with Head of Legal, requested updates.03–10–2018 Head of Legal introduced me to a security engineer, security engineer explained that they previously marked this bug as resolved, apologized for the lack of communication, discovered unvalidated cache that causes the payload to still work, explained they invalidated all the caches, allowed me to disclose the report at 04–10–2018.04–10–2018 Published this Report