Belgian banks & SSL — part 3

EDIT: ING is now A- (not reflected in this blog post).
EDIT 2: Keytrade & Hello Bank also went to A. I’ll post a new blog post later tonight.
EDIT 3: Updated post here.

Part three, or how I single-handedly “fixed” SSL at the Belgian banks. 😉

Part one and two are available here. Not related but useful nonetheless NY Times article about bank hackers.

Argenta promised to fix their SSL, so it’s the time to check everything again.

TL;DR: Only Argenta’s status changed for the better.

Those that did not change:

  • Rabobank: A+
  • Triodos: A+
  • Belfius: A-
  • BNP Paribas Fortis: A-
  • bpost bank: A-
  • AXA: B
  • beobank: B
  • CPH: B
  • KBC: B
  • Keytrade Bank: B
  • Crelan (internet banking): B
  • Hello bank!: C
  • Bank Van Breda (internet banking): C
    • BvB no longer supports secure renegotiation (which, afaik, it did before). However, it’s still rated as C, as this isn’t a real issue.
  • ING: F
  • Record Bank (internet banking): F

Those that did change:

  • Argenta (internet banking): F to B
    • No longer vulnerable to POODLE,
    • Support for protocol downgrade attacks prevention,
    • Still using SSL3 (obsolete and insecure),
    • Weak signature (SHA1),
    • RC4 cipher is supported (insecure),
    • No Forward Secrecy.

Still a little way to go for Argenta, but it’s on the right path.

Those that I hadn’t tested before:


The entire list updated:

Grade A

  • Rabobank (A+): no known issues. Support for HTTP Strict Transport Security and prevented downgrade attacks.
  • Triodos (A+): no known issues. Support for HTTP Strict Transport Security and prevented downgrade attacks.
  • Belfius (A-): weak signature (SHA1), no Forward Secrecy.
  • BNP Paribas Fortis: (A-) weak signature (SHA1), no Forward Secrecy.
  • bpost bank: (A-) weak signature (SHA1), no Forward Secrecy.

Grade B

  • Argenta: no SSL on main page.
    • internet banking: SSL3 (insecure), weak signature (SHA1), RC4 (insecure), no Forward Secrecy.
  • AXA: weak signature (SHA1), SSL3 (insecure), RC4 (insecure), no Forward Secrecy.
  • beobank: weak signature (SHA1), no TLS 1.2, RC4 (insecure), no Forward Secrecy.
  • CPH: no TLS 1.2, RC4 (insecure), no Forward Secrecy.
  • KBC: weak signature (SHA1), no TLS 1.2, no Forward Secrecy.
  • Keytrade Bank: weak signature (SHA1), RC4 (insecure).
  • VDK: SSL3 (insecure),no TLS 1.2, weak signature (SHA1), RC4 (insecure), no Forward Secrecy
  • Crelan: no SSL on main page.
    • internet banking: weak signature (SHA1), SSL3 (insecure), no TLS 1.2, RC4, no Forward Secrecy.

Grade C

  • Hello bank!: vulnerable to POODLE attack, weak signature (SHA1), RC4 (insecure).
  • Bank Van Bredano SSL on main page.
    • internet banking: vulnerable to POODLE attack, weak signature (SHA1), no TLS 1.2, no Forward Secrecy, no support for secure renegotiation.
  • Ogone: payment facilitator
    • weak signature (SHA1), RC4, vulnerable to POODLE, no Forward Secrecy

Grade D

  • n/a

Grade E

  • n/a

Grade F

  • ABK: SSL2 (insecure), vulnerable to POODLE attack, weak signature (SHA1), RC4 (insecure), no Forward Secrecy, no TLS 1.2.
  • ING: vulnerable to POODLE attack, SSL3 (insecure), weak signature (SHA1), RC4 (insecure), no Forward Secrecy.
  • MeDirect Bank: vulnerable to POODLE attack, OpenSSL CCS vulnerability (quite bad),
  • Record Bankno SSL on main page.
    • internet banking: vulnerable to POODLE attack, RC4 (insecure), no Forward Secrecy.

Information about SSL Labs grading can be found here. Grade A (+) being the best possible ranking, and F the worst.

Also, shame on you ING. More than any other bank.

