Background
Previously we discussed XSS, open redirect bugs and unrestricted file uploads. Today we will focus on email content spoofing.

Phishing someone is way more easy if we are able to send emails from the servers of a well known brand. The email looks legitimate, is digitally signed by the sending domain and due to that it won’t be flagged as spam or phishing. Perfect.

IKEA.com
As mentioned in our previous bug report, IKEA is a nice brand with a proper responsible disclosure statement. So we’re safe to help them find bugs, maybe even in exchange for a reward ;-)!

Finding targets
An important rule is that once you find a bug in a system, most of the time more bugs are nearby.

This is a good example, we previously found an local file inclusion bug in the same application, bathroomplanner.ikea.com. So today we will have a closer look at this application and see if it is also vulnerable to email content spoofing.

Let’s have a closer look at this form. We start Burp Suite and intercept the form submission.

As we can see there are multiple interesting fields:
– senderName
– subject
– HTML

Inside the HTML field there is some code that is encoded. We can easily decode it, first urldecode, after that base64decode.

The HTML content is:

Use this code to recover your project in the store or at home. VJ5G3

Changing the email contents
What if we change it to
– senderName: IKEA Account Recovery
– subject: WARNING: ACCOUNT COMPROMISED, ACTION REQUIRED!
– HTML:

WARNING Someone tried to login into your IKEA account, action required! https://s3-eu-west-1.amazonaws.com/pentesting-target/ikea.html” style=”color:#333;”>RECOVER ACCOUNT (FAKE PHISHING LOGIN LINK)

Let’s open our email box and see if we’ve got mail.

Perfect. We just received a digitally signed phishing email from the IKEA.com domain.

Conclusion
IKEA.com did not check the fields being used in one of their email forms. This resulted in the creation of fully signed phishing email, passing all the spam filters.

Solutions
Never allow the user to set the HTML, subject & from contents of an email.
Scan outgoing emails for malicious content, drop the mail if it looks suspicious.

Rewards
€ 50

Timeline
16–06–18 Discovered the bug, report sent by using the Zerocopter submission form.

See the IKEA LFI Report for the timeline for the initial difficulties I had to get in touch. After a while it resolved and I was able to coordinate the disclosure.

09–08–18 Discovered that the bug still exists, informed Zerocopter that it is not resolved, requested Zerocopter to share this post (draft) with IKEA for review, I understand IKEA needs more time, requested direct contact for further coordination of disclosure; email or Zerocopter platform is fine for me.

13–08–18 Zerocopter: no updates yet, requested status update from IKEA, sent this blog to IKEA for review.
13–08–18 IKEA their CDN/WAF (Akamai) banned my private IP site wide, asked Zerocopter if they could ask IKEA to unban me (if they want me to confirm other bug fixes in the future).
13–10–18 Requested an update from IKEA
15–10–18 IKEA requests to me to retest the bug, a fix is deployed
15–10–18 Created a bypass for the bug fix, informed IKEA about this
23–11–18 Requested an update from IKEA
26–11–18 IKEA informs me a new fix will be released 17–12–18, update will be sent through Zerocopter platform
21–03–19 Zerocopter requests me to test the fix
27–03–19 I confirmed the fix
01–04–19 Asked IKEA if I’m allowed to publish this report
02–04–19 IKEA allowed me to publish the report
06–04–19 Published the report