4

today I went to my Online-Banking by typing in the correct domain name in Firefox. I could login and even see my actual balance. Then within the site a warning appeared that I should do a test-transfere for security reasons (over 7200€...). I didn't do this, but was wondering, because I still stayed on the original domain.

Checking the certificate showed me this (wrong, but valid. To compare with the original one: https://www.sparkasse-suedpfalz.de):

enter image description here

This type of certificate appears on every website I visit (inkluding stackexchange.com or google.com).: Instead of a certificate for [DOMAIN] i get one of *.[DOMAIN], where the CA is VeriSign.: enter image description here

It happens with all browsers (Firefox, chrome, edge), but not with TOR. The OS is Windows 10 Pro, Version 10.0.19042 Build 19042

I dont have any issues on an other machines in the same intranet.

Are all requests from this computer send to a proxy? And how do they manage to insert fake requests to send money to the original domain? Happy if you have an idea what to do.

TheGermanGuy
  • 41
  • 2
  • The bank certificate is definitely not genuine (original doesn't use wildcards and has a different digest). At least now you know that your system is infected somehow. Backup you data and files and re-install it from a fresh genuine media. – Robert Jan 13 '22 at 21:35
  • 2
    Looks like a MITM attack in your network. When using Tor or a VPN originating on your machine you are protected from such attacks since it tunnels through the local network. It is unclear where exactly the attack originates though, might be a compromised router or some other compromised machine on the network or an actual attacker machine inside it. It might also be that your local machine is compromised. – Steffen Ullrich Jan 13 '22 at 21:53
  • I tried the VPN but the problem is still there, so it musst be a local problem (what I thought already, since the other machines running well) – TheGermanGuy Jan 13 '22 at 22:24
  • 3
    Regardless of where the MITM attack is taking place, your system has been compromised, as the attacker was able to install the 'OV Verisign CA' certificate in your system's trust store. This is what is enabling the MITM attack, i.e. the 'OV Verisign CA' certificate in your system's trust store is what is causing your browser to trust the MITM attacker's fake certificates. – mti2935 Jan 13 '22 at 22:31
  • 3
    You should change all your passwords from a separate machine immediately, and treat this one as compromised. Ideally, follow the instructions from this post – nobody Jan 13 '22 at 22:46
  • So all my communication goes to the MITM server that receive it unencrypted? From there it's redirected to the original server that doesn't realize it's not me, what makes it possible for the MITM to give me original and sensible content, like my actual balance.

    However, passwords shouldn't been stolen, since they are directly hashed, right? Of course I will change them anyway. My bank account is blocked allready.

     – TheGermanGuy Jan 13 '22 at 22:50
  • 2
    @TheGermanGuy When you login to an https web site, the password is sent in plaintext through the TLS tunnel. So, an MITM attacker in this case would be able to see your plaintext password. See https://security.stackexchange.com/questions/110415/is-it-ok-to-send-plain-text-password-over-https. The password hashing that you are referring to applies to how passwords are stored on a server. See https://security.stackexchange.com/questions/211/how-to-securely-hash-passwords – mti2935 Jan 13 '22 at 22:55
  • @TheGermanGuy: "So all my communication goes to the MITM server that receive it unencrypted?" - No. It is encrypted. But the MITM can decrypt it and read everything. – mentallurg Jan 13 '22 at 23:06
  • @TheGermanGuy: "passwords shouldn't been stolen, since they are directly hashed, right?" - No, this is not true. Passwords are hashed on the server side only. But you as user must show that you know the original password. That's why you have to send the password as a plain text. (There are other methods without presenting the password, but let's assume the most widely used - plain password). Despite the password is encrypted, as the whole traffic encrypted, the MITM is able to decrypt the traffic and will know also your password. That's why change your password as soon as possible. – mentallurg Jan 13 '22 at 23:10
  • All right, thanks for the lots of advices. My knowledge is this is not to good... One more thing I tried befor this post, since I already thought about the mitm: With tracert I should see more hops, compared to a uninfected machine, since my packages are going over an other server? Is that correct? – TheGermanGuy Jan 13 '22 at 23:15
  • @TheGermanGuy Not necessarily. Your browser thinks the MITM's server is the actual server of the site that you are connecting to. It's like this: your browser <-TLS-> MITM server <-TLS-> actual site's server, where each <-TLS-> is a separate TLS connection. So, the trip to the MITM's server could be more hops or less hops than the trip to the actual server. By any chance, are there any proxies set, or any changes to the network settings, in your browser's network settings or your system's network settings? – mti2935 Jan 13 '22 at 23:44

0 Answers0