36

I just heard a very confused news broadcast about Symantec warning the world about the dangers of formjacking. The newsreader said it involved “hacking the form, not the website” whatever that means.

I googled around and found a Symantec blog post about it, where they describe the attack as follows:

  1. The attacker “injects” malicious JavaScript into the targeted webpage
  2. The user fills out the form on that webpage
  3. The JavaScript sends the entered data to the server of the attacker.

However, I would say that if an attacker has write access to the code on the server formjacking is the least of your concerns (and not the actual vulnerability – whatever gave them access is).

Why is formjacking the big deal (it was on the national news where I live) and not the fact that tons of websites (among which British Airways according to Symantec) have a ridiculously large vulnerability that allows attackers access to their servers?

  • I assume that, at least in part, the confusing thing about the news report is the "hacking the form, not the website" statement. To me that sounds like they"re not completely understanding the issue. After all, depending on your point of view, the form is a part of the website. Like DaveMongoose explains below there are technical differences that might limit an attackers possibilities in terms of server-side code or not, this is likely the reason for the vague statement in the news. COmplex things are complex and all... – Gero Feb 22 at 8:11
  • Could you link to the blog post? – Anders Feb 22 at 8:57
  • @Anders Embarrassingly it’s the blog post Tim used in his answer; I completely overlooked the section that fully answered my question. – 11684 Feb 22 at 11:44
  • @11684 And I completely owerlooked the link in Tims answer! :-) – Anders Feb 22 at 13:24
48

The Symantec article you are referring to is like this one.

Looking at the graphic:

graphic

Point 1 is what is generally the most interesting to security researchers, because that is where the vulnerability is.

Points 2 and 3 just show what might be possible with such a vulnerability. For example, JavaScript can be used in phishing attacks (show a fake form) or to read out any data the user enters into forms. This is what Symantec calls formjacking, but it's of course nothing new.

Their article also has a section "How are websites being compromised?", which will likely interest you.

Vulnerabilities do indeed include the option to change server-side code, though not necessarily of the main application, but especially in JavaScript dependencies.

Issues with including 3rd party JavaScript are of course nothing new either. Burp eg calls it Cross-domain script include, and OWASP warns about it as well. Including 3rd party scripts always requires complete trust in the 3rd party as well as trust in their security processes.

Why is formjacking the big deal

Good marketing on the part of Symantec?

  • 1
    It's also worth noting that it's only possible to use an attack like this to steal payment card information if you put payment card information into your form in the first place. For heaven's sake, people, it's 2019! Why does anyone still exist that doesn't offer Paypal or similar as the default option?!? – Mason Wheeler Feb 21 at 17:03
  • 19
    This is just XSS, is it not? – Captain Man Feb 21 at 17:22
  • 27
    +1 for "Good marketing on the part of Symantec" – R.. Feb 21 at 17:27
  • 1
    @CaptainMan XSS would be another possible way to achieve point 1 in the graphic. But Symantec at least doesn't mention it explicitely; they mostly focus on "supply chain attacks", which in this case mainly means included JS libraries for analytics, support, etc. – tim Feb 21 at 17:43
  • 2
    @pojo-guy No. In MITM, the client and server both think they're talking to each other but they're actually both talking to a third party who's passing messages between them and observing and/or altering them. In formjacking, the server is talking directly to the client, while the client is sending its responses to both the server and the third party. – David Richerby Feb 22 at 18:59
40

Direct access to the server is not required

There are a number of ways that malicious javascript could end up on a webpage without the attacker having access to the server.

  • The author of the website might be linking to a library from an untrustworthy source
    • e.g. Web Developer A likes the image carousel on my-site.com and links directly to it - now the owner of my-site.com can modify that script whenever they like, potentially adding malicious code.
  • The author of the website might have copied some javascript from an untrustworthy source
    • e.g. Web Developer B is searching for a library to convert Celsius to Fahrenheit. They find a script on free.javascriptlib.zz which does the job, but don't notice it contains malicious code because the script itself is obfuscated.
  • The end user might sabotage themselves by using an untrustworthy browser extension or bookmarklet.
    • e.g. Alice has added a button to her browser which gives her an emoji keyboard, but it also inserts malicious code into the current page.
  • The end user might be the victim of DNS spoofing.
  • ... etc. etc.

The other concern with these types of attack is that they can be difficult to detect. Javascript is executed client-side, and so none of these would raise flags about the site being compromised: it's unlikely that affected users would get any warning that their details have been stolen.


Regarding the British Airways vulnerability in particular, the BBC wrote an article speculating on the cause here: https://www.bbc.co.uk/news/technology-45446529

In it, they suggest that it was likely to be a third-party script and cite another example regarding Ticketmaster where "an on-site customer service chatbot was labelled as the potential cause".

  • 3
    Excellent points! I would add than an additional vector would be rogue or infected advertisements. They, too, can be designed to have access to everything on the web page on which it is embedded, and therefore, can steal or manipulate similarly as the other vectors. – Andrew Jennings Feb 21 at 17:49
  • You left off ads, which is probably the most problematic of attack vectors... – Jared Smith Feb 22 at 12:45
13

I agree. Formjacking is not a vulnerability, but a type of attack, that can be executed if the attacker already has write-access to the webroot of the victim, or on the webroot of another site, that has full trust of the victim.

Therefore, Formjacking might also be an issue, if the victims webroot is safe, but they dynamically include third-party code or just try to serve ads, which also frequently leads to malformed trust relation ships.

Formjacking is interesting, as the victim of the attack is the customer of the company, the attacker is targeting and groups like Magecart have already earned quite some money with it.

  • 1
    +1 for mentioning 3rd-party scripts, which are probably a bigger risk vector than someone getting write access to the server. – brichins Feb 21 at 17:11
  • Is it like sql injection? – MarkTO Feb 22 at 17:36
  • @MarkTO: No, I don't see much similarities here. Why would you think it is? – Euphrasius von der Hummelwiese Feb 23 at 9:37
  • Because by the way it's described, it's inserting code into a page which causes unwanted behavior.That's why I thought of it. – MarkTO Feb 25 at 17:04
  • @MarkTO: Inserting code, when you have access to the DOM to execute it on the client is quite different from injecting code to a regular request and executing it on the servers DBMS. – Euphrasius von der Hummelwiese Feb 25 at 17:19
1

It appears that Symantec did indeed oversimplify the whole issue of "formjacking". The first time I read it, I was led to the same conclusion as you.

But the matter of concern here is that these malicious payloads are injected without attackers having to access the servers of their targets. That's why they're being mentioned as supply chain attacks.

Attacks on Ticketmaster, British Airways, OXO, Copay, Gate.io all were achieved through this same approach - compromising a third-party to inject malicious code downstream into their targets.

Much like was said in this thread before, using third-party scripts is the most common occurrence in these attacks, but it's not the only one. The attack to Copay was achieved by inserting malicious code into event-stream, a dependency of the Copay crypto wallet.

Considering that the average web app has well over 1000 dependencies, it's no wonder that this flew under the radar and the company released versions of their own product which contained the malicious code. While this attack doesn't fit with the "formjacking" M.O., it did feature the same principle of inserting malicious code through compromised third-parties than by directly breaching the target company.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.