Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Security

More Than 1,200 Phishing Toolkits Capable of Intercepting 2FA Detected in the Wild (therecord.media) 52

Posted by msmash from the security-woes dept.
A team of academics said it found more than 1,200 phishing toolkits deployed in the wild that are capable of intercepting and allowing cybercriminals to bypass two-factor authentication (2FA) security codes. From a report: Also known as MitM (Man-in-the-Middle) phishing toolkits, these tools have become extremely popular in the cybercrime underworld in recent years after major tech companies started making 2FA a default security feature for their users. The direct result was that threat actors who managed to trick a user into entering credentials on a phishing site found that the stolen credentials became useless since they couldn't bypass the 2FA procedure. To counter this new trend in account security protections, since at least 2017, threat actors started adopting new tools that would allow them to bypass 2FA by stealing a user's authentication cookies, which are files created inside a web browser once the user has logged into an account after the 2FA process was completed. In most instances, cybercrime groups have relied on a malware category known as an "infostealer" to steal these authentication cookie files from computers they managed to infect. However, there is another way to steal these files that does not rely on infecting a computer with malware -- namely, by stealing the authentication cookies while they transit the internet from the service provider to a user's computer.
This discussion has been archived. No new comments can be posted.

More Than 1,200 Phishing Toolkits Capable of Intercepting 2FA Detected in the Wild More

More Than 1,200 Phishing Toolkits Capable of Intercepting 2FA Detected in the Wild

