There is a serious security problem in the older versions of mPDF as we can read in the issue being reported by h0ng10; one is able to include files through the annotation tag.

If we take a closer look at the Github commits of this project we will discover this commit, it shows us the vulnerable mPDF code.

So we are able to change the template of the PDF and we may have the possibility to include a tag that includes files. Perfect. Lets see if IKEA forgot to update the library to the latest version.

The AttackWe add the following tag to the template:

<annotation file=\”/etc/passwd\” content=\”/etc/passwd\” icon=\”Graph\” title=\”Attached File: /etc/passwd\” pos-x=\”195\” />

Send the new template with the Burp Suite Repeater and download the PDF file. We open the file with Foxit Reader and start looking for the yellow annotation marker.

A double click on this marker is enough to open the stolen server file, our attack is successful

ConclusionIKEA.com allows one to manipulate the PDF template being used in one of their shopping list exports. The used PDF library contains (hidden) functionality that allows one to embed files into the PDF by adding a specific tag in the template. This functionality was disabled in the latest version of this library, IKEA did not update so they were vulnerable to this bug. This resulted in the creation PDF containing the /etc/passwd file of one of the IKEA production servers.

Solutions- Never allow the users to manipulate the template of a PDF- Render the PDF containing the shopping list on the client-side, for example with jsPDF- Update to the latest version of the mPDF library, disable the annotation code

Rewards€250

Discussion, what is Responsible Disclosure?Below you can read the timeline of the bug report. It’s quite long this time. Most of the time my reports go without any hassle, Bol.com is a great example. But sometimes it takes more time.

This time we ran into an interesting situation; we were forced by IKEA to report our bug through a Bug Bounty Platform: Zerocopter. But we were not allowed by Zerocopter to have an account at the time of submission. So we had to email Zerocopter for updates and the coordination of the disclosure. We did not have a direct communication channel with IKEA. The initial fix took a few weeks and the coordination of the disclosure three full months and ~30 emails.

The Dutch Governement created a policy that explains in a few pages how to setup a proper responsible disclosure. Direct communication between a security researcher and the organisation that has a security vulnerability is key.

Furthmore it is important to have a clear procedure of how the disclosure works. Only in rare situations a researcher and organisation may decide to do a non-disclosure (PDF, page 7):

If a vulnerability is difficult or impossible to resolve, or if resolving it will involve high costs, the disclosure and the organisation may agree to not disclose the vulnerability.

These days plenty of bug bounty programs are private and non-disclosure is part of their rules. But is this in the public interest? What if a company does not fix the bug in time, what if customers are affected by the bug (a data leak) but they are not informed, what if a researcher got threatened afterwards by lawyers because the researcher revealed its name?

This non-disclosure rule is not part of any ISO recommendations. Also the European Task Force does not advice any non-disclosure rules in their June 2018 report on Software Vulnerability Disclosure in Europe. The opposite, they advice to forbid governments to sign non-disclosure agreements; see page 84.

If Bug Bounty Platforms don’t change, security researchers may start avoiding these platforms and companies and they may start publishing full disclosures again. And that is exactly what we try to avoid.

Bug Bounty Platforms have a big responsibility these days; they advice organisations how to setup a proper responsible disclosure program. However they should also defend the public interest and their security researchers at the same time. Pushing for public disclosure should be part of that.

Hackerone is a good example, their public disclosures are a great resource to learn more about specific bugs and at the same time they inform the public about potential leaks in the past.

Other bug bounty platforms like Bugcrowd and Zerocopter miss a public disclosure feed like the one Hackerone has. Would be great if this changes and platforms start pushing more for public disclosure instead of non-disclosure.

In a perfect world private programs would not exists; everything is public at a certain moment. There need to be clear procedures of what to do if a report is not fixed in time and researchers should be protected from (civil) prosecution if they follow the rules. Reporting bugs should be without any hassle. What do you think? Please leave a comment below.

Happy that IKEA fixed the bug and is supporting coordinated responsible disclosure, thanks!

Andras fel lär bäst.