64 comments

  1. […] Tested using SSL Labs on 20/01/2015. Updated version 01/02/2015 here and 15/02/2015 here. […]

  2. […] I previously wrote about Belgian banks & SSL. Updated version (15/02/2015) here. […]

  3. Michel says:

    What about the Belgian site of Deutsche Bank?

  4. sd says:

    Moneyou.be is missing in the list…

  5. Yeri Tiete says:

    I will add them later today. Thanks !

  6. Stephen says:

    “Zelf een overschrijven aanmaken, kan een hacker niet, omdat de klant daarvoor een ‘bakje’ (digipass of kaartlezer) moet gebruiken. Maar een overschrijving omleiden naar een andere rekening kan een hacker dus wel.”

    Flauwekul imho. Je signt met de digipass een transactie die een bepaalde bedrag naar een bepaalde rekening overschrijft. Wanneer de gegenereerde response token in de backend niet overeenkomt voor de parameters gaan er al heel wat belletjes rinkelen. Daarbij komt nog het feit dat de meeste van de aangehaalde SSL vulns enkel via server side MITM kunnen worden onderschept.

    Maar jij hebt wel gelijk dat financiële instellingen het voortouw moeten nemen om de migratie vanaf SSLv3 door te pushen.

  7. Yeri Tiete says:

    Van waar komt dat?

    En ja, meeste zijn MitM — maar dat maakt het niet minder erg.

  8. Jan says:

    Ik mis ook Delta Lloyd. Geen zin om die eens onder de loep te nemen?

  9. wdbacker says:

    The most used B2B payment site isabel.be gets A-, a SHA2 certificate signature is certainly needed here IMHO.

    • iemand says:

      Isabel is a different story, they have a certificate on their public website (which you have scanned and gets a A-), but for the ebanking part they are their own certificate authority. This CA certificate is installed in the certificate store (in Windows) when installing the application that has to be installed to gain access to the online banking.

      https://www.ssllabs.com/ssltest/analyze.html?d=ebanking.ibs6.isabel.be&hideResults=on

      • Yeri Tiete says:

        Thanks for the information! I indeed scanned the main page.

      • iemand says:

        BUT, next to the sites certificate all users also get a personal certificate (similar approach as the Belgian eID card) which is renewed every few months. This certificate is used to gain access to the ebanking part and to sign payments. This certificate is similar as the ebanking certificate but the check doesn’t take into account that the certificate is renewed every few months.

      • wdbacker says:

        You are right – Isabel is its’ own CA for the ebanking part – didn’t test that – the CA certificate is a grade B currently (a 1024 bit RSA server key). They are renewing client certificates every few months and the use of a card+digipass with external keypad on the digipass to sign transactions add an extra layer of safety.

  10. Yeri Tiete says:

    Ik zal vanavond Isabel (hoe kon ik die vergeten, al is het technisch geen bank) en Delta Lloyd ook toevoegen. 🙂 Merci

  11. Cedric says:

    I tried to contact you directly Yeri but didn’t find any option to do.

    I personnally experienced the story you’re relating about security and for POODLE in particular, there was mitigation available for some “F-rated” banks such as redirection to an information page. If you take Facebook, they just disabled SSLv3 and a lot of customers were screwed (FYI, Vista + IE9 has only SSLv3 enabled by default, XP + IE6 does support only SSLv3). As a financial instituion with several millions of customers, you can’t just cut it down and create a frustration for them.

  12. Yeri Tiete says:

    yeri@tiete.be or get in touch with the media. 🙂

    Also, yes, you need to have some level of compatibility, but XP (and IE6) is EoL and you have to make tough choices. Get your customers to upgrade (start with a warning, and disable after a couple of months).
    I have also told this to the media outlets (which they didn’t really publish afaik — I haven’t really read the papers yet).

  13. wdbacker says:

    Nog eentje om ‘t af te leren: taxonweb.be (heb ccff02.minfin.fgov.be getest): grade C, kan ook wel een upgrade van tenminste de settings gebruiken … 😉

  14. nietS says:

    Hi,
    First time here. Nice work!
    Zou Europabank er ook bij mogen aub? Djw
    Cheers

  15. Yeri Tiete says:

    Ik probeer Europabank al van gisteren nacht te testen maar hun DNS werkt niet ? Ik probeer verder vanavond.

  16. jarth says:

    Mooi nummertje, curieus hoeveel jij betaalt werd om de bliksem af te leiden.

    Voor minstens één van de sites is de default verbinding een B-Grade en géén F-Grade zoals jij aangeeft en zelfs op de voorpagina van een of meerdere kranten rondbazuint.

    Verder, hoewel het inderdaad zo is dat POODLE een zwakheid is zal bij gebruik van RC4 dit NIET meespelen. Voor RC4 is er een theoretische zwakte aangetoond waarvoor tot op heden géén practische attack bekend is. Wat niet wegneemt dat dit een mogelijke weakness is. Maw, zelfs een B-Grade verbinding is voorlopig behoorlijk veilig.

    In het SSLLABS rapport, op basis waarvan jij jezelf tot hacker, bombardeert staat trouwens een exhaustieve lijst van welke browser/agent welke cipher gebruikt. Daar zie je dan welke cipher er als preferred wordt gekozen, welke de real-world grade van de verbinding bepaalt.

  17. Condo says:

    Fintro misschien er ook bij zetten, hun it gebeuren zal waarschijnlijk binnen het moederbedrijf BNP Paribas afgehandeld worden, maar eens onder de loep nemen kan geen kwaad.

  18. Yeri Tiete says:

    @Jarth: haters gonna hate. 🙂
    Zij blij dat het in de media is en er nu aandacht naar is.

    En theoretisch zwakheid is al genoeg om er aan te werken lijkt mij. Ik heb altijd vermeld dat het “potentieel” en “theoretisch” is. Als ze dat niet vermelden of eruit knippen. Tja 🙂

    En ik heb mezelf nooit hacker genoemd.

  19. Jan-E says:

    ING.be scoort inmiddels A-

  20. Thijs says:

    Ik heb er nog één die abominabel is. Atos-sips (payment provider)(payment-webinit.sips-atos.com): grade F.

  21. Yeri Tiete says:

    Super van ING 🙂 Ik zal nieuw blog postje maken als ik nog even uurtje of twee tijd heb.

  22. Luk says:

    There goes your credibility…. this article lacks depth, it lacks accuracy and most importantly, it lacks “your insight”… So you ran a scanner, found out not all was green and jumped to conclusions… What is this, your first year in netsec?

    Props on the “Whatever gets readers” and “@Jarth: haters gonna hate.” replies though… that shows the exact kind of maturity I’d expect from someone working in network security on any level…. in case you missed that: that was sarcasm right there…

    I’d be surprised you feel as-comfortable publishing this comment as you are posting the article itself.

    • Yeri Tiete says:

      🙂

      Feel free to add depth.

      It shows what it shows, nothing more needs to be added.

      • Yeri Tiete says:

        Also, please feel free to tell us your real name, what bank you work for (I’d only expected these replies from IT people that had a bad monday morning) and let’s get a discussion going. As I said to someone else (from a bank) that mailed me, we’re on the opposite side, and we’re “by default” enemies.

        Nonetheless my bad article, lacking any credibility, insight, depth and whatever else resulted in at least 3 banks changing their SSL configs and upping their security.

        So, apparently I didn’t need more to make all of us a tiny bit more secure. Even if it’s all “theoretic” and “potential”.

        Thank you though. 🙂

        • Yeri Tiete says:

          Oh, and I’m extremely sorry if your manager gave you a hard time today. I didn’t mean for that to happen.

          • Cedric says:

            Btw, I understand the missing depth, you can never argue with a high-manager or a business-manager while he read something on the internet and sees that his infra doesn’t look like to be secure for the world (although this may have been mitigated).

            That’s a way of social engineering, you could force an institution taking bad decisions based on such unclear articles (based on reporter’s will or the interview itself).

            Moreover, in case of Poodle, while you can support SSLv3, TLSv1.2 and TLSv1.0 remained the most used protocols, so the majority of the users were actually safe.. technology knowledge by the population is the real lack in terms of security which induce such “reputational-risks” because for them “it’s working magically, protect me” and, actually, we do… while other companies in other areas would just say “You’re not aé secure guy, go away with your crappy browser”.

            I would even add that going too quickly to a structural solution (by patching for instance) may introduce other security issues that you don’t know yet (because old bug was solved and we just don’t care actually).. just have a look about GHOST and how a misclassified bug could lead to a non-appropriate way of handling it.

            And finally, like I told you, our institution didn’t react based on your blog, but internal constraint do that the closure of the technical vulnerability is done later than actually mitigating it.

    • Tom says:

      Several good remarks, Luk, but I think you missed the point. This isn’t a technical discussion, something to avoid in mass media anyways, but a very public reminder for any institution to _continuously_ focus on all levels of their system and not be fooled into a false sense of security provided by individual tools such as digipasses, biometric verification, SSL or others. Large organizations historically tend to move slow, very slow, and sometimes only public outrage or brand damage seems to add urgency to draconian and sluggish procedures. Yeri has achieved precisely that. As for assessing his technical skills, a job interview or working together trumps a news article, wouldn’t you agree?

      • Luk says:

        Yeri,

        Read Cedric’s comment carefully.

        I did not say that your article didn’t have the desired effect. I’m referring to the language you’ve used in your article and in replies; like “shame on you ING”. I’m referring to you not substantiating your claims. I did not have a bad day because of this, I do not even work at a bank, but I do know that this kind of attitude towards “disclosure”, if you can call it that, at least raises some questions as to “has he really thought this true or not”.

        I can understand the excitement, but what will come of this? Banks don’t upgrade their SSL because of…. what exactly? Did you actually think it through? Is it because they’re “slow in upgrading”? Why? Is it because the admins simply don’t know any better? Is it because they secretly want everyone to steal your data? Maybe it’s that fat IT guy just being lazy… Or maybe it’s because they know exactly what they are doing. Assumption, assumption, assumption.

        I have a return-question for you: did you take into account that in order to pull off any of the attacks on SSLv3 or TLS, you’d trip so many wires on so many different levels, you’d probably have cops at your doorstep before your first attempt at obtaining a single authentication token has finished running? They do store your packets, they don’t need to mitigate it in real-time, none of their customers will be impacted whatsoever, save some potential downtime to “repair the issue”, they’re insured against this sort of thing, they are fully aware and hence are not quick to upgrade as it’s just an additional cost. You now singlehandedly forced everybody to “upgrade their SSL”, basically costing thousands in economic damage for those banks (some more than others, I’m sure), not counting the commercial hit they took for the so-called “not taking security seriously”. I’m guessing you simply don’t know how banks handle netsec.

        Your adversarial attitude is now forcing everybody to upgrade to technology they either don’t know (cause you know, “they don’t know any better”), or for which they don’t have the time (cause you know, “they’re slow and simply do not care”). How is this better? How is this now not giving everybody a false sense of security? Up until a few months ago, TLS was secure as well, and then it changed…

        I, for one, strongly believe that assumptions in security are the basis for a lot of mishaps. You claim that banks assume “that SSLv3 is secure”, just like you claim that “they should know better”. Perhaps they have the actual statistics on how many people would be impacted if they disabled SSLv3, they then calculated the cost of both scenarios and decided on leaving it as it is but with additional monitoring.
        You yourself make the assumption that I must be working for a bank, hiding my identity, while in reality neither is true, but you assumed it and you acted on it: in an adversarial way, blatantly stating that this is not my real name, again with no substantiation, even when it shouldn’t be that hard to substantiate it, right?
        You don’t substantiate your claims towards any insecurity, you assume it’s obvious, or at least that it should be. Maybe it is obvious, but you just didn’t reach that level of broad understanding on how ‘security’ works yet?

        I really don’t mind that this is given a lot of buzz, I actually welcome and endorse it full on, awareness is key in my world, but I do take issue with the way in which you’ve done it, hence my comment on lacking depth and maturity.
        I hope that your articles won’t impact your career in a negative way. Oh and on another, totally irrelevant point: I’m not in management, I’m a pure techie.

        So as a last item, some tech stuff: some of the claims you make about “being vulnerable to POODLE” are simply false as several vendors have patched their implementations in a way that it is technically impossible to even detect a patched system, so are you telling me that they’re still vulnerable now? That the programmers did not do their job and that you just found out about it? Or are you telling me that you ran a random scanner, and when it flared up red you acted on the assumption that the scanner “must be correct”? Or did you really test for the vulnerability by trying to exploit it, like any penetration tester with a sense of self-respect would have done? I’m guessing you didn’t, as you’d be too busy explaining yourself to police officers as your hardware (and god forbid, that of your company) is being seized for investigation.

        I have to give you props on allowing my comment though, that does show maturity. Let’s see how this one fares.

        Kind regards,

        Luk

        • Yeri Tiete says:

          Thanks for the great reply Luk. And thank you for clarifying a few things.

          This is my personal blog, with tons and tons of shit (look around). My language is my own and if that bothers you or anyone else that’s okay. I have said worse things in public. I am “kort door de bocht” — I know. 🙂

          I am not a “hacker” nor a “security blogger”. That’s something the media shouldn’t have written, I agree (I actually pleaded them not too), I don’t know banks nor their security (and I’m happy some people took time to explain in detail what’s going on — again, every industry should do this more often… Communicate! Or make sure you have a good defence).
          As I explained to Cedric, I posted this from the selfish point of an end-user (“me”).

          I also stated in all media (which they cut out?) I used freely available tools, which isn’t “hacking”, and I have no intention of going any further (nor am I the right person to do so). If I did, I know I wouldn’t be writing this.

          I didn’t “force” them to update anything. I merely pointed this out. There are other sites doing exactly the same: https://httpswatch.com/global.

          A statement with what you just said would have sufficed for me. Something like “we know, we’re working on it, and because of X we cannot do it now, but rest assured because of Y you’re safe”. Simple as that. 🙂

          Hence why I linked every reaction I could find in my posts.

          I doubt they took any commercial hit. There has been worse. But then again, that’s the risk of these modern days.

          People got woken up once again. I heard from a big IT consulting firms that IT security budgets have increased greatly since a couple of years ago. And that’s what we need in these times.
          Let’s leave it at that 🙂

          But, again, thank you for the comments. I’ll definitely try to be more substantial.

          I haven’t deleted, edited or not allowed any comment — that’s not how I operate.

  23. John says:

    Answer from MeDirect after I mailed them a link to this article:
    “De in de pers vermelde items kwamen reeds aan het licht bij eerdere testen en worden meegenomen in een veiligheidsupdate die momenteel wordt voorbereid. Deze veiligheidsupdate lost de kwetsbaarheden op die in de pers werden vermeld.”

  24. Yeri Tiete says:

    @Cedric, I have no proof to to say your institution did or did not act on the blog of a merely little guy who doesn’t know half you do.
    And to be honest I am happy they solved it. And that’s all there is to it. And I hope the media get my message and update their site and/or post a new article stating so (but that’s not as “cool” as saying it’s all broken).

    Instead of patching it and making it all “green and fancy”, you could’ve also written a decent explanation about what your (or other) institution does to mitigate these things. Which would be, I guess, be just as good (although, yes I admit that “Green” and “A” is better for the average internet surfer).

    And you have the downside of working for a company that has pretty much every Belgian as customer. So that has a slightly higher media impact than, say, the local website of the night shop. 😉

    And please, don’t forget that these medias are also just corporates that need to make money. You had the bad luck that De Morgen was working on an article about the big bank hack and now they suddenly had a link to Belgium. Impact just went up.

    Again, these blog posts have been around for 1.5 month. Not my fault it suddenly got picked up. And next time I’ll blog about something else. And you should too. 🙂

    • Cedric says:

      We did explain, on our website… but you had to test it using SSLv3 before we removed that page (I can’t find it back right now).

      Arguing about the weight of my employer on the belgian market is the same one to mitigate or not a vulnerability.

      Regarding the big bank hack, knowing this is an Interpol investigation, you should know you’ve constraints then. 🙂

      Actually, vulnerabilities are coming up several times a month but vulnerabilities is not the only thing to do to ensure your security, it is a reactive process while security mindset is a proactive one.

      I can imagine some of my banking colleagues having some troubles today due to this post. But for sure, I won’t blog anything because it is introducing an even higher risk than saying nothing but acting well.

      Ps: you found me on a social website, I was not so anonymous than you thought 🙂

  25. Yeri Tiete says:

    I just saw the VTM news: I NEVER said it’s “een kinderspel om je bankgegevens te lezen”.

  26. Cedric says:

    And you were also on the RTBF. They had updated values for ING btw, some guys should have really a rough day !

  27. […] top pages were Part 3, Part 1, Part 4 and Part 2 […]

  28. S says:

    Misschien moet je de banken nu ook eens door de Logjam-test halen: https://weakdh.org/sysadmin.html Net KBC en Record Bank getest…

  29. […] Dat ING zo slecht scoort is erg opvallend. De bank positioneert zich op het voorfront van beveiliging door onder andere als eerste mobiel bankieren met een vingerafgdruksensor te combineren. Dat de SSL-beveiliging zo lek is als een zeef, en zelfs nog kwetsbaar is voor Poodle, een bug die al sinds 15 oktober van vorig jaar gekend is, is dan ook verrassend. Een recente lijst met de scores van de banken hier bekijken. […]

Leave a Reply...