Comments Filter:
  • Are mutually exclusive terms. Given the design and porosity of the browser platform, I don't think it is fixable.
    • Security is an arms race. With enough ammunition, a person could take down the entire 1776 British army with only a Glock, John Wick style.

      Now's as good a time as any to point out that Drupal is widely used by governments [drupal.org] and has a well-regarded security team [drupal.org] and Best Practices in-place, improving all the time.

      • I suspect that 1776 army firing a few hundred or even thousand muskets simultaneously would make mince of the guy with the glock.

        • You're probably correct. Everything I know about guns comes from the movies.

        • Re: (Score:2)

          by NFN_NLN ( 633283 )

          Cops with 9mm weapons couldn't take out guys wearing full body armor in the famous "Hollywood Shootout". So I doubt muskets would do any better.

          https://www.youtube.com/watch?... [youtube.com]

          • Unless he wore body armour on his face hes dead. Besides, enough musket balls to put him on the ground and wind him and then move in with the bayonets. Or a cannon.

          • Re: (Score:2)

            by Entrope ( 68843 )

            Musket balls are a lot larger and higher-energy than 9mm bullets. That's why SWAT teams wanted access to rifles or shotguns after that shoot-out. The British army would have been normally armed with long guns.

            • Re: (Score:2)

              by NFN_NLN ( 633283 )

              Will Modern Body Armor Stop a .50 Cal Flintlock?
              https://www.youtube.com/watch?... [youtube.com]

              • So the only good way to watch an absurdly-long video like that is by making use of YouTube's scrubbing bar.

                The answer is

                1) Yes, the body armor stopped the flintlock
                2) The slow-motion video from the side shows that the flintlock round pushed a good-sized section of that armor inward a fair ways, temporarily. So I'm guessing several near-simultaneous flintlock impacts would, while not killing you, knock you over and leave you in a lot of pain. Washington's troops would probably be able to finish you with thei

        • Yes, muskets have the same effective range as a glock. A modern rifle is more accurate than a musket (due to spiral grooves in the barrel) but the glock wouldn't be more accurate than the musket. The only advantage that a glock would have is a faster firing and reloading rate, woth the muskets taking 1 minute to reload, but that advantage would disappear against many people reloading their muskets in a coordinated fashion.

          • Muskets took 3 minutes back then. it wasnt until later that And without rifled bores they were told to only fire in the 25-50 yard ranges. So a glock is more accurate than flintlock black powder smooth bore musket at say 60 yards. Especially since the muzzle velocity is so low that if you saw the muzzle smoke, you could actually move before the ball reached you. The ultimate problem with that was if you wound up actually moving into the path of the wildly inaccurate tumbling ball as it met with air friction
        • If they hit them. Dont forget that a smooth bore flintlock rifle has an accuracy range of only 100yards in the absolutely most practiced hands. SOP dictated that shots be fired between 25yards and 50yards. If they all fired at the same time, and all missed as you dove for cover, it would take them around 3 minutes to reload their flintlock rifle. It was the Norths access to lever action rifles with brass casings during the Battle of Chickamauga that turned the tide in favor of the Union Army. They could fir

    • In the big picture, I would prefer a web application to a native code application any day. The problem is the browsers are trying to do too much, which makes it impossible for security by design. We need special-purpose browsers with specific levels of trust and functionality.

      Unfortunately most (mobile) apps today are still using the web/https/html for backend communications at a minimum.

      • Unfortunately most (mobile) apps today are still using the web/https/html for backend communications

        How does that cause problems?

    • Re: (Score:2)

      by shanen ( 462549 )

      Not a bad FP, but you didn't blame anyone.

      May I nominate Al Gore? Stay with me, even if it's a joke of sorts about the flawed foundations of the Web. Gore told the original designers of the Internet not to worry about the money. He promised he'd get the money out of Congress, and I think he deserves as much credit as any politician does for funding the development of the Internet. Not worrying about who was going to pay for it, they built weak foundations. Like SMTP and later on HTTP. And we've been buried

      • Comment removed based on user account deletion

        • Even the most secure replacement for SMTP would be susceptible to phishing as it attacks to stupidity of people, not the protocol. There's literally no attack on SMTP in phishing, so there's no way to change SMTP to "fix" phishing.

          You have to "fix" humans. That's never happening. Who cares about how secure the foundations of the internet are when you can just ask someone to give you their password and then walk away.

          While there is a kernel of irreducible spam and attack shenanigans inherent in email and personal communications the delta between what is possible with a properly structured system and the damage nonsense like SMTP continues to inflict is the difference between a small creek and Niagara falls.

          • Re: (Score:2)

            by shanen ( 462549 )

            I actually find it kind of offensive when I present it as an option that I no longer advocate, but someone picks THAT as a straw man to play patty-cake with. Does not seem worth noting that the problem with SMTP is that it's too easy to pretend the marginal cost of a million more spams is too small to worry about. My less-simple-than-SMTP suggestion (from those days circa 2002?) was to extend the protocol to keep track of sending and receiving. The accounting doesn't have be perfect. Actually it didn't even

    • Saying "security" and "web application" are mutually exclusive is both sweepingly broad and largely incorrect. In the two examples referenced in the article: Real-time phishing is not a weakness of the web but a broader one impacting a poor implementation of two-factor authentication; a phone transaction is just as susceptible to the attack as a web-based one, for example. In the second case of stealing a cookie, that is just an absurdly poorly designed system. Designed properly, a cookie is just one piece

  • Everyone whose anyone knows 2FA is a magic cure-all for stolen passwords, buffer overruns, and ugly fat people wearing revealing clothing in hot weather.

    • Apple wants me to switch to 2FA on my phone. But my phone runs all the 2FA for every damn thing my company requires 2FA for, because they took the blue pill. No way in hell im going to get locked out of my phone and subsequent locked out of every other 2FA thing I have to do. I just need my phone to work and just guard it like my CCW.

  • How? (Score:2)

    by PPH ( 736903 )

    by stealing the authentication cookies while they transit the internet from the service provider to a user's computer.

    Where exactly do they do this? What happened to TLS?

    I get how they can infect a computer with malware and steal cookies and credentials.

    • Where exactly do they do this? What happened to TLS?

      I get how they can infect a computer with malware and steal cookies and credentials.

      Third party garbage (stalking bugs, ads, CDNs) plus permissive cors policy or misdirection. Many widely used 2FA schemes don't support proper channel bindings.

    • Re:How? (Score:5, Informative)

      by 93 Escort Wagon ( 326346 ) on Monday December 27, 2021 @04:59PM (#62120201)

      The statement appears to be misleading. What the article describes is two scenarios.

      1) Malware is placed on the end user's computer. We know how that works.

      2) The bad actor manages to get the end user to visit a phishing site under the bad actor's control. That phishing site mimics the real site, while the bad actor visits the real size. When the real site prompts the bad actor to enter the two-factor code, the bad actor triggers the phishing site to prompt the end user with a phony "enter your two factor code" prompt. When the end user does that, the bad actor turns around and types that code into the real site.

      So, it's just a riff on the classic man-in-the-middle attack. TLS is not compromised.

      • 2) The bad actor manages to get the end user to visit a phishing site under the bad actor's control. That phishing site mimics the real site, while the bad actor visits the real size. When the real site prompts the bad actor to enter the two-factor code, the bad actor triggers the phishing site to prompt the end user with a phony "enter your two factor code" prompt. When the end user does that, the bad actor turns around and types that code into the real site.

        So, it's just a riff on the classic man-in-the-middle attack. TLS is not compromised.

        You are right. TLS is not compromised it is simply being used incorrectly en masse. In the end its a distinction without a difference.

        There is no reason the MITM above need be tolerated. No point in arguing such attacks are somehow out of scope or fundamentally impossible to mitigate.

        Such attacks are easily guarded against using multifactor authentication with proper channel bindings as has been available for decades with client certs / smart cards.

        Even password only single factor authentication over a p

        • Re: (Score:2)

          by MrL0G1C ( 867445 )

          It's not a Man-In-The-Middle attack, it's a phishing attack, the phishers have to get the victim to visit their fake site and enter passwords and 2fa codes into their fake site which they then use on the real site.

          The mitigation would to be using verification checking codes against payee numbers and against amounts so that when the attacker can then only pay who the victim intends and the amount would only be the amount the victim intends. This is a painful level of security though requiring verification at

  • Hardware 2FA (Score:1)

    by Anonymous Coward
    I saw no mention of hardware 2FA, like yubi keys or rsa devices...are they currently immune to these attacks?

    • Re: (Score:2)

      by jetkust ( 596906 )

      I saw no mention of hardware 2FA, like yubi keys or rsa devices...are they currently immune to these attacks?

      I think not, because the attack only happens after you're already hacked, or logged into a hacked network. You're communicating with a malicious computer (Man In The Middle) that is just forwarding everything back and forth to the real site until it gets the session cookie. Once it has the session cookie, they can access the website without you. I don't think the technologies you mentioned can account for this. It's more a problem on the websites end. Which is one reason many websites are suspicious o

  • If you use Microsoft products your most likely already infected thus 2FA does not help much since the crackers already own your system.

  • Cookies Again! (Score:3)

    by Thelasko ( 1196535 ) on Monday December 27, 2021 @04:54PM (#62120187) Journal
    I wrote a journal post about this a while back. If your browser has the right cookies, then the many services disable 2FA. Options to avoid this are:
    - Do banking in private/incognito mode.
    - Clear cookies after visiting your bank.
    - Use Multi-Account containers? [mozilla.org] I've had this recommended, but I'm still unsure about it.

  • when they forced users to cough up their phone numbers so they could make all their users do 2FA. They told me 2FA was secure. I told them that 2FA was not secure, there are sim swap attacks and middle man attacks, and this makes the bad guys want to get my phone even more. They were surprised.

    • 2FA via SMS is not secure. Other kinds of 2FA are more effective, and any of them are a significant barrier for everyone. You are working a lot harder if you have to manually MITM my 2FA, and you are assuming that my 2FA even involves me entering a code at all.

  • 2FA Is Not A Defense Against Laziness (Score:3)

    by IonOtter ( 629215 ) on Monday December 27, 2021 @05:04PM (#62120211) Homepage

    The summary and article make it clear: the baddies are stealing your cookies.

    So the answer is simple!

    When Google, Amazon, Twitter and other sites using 2FA give you a checkbox, saying, "Don't require OTP on this browser"???

    DON'T CHECK IT.

    This means you have to enter your OTP every single time, but it also means it can't be stolen.

    • Re: (Score:2)

      by xwin ( 848234 )
      You can also use something like Cookie AutoDelete plugin. However I am not sure if it helps in this case. From what I understand the site steal cookies in flight, between your browser and the ISP. I am not sure how this is possible with all of the SSL and TLS and such. There should not be man in the middle type of attacks, unless you specifically authorized third party certificate. Security and convenience do not live well together. If you want your data secure, make sure you are logging out and clearing yo
    • I think "laziness" is too strong. I have about a HUNDRED different logins I need to know. I need to log in multiple times / day and the total time spent logging i to websites adds up. Security theater TFA questions don't have realistic answers: I don't have a favorite fruit. Use of my cell phone for TFA is concerning because Companies have been caught selling cell phone numbers to advertisers. Also if I lose my phone, I am in really deep trouble - unable to operate normally until I get a new one and g

      • I have about a HUNDRED different logins I need to know. I need to log in multiple times / day and the total time spent logging i to websites adds up....

        You are making a strong case for a password vault. I too have 'about a HUNDRED' different logins. The difference is that I only know about 4 of them. The rest are all auto-generated and my vault "types" them into the relevant login form with just a couple of clicks/taps/keystrokes.

        When given a choice regarding MFA, I chose options that allow one to register two devices specifically to mitigate the 'lose my phone' concern.

    • I'm hypothesizing that, if those technologies are released out into the wrong hands, I don't know where it could go. It's dangerous. https://bit.ly/3EMVjBe [bit.ly]

  • If this is what I think it is, a lot of sites give you a choice of sending the authentication code different ways, including a phone call. Most people nowadays have smart/cell phones but a landline is probably better if you have it.

    Maybe I'm not getting it right. If the user safely gets the code, by phone for instance, could intruders still capture the code as the legitimate user is sending it back to the institution via Man-In-The-Middle?

  • ... bypass two-factor authentication (2FA) security codes.

    Google said they would push all accounts to use 2FA. Last month, I tried to enable 2FA on a gMail account: It's not in the security menu, as the Google FAQ claims. Google doesn't allow me to enable 2FA.

    A popular banking service here sends a physical OTP dongle to customers. I don't want a dongle that can only be used at one web-site. Yet no bank offers the ability to load a 2FA secret onto an authenticator app, not even as a in-person service.

  • Session hijacking is an entirely different attack.

Slashdot Top Deals

I've noticed several design suggestions in your code.

Close