Timeline16–06–18 Discovered the bug, used Zerocopter submission form as a guest (no signup allowed)17–06–18 Discovered that PDF generation is now disabled (By IKEA after tripping their IDS? High five to their devs!)18–06–18 Zerocopter could not confirm bug (because pdf generation was disabled), but accepts report based on provided evidence, informs IKEA25–06–18 Requested Zerocopter for updates27–06–18 Answer from Zerocopter: IKEA busy with fix since 19–06–1808–07–18 Requested update by email, requested if they could ask IKEA if they mind if I disclose this bug as part of a print magazine article that would be published in October 2018, asked if bug is eligible for any rewards09–07–18 Zerocopter informed me that bug is fixed, Zerocopter told me I do not have permission for publication (‘ IKEA does not allow their name to be used by other companies/people for commercial or other purposes’). 09–07–18 Informed Zerocopter that I won’t use the name or logo of IKEA for this time in this specific print article, but will not censor it from my regular online reports. Notified Zerocopter that the Bug Bounty Rules IKEA has on their website do not mention any non-disclosure rules after a bug fix.09–07–18 Zerocopter confirmed that non-disclosure is not part of the current rules as published on the IKEA website. They will remind IKEA again to add this to their rules.13–07–18 Zerocopter informed me that they will ask IKEA about the rewards when all my other reported bugs are resolved.30–07–18 Requested Zerocopter update by email02–08–18 Answer from Zerocopter: file inclusion bug should be resolved now, although status of report is not changed to resolved, I have to wait on a reply from IKEA themselves.02–08–18 Informed Zerocopter that I don’t have a Zerocopter account, so impossible for IKEA to reach me. Informed Zerocopter that I plan to do a responsible disclosure on 15–08–18 (60 days after submission is considered to be enough time), asked for direct contact with IKEA to coordinate disclosure. Explained that I dislike this way of follow-up by email, difficult to do proper responsible disclosure without any direct contact with IKEA. Requested if IKEA is aware of this suboptimal situation.03–08–18 Zerocopter acknowledges that they understand my frustration, no update from IKEA (‘IKEA is a big company and have plenty of other bugs to fix’). Zerocopter promises that any new bug reports will be part of a personal account so follow-up to Zerocopter is easier in the future (Good news: signups are open again for everyone. You are now able to follow-up your reports. Side-Note: Research accounts that give access to other private programs are still on hold.)09–08–18 I confirmed Zerocopter that the bug is resolved.09–08–18 Requested Zerocopter to share this post (draft) with IKEA for review, requested direct contact for futher coordination of disclosure; email or Zerocopter platform is fine for me.13–08–18 Answer from Zerocopter: informed IKEA about the blog and shared my confirmation of the bug fix. Zerocopter adviced me to remove IKEA from the report in order to avoid any problems with IKEA.13–08–18 Informed Zerocopter that non-disclosure after a fix was not part of the rules on time of report submission and IKEA did not update the submission rules after Zerocopters reminder on 09–07–18. Suggested to meet in person and have a conversation over a cup of coffee; as I live 2000 meters from Zerocopters office. Requested Zerocopter to ask IKEA to contact me to discuss any problems they might have with disclosure. 14–08–18 Zerocopter shared IKEA contact details with me, they mentioned their Confidentiality clause in their terms I agreed on when submitting the bug.17–08–18 Emailed IKEA and requested bug report updates, requested coordination of disclosure of this report, shared my frustration that it is quite difficult to do proper responsible disclosure with them.20–08–18 IKEA confirms frustration, explains they are new to responsible disclosure programs and need to coordinate plenty of teams world wide. IKEA is going to request the different teams involved for updates.21–08–18 Emailed IKEA I just submitted a new bug through the Zerocopter platform, using my new account. It works well.30–08–18 Zerocopter asked me if contact is setup between me and IKEA.30–08–18 Emailed Zerocopter to thank them for the introduction and the properly working account.06–09–18 Requested IKEA for an update; requested coordination of disclosure of this report.11–09–18 IKEA informed me they changed the status of this bug to Resolved on Zerocopter.11–09–18 Zerocopter sent me a €250 Reward11–09–18 Emailed IKEA to thank for the reward, requested coordination of disclosure of this report.17–09–18 IKEA informed me I’m allowed to disclose this report.19–09–18 Published this report.