128

Finland's largest bank OP (former Osuuspankki) has added tracking domains (all three owned by Adobe) in their website redesign:

uBlock Origin on uusi.op.fi

These domains are loaded when signed in:

2o7.net
demdex.net
omtrdc.net

Is this considered acceptable? What information can third-party domains gather on my bank account activity?

redyoshi49q
  • 103
  • 2
user598527
  • 1,303
  • 2
  • 9
  • 16
  • 8
    Are these domains embedded into the actual online banking or only in the website of the bank, i.e. on pages where you enter sensitive information or not on such pages? – Steffen Ullrich Jul 29 '17 at 19:48
  • 2
    @SteffenUllrich: demdex.net, omtrdc.net and occasionally 2o7.net are loaded when inspecting my account activity. The balance of my bank accounts is displayed on the front page. – user598527 Jul 29 '17 at 19:56
  • 4
    Given the answer by Steffen, I hope you send(sent) your bank a warning message? And thanks for asking, I'll put this check on my to-do list. –  Jul 30 '17 at 10:28
  • 1
    @JanDoggen: Yes, I have informed the bank. – user598527 Jul 30 '17 at 20:15
  • 5
    This happened with another Finnish bank, S-Pankki, a couple years ago. Article in Finnish, sorry. http://www.tivi.fi/Kaikki_uutiset/2015-02-25/Tietovuotokohu-her%C3%A4tti-S-Pankki-lopetti-k%C3%A4ytt%C3%A4j%C3%A4seurannan-Google-Analyticsilla-3216327.html – AKX Jul 31 '17 at 07:28
  • 2
    OP representative has responded, claims there's no threat (in Finnish): http://www.tivi.fi/Kaikki_uutiset/op-n-verkkopalvelussa-epailtiin-tietoturvauhkaa-pankki-kiistaa-asian-ei-riskia-6665694 – user598527 Jul 31 '17 at 19:15
  • 1
    Similar situation with [Sberbank (Russia) using Google Analytics](https://geektimes.ru/post/289577/). [Responded with "there's no threat"](https://geektimes.ru/post/289661/) too (and got downvoted for that). Unfortunately, both articles are in Russian. – D-side Aug 01 '17 at 02:17
  • 1
    FYI, [OP bank has replied](http://www.tivi.fi/Kaikki_uutiset/op-n-verkkopalvelussa-epailtiin-tietoturvauhkaa-pankki-kiistaa-asian-ei-riskia-6665694). They're essentially saying that there's no risk as this has been audited by a 3rd party. – Adi Aug 01 '17 at 11:58
  • 1
    This is such an excellent question that it has me wondering... how do I determine which tracking domains are loaded by my bank? – psoft Aug 02 '17 at 02:50
  • @psoft: Use uBlock Origin and enable "advanced mode": https://github.com/gorhill/uBlock/wiki/Advanced-user-features – user598527 Aug 24 '17 at 20:06
  • Don't know current situation, but before they even downloaded javascript files from 3rd party server and executed those scripts on front page, in the page where you can make login. I complained for them about security issue but they ignored it and just replied it is not an issue. 3rd party script could make fake login and ask those passwords and numbers while actually doing attack with that information. – Antti Jan 15 '18 at 15:18

3 Answers3

160

It looks like the main site is embedding script from Adobe Marketing Cloud directly into the page. While these scripts are loaded from the same server as the main site it looks like that these scripts communicate with external servers using XHR and also download new script from demdex.net and 2o7.net according to the logs of uBlock Origin.

Especially the loading and executing of new scripts from a third party outside the control of your bank is a huge security problem. Essentially these scripts can get full control over the web site, including reading what you enter, changing submitted or displayed content etc. These are essentially cross site scripting, only that they did not happen by accident but the developers of the banking site explicitly invited these third parties to do cross site scripting.

While such use of third party services might be acceptable on a site where no sensitive information is entered, it is absolutely not acceptable whenever sensitive information is transferred or when it unexpectedly changes to the content of a web site (like showing a different account balance) and might cause unwanted actions from the visitor.

Mr G
  • 103
  • 1
Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • As an addition, seems like `https://uusi.op.fi/js/adobe-analytics/satelliteLib-e8704e6a9fe0a24212f74dccb72240f1fe58410f.js` is causing the trouble. I see a relation in this file to the mentioned domains. Looks like the file is hosted locally, at least that's something. – Kevin Jul 30 '17 at 17:53
  • 2
    Can Adobe see my bank account balance and activity? – user598527 Jul 30 '17 at 21:10
  • 12
    @CC.: Yes, it's possible for Adobe to deliver scripts that submit arbitrary content of the current page (incl. account details) to whomever they want. – David Foerster Jul 30 '17 at 21:13
  • 5
    There are mechanisms that allow for integrity checking of third party scripts, ensuring they are the the ones expected by the developers of the primary site. (https://www.w3.org/TR/SRI/) As such it is possible for this to be done safely. – Gary Jul 31 '17 at 00:34
  • @DavidFoerster, that depends on whether those third party scripts are loaded in the personal section of the website or not. – n0rd Jul 31 '17 at 01:26
  • @Gary what keeps the badguy from cloaking: serving clean code when the integrity checker comes knocking, and serve malicious code when a potential victim arrives? – Harper - Reinstate Monica Jul 31 '17 at 04:08
  • 7
    @Harper. The code from the site that requests the third-party script has a checksum for the resulting script. The browser itself validates that the file returned has the checksum the bank's developers expected before it runs it. – Gary Jul 31 '17 at 04:18
  • 8
    Isn't whether or not to trust a third party vendor such as Adobe a business decision as well? Maybe the bank decided that their security and regulatory compliance is not compromised by including scripts from Adobe on the page? – trognanders Jul 31 '17 at 09:05
  • 18
    @BaileyS: the problem is that the bank has no control over what the third party side does. Even if it trusts that the third party does not intend to do harm it has no control over the security of the third party and thus will be affected if the third party is hacked and serving different content. Thus the business decision is not only if it trusts Adobe's intend but also if it trusts Adobe to fully protect their infrastructure. And [this might not be a good idea](https://nakedsecurity.sophos.com/2013/11/04/anatomy-of-a-password-disaster-adobes-giant-sized-cryptographic-blunder/). – Steffen Ullrich Jul 31 '17 at 09:19
  • 2
    @SteffenUllrich, right. Just like anyone else the bank employs: security, CEO, vault manufacturers. If they employ malicious or incompetent parties, they are vunerable. – Paul Draper Jul 31 '17 at 10:55
  • 2
    In Poland, one bank was sending account balance to an analytics company. When one user noticed it, they immediately took down the script and said it was a bug. I haven't heard about any legal consequences for either company. – Serpens Jul 31 '17 at 13:36
  • @Harper The system Gary eludes to is an old trick on how to handle static content efficiently via HTTPS. You transfer your cryptographically safe hash over a safe connection and then download the static content over an insecure connection (with all the benefits and downsides that entails). You can then easily see if the insecurely downloaded content was modified or not. That said, this requires someone to check whether the actual content is safe in the first place which for JavaScript of a tracking domain seems problematic. – Voo Jul 31 '17 at 15:42
  • 1
    @SteffenUllrich This also makes it impossible for the 3rd party provider to maintain their code. If they do a bug fix or feature add, it breaks the hash and breaks every client, until they update their hashes. I think real-world that authentication would just be skipped entirely, at least after the "who broke the site AGAIN?" meeting. – Harper - Reinstate Monica Jul 31 '17 at 16:59
  • Which checksum does the validation use? Padding a malicious piece of Javascript so it gets the same checksum may well be economically feasible if the expected financial returns are substantial, and in the worst case (a weak or vulnerable algorithm) trivial under these circumstances. – tripleee Jul 31 '17 at 17:06
  • 4
    @tripleee It's SHA-256. (Or better.) The entire purpose of these checks is to prevent someone from performing exactly the attack you mentioned, so weak hashes aren't allowed. As [per the spec](https://www.w3.org/TR/SRI/#cryptographic-hash-functions): "User agents should refuse to support known-weak hashing functions like MD5 or SHA-1 and should restrict supported hashing functions to those known to be collision-resistant. Additionally, user agents should re-evaluate their supported hash functions on a regular basis and deprecate support for those functions that have become insecure." – Ajedi32 Jul 31 '17 at 18:37
  • 3
    @Harper They don't need to break anything to deploy a new version. They just need to make sure they deploy the new version of the library to a different URL. E.g. If `https://code.jquery.com/jquery-3.2.1.min.js` starts serving copies of jquery 3.2. **2** then yes that will break a few sites. Deploying `https://code.jquery.com/jquery-3.2.2.min.js`, however, would not. – Ajedi32 Jul 31 '17 at 18:45
16

Banking sites are hardly monolithic. A bank usually relies on dozens or even hundreds of third party systems in their overall solution. You might have a banking host provided by one vendor, a credit card solution from two or three more vendors, a signon solution provided by yet another, payments by another. The work to put together these sites is enormous.

It is not at all uncommon for banking sites to involve third parties on the front end as well. This could range from third party libraries just to render a calendar control to systems that provide user behavior analytics and risk decisions. Many of these vendors offer script and content via content delivery networks (CDNs), meaning that the files might come from a third party domain.

Is this dangerous? It can be. If the third party resources are not verified via Subresource integrity, they could be modified by hackers (via Man-in-the-middle) or even the third party itself (e.g. malicious employee). So any online banking implementation will either host the content themselves (i.e. copy and paste the third party files onto their own web server) or in some cases deliver the content with a cryptographic hash, notated via the integrity attribute of the script node or link node that references the external file. In yet other cases, they will link to the CDN but provide fallback behavior to a local file (see this StackOverflow question) in case the SRI check fails.

Should I be worried of tracking domains on a banking website?

It is important to note that in the EU, the cost of fraudulent transactions is borne by the institution. Online banking security, therefore, has the primary mission of protecting the bank, not you.

Whatever architecture OP came up with, you can be certain that it passed several layers of risk assessment and review and the decision to use a CDN to serve some content was not made lightly. Chances are they have implemented it properly and are using some means of SRI. You can still worry, but the worry should be minimal.

John Wu
  • 9,101
  • 1
  • 28
  • 39
  • 7
    Whilst it's true that the liability for fraud falls on the institution, it's still a bit of a nuisance to deal with until they accept it's their fault. Definitely worth avoiding, in my book. I wouldn't enable scripts on my bank's site, and certainly not third-party ones! – Toby Speight Aug 01 '17 at 15:31
  • 6
    The cost of fraud is indeed borne by the bank (unless you were grossly negligent). But good luck convincing the bank that it wasn't you who made that properly authenticated transaction from your computer while you were logged in. – David Richerby Aug 01 '17 at 21:13
  • 1
    +1 for mentioning (SRI)subresource integrity. For those who don't know SRI verifies the hash of the third party code matches an expected value. As long as they use that, there really isn't anything malicious a third party could do without causing the SRI check to fail. However SRI is relatively new, and is not supported in IE or Edge, so they may not be using it. You must also be using Chrome of Firefox to receive this extra security protection. – wp-overwatch.com Aug 03 '17 at 06:37
  • 5
    Even if the 3rd party does not do malicious transactions, they might have access to the data. – JKAbrams Aug 14 '17 at 16:51
4

The chance is low but it could be a real threat. Recently (April 2017) it was discovered that tracking scripts (Gemius) on one of large Polish banks (mBank) was sending account balance together with other (standard) tracking data. The intended effect was probably capturing navigation (page titles/section) so leak itself might be accidental.

user158037
  • 271
  • 1
  • 6
  • 3
    citation needed – A. Hersean Aug 01 '17 at 11:33
  • 4
    I don't know of any English source. the original discovery was published at: https://zaufanatrzeciastrona.pl/post/masz-konto-w-mbanku-na-serwery-gemiusa-moglo-trafic-saldo-twojego-rachunku/ It contains sample request to 3rd party server and bank response claiming it was accidental. Such requests no longer happen. – user158037 Aug 01 '17 at 13:42