5 ms·

Sysadmin at a school: we use GMail for our students and faculty, and we got hit by this hard right before the holiday break. Three employees and a handful of s

Sysadmin at a school: we use GMail for our students and faculty, and we got hit by this hard right before the holiday break. Three employees and a handful of students all got hit by the attack within a two hour period. It's the most sophisticated attack I've seen. The attackers log in to your account immediately once they get the credentials, and they use one of your actual attachments, along with one of your actual subject lines, and send it to people in your contact list. For example, they went into one student's account, pulled an attachment with an athletic team practice schedule, generated the screenshot, and then paired that with a subject line that was tangentially related, and emailed it to the other members of the athletic team. They were using bit.ly to obscure the address (in Russia). We had to take our whole mail system down for a few hours while we cleaned it up.

camtarn 10y ago
Holy crap. That is some serious ingenuity and skill being applied to the cause of evil.
colinbartlett 10y ago
Requiring 2-factor auth would prevent this from being exploitable, right? Probably impossible in a school environment but in an enterprise situation, more palatable perhaps.
- IanCal 10y ago
  I don't think so, I'm not sure how it could. One of the tweets points out that something like lastpass would help with this as it wouldn't allow you to autofill your password (as it's not on the google the domain), but then you could get it manually from there anyway.
  - danielbarla 10y ago
    Well, when the attacker attempts to log in via the stolen credentials, they would get the 2FA check, and you would get an SMS. Normally this would alert you to the fact that someone is logging in to your account, and would stop the attacker since they lack the 2FA one time pass. In this case though, since you've already fallen for the "I'm trying to log in to Google again", the attacker will probably fake the 2FA screen as well, and you'll merrily type it in.
    - IanCal 10y ago
      I was thinking this would be done automatially. You enter username and password, they send to google and get a 2fa request. Show you the same screen and ask for your 2FA pass, which they then send on and they're in. Someone else mentioned U2F would work though as that's tied to the domain, but I don't really know much about that.
    - michaelt 10y ago
      1. You visit the attacker's page and give them your username and password. 2. The attacker immediately tries them, triggering an SMS to you and an 'enter SMS code' page for them. 3. The attacker shows the 'enter SMS code' page to you, and you enter the code from the SMS you just received, giving it to the attacker. 4. The attacker completes their login using the SMS code. 5. The attacker shows the user some believable error message (implying an error on Google's end, or a typo in the SMS code) then forwards the user to the legitimate Google login page.
      - danielbarla 10y ago
        Yep, that's what I'm saying too. If you've fallen for providing 1FA, you'll fall for 2FA too, since you think it's legit.
        mikeash 10y ago
        Apple's 2FA for iCloud will likely avoid this if you're careful. They do a GeoIP lookup of where the request is coming from and show the approximate location of the login attempt before they show you the 2FA code. For example, when logging in legitimately from home, it'll say that there's a login attempt from the city where I live. In the likely case where the phisher's server isn't in this area, it'll show something else, and I'll know what's up. Obviously this isn't perfect because it depends on people actually paying attention to that, and on not having too many false positives due to GeoIP failures, but it seems like a nice improvement. Apple has a nice UI on it (no surprise, I'm sure) where they show a map centered on the location in question, but even SMS-based solutions could include a quick "Login attempt from City" along with the code.
  - tscs37 10y ago
    Autofill should usually pull the user out of their tunnel vision and focus them on the site and what they are doing. Not perfect but atleast they're not blindly typing in passwords.
- dankohn1 10y ago
  No. A man-in-the-middle phishing attack can ask you for your second factor and pass it through to Gmail.
  - midgetjones 10y ago
    That's assuming the attacker could log in with it before it expired, isn't it?
    - danieldk 10y ago
      Yes, but as per the standard TOTP codes are valid for a window of 1 minute. TOTP barely protects against phishing. What you want is an U2F key as the second factor. It's not like they are expensive anyway (usually 7-15 Euro) and quite some large services support U2F tokens already (Google, Dropbox, GitHub, Fastmail, etc.).
      - midgetjones 10y ago
        Thanks! Is the 1 minute window always the case? In the authenticator app, it seems like codes expire after ~30 seconds. If I wait till the last few seconds before using the code, does that make me any safer?
        jpalomaki 10y ago
        In some cases the server is configured to accept multiple codes (prev, current, next) to handle timesync issues between server and client (where the app is running).
        wopwopwop 10y ago
        No. How long does it take from you entering the code to the code reaching Google? A few tens of miliseconds? With a phisher in the middle it's a couple extra miliseconds.
        danieldk 10y ago
        The RFC recommends a time step of 30 seconds + permitting at most one previous time step for handling out of sync clocks and slow/late entry: The validation system should compare OTPs not only with the receiving timestamp but also the past timestamps that are within the transmission delay. A larger acceptable delay window would expose a larger window for attacks. We RECOMMEND that at most one time step is allowed as the network delay. [...] We RECOMMEND a default time-step size of 30 seconds. This default value of 30 seconds is selected as a balance between security and usability. Since the client's clock could be in the behind or ahead of the server's clock, I have to correct myself and the window would be 90 seconds. One could be a bit strict and e.g. the previous time step only until 1/2-way the current time step, which would bring the window make to 60 seconds. At any rate, all these timeframes are far to large to avoid real-time phishing attacks.
- Jarwain 10y ago
  My school is actually rolling out optional 2-factor auth. I'm not a fan of the system they use^, but it's neat that a University is taking advantage of some security best practices. ^Instead of using "standard" 2-factor that generates a code on-the-fly within an app like GAuth or Authy, users receive a text message with 10 codes. The first digit of every code increases sequentially (0972,1042,2512,etc), must be used in that order (0 code on first login, 1 code on second, etc.), and the page informs the user which number they're on.
  - oxguy3 10y ago
    Oh my god that's awful, what's the point of making it so counterintuitive?? I'll never understand the motivation of companies that roll their own 2FA instead of just using TOTP or Authy.
    - Jarwain 10y ago
      It was probably the worst way they could have implemented 2FA; we're still vulnerable to a MITM attack. One of the more annoying things is that the codes are sent from a random 386 number. Out of the 7+ texts I've received thus far, only 2 were from the same number. Apparently the company they're using is named https://duo.com/ https://duo.com/
      - nerdponx 10y ago
        Huh, I've heard good things about Duo. They're not a nobody at any rate.
      - grivescorbett 10y ago
        That's odd, we use duo at work and it's great. Every user is configured to get a push notification directly to the device which bypasses the issues with SMS.
        Jarwain 10y ago
        That requires the user to use the Duo app though, right? I don't recall whether I had the option to use the app when I enabled MFA initially. However, after the fact, and as far as I can find, I cannot go back and enable the app.
- wopwopwop 10y ago
  Not really. The phisher can just ask for the second factor the same way they ask for the password.
  - angrygoat 10y ago
    U2F knocks this on the head - a MITM site won't have the secret required to generate the token.
    - wopwopwop 10y ago
      Wrong. The target domain asks the MITM for the secret, the MITM asks the victim for the secret, the victim gives the secret to the MITM and the MITM gives the secret to the target domain. Just like with the password. You have no idea what you're talking about and yet you downvote first and ask questions later.
- hobarrera 10y ago
  Probably not; the fake page can also prompt for the second factor and then quickly do the real authentication using that.
  - jdavis703 10y ago
    This is why having a warning for non-HTTPs sites is so important: http://boingboing.net/2016/11/05/chrome-is-about-to-start-warni.html http://boingboing.net/2016/11/05/chrome-is-about-to-start-wa....
    - hobarrera 10y ago
      Yup, hopefully that would make a difference, though if we keep getting news like today's GoDaddy validation bug, this'll gradually lose value. :(
    - anchpop 10y ago
      I don't see how that would help here. Couldn't the phishing site have HTTPS?
- Niten 10y ago
  U2F would prevent this from being exploitable, but one-time password schemes like TOTP would not.
  - RedPanda250 10y ago
    Why would TOTP not suffice to prevent this exploit ?
    - extrapickles 10y ago
      They can use the TOTP token to auth themselves where as U2F will not work if you are the middle-man. U2F basically[0] signs the current URI and HTTPS key and sends it back. If there is a man-in-middle then the signatures will not match and the auth will fail. [0]: https://developers.yubico.com/U2F/Protocol_details/Overview.html https://developers.yubico.com/U2F/Protocol_details/Overview....
- gaia 10y ago
  2FA would make it harder to exploit, but phishing attacks are getting fancier. They capture the 2FA code you enter and immediately start a session elsewhere with your password and 2FA. Hardware 2FA, a security key, (such as a Yubikey) is the only likely way to prevent phishing (excluding targets of state actors) https://support.google.com/accounts/answer/6103523?hl=en https://support.google.com/accounts/answer/6103523?hl=en
  - smeehee 10y ago
    Google can prompt you to confirm the login via your phone. It appears to work well: there's a time-out, and this time-out is also triggered if a second login attempt is made in parallel (and reaches the confirmation stage). So… whichever login attempt gets to confirmation stage last wins (not relevant in this situation), and the confirmation screen on (at least) my phone does not indicate anything regarding location (which is highly relevant). This looks a little weaker than TOTP (you're basically trading a little security for the convenience of not entering a code while keeping the second factor) and a lot weaker than U2F.
  - shimon_e 10y ago
    > Hardware 2FA, a security key, (such as a Yubikey) is the only likely way to prevent phishing For now.
    - deleted 10y ago
      [deleted]
    - semi-extrinsic 10y ago
      Or manual challenge-response, like some internet banking tokens have.
  - acchow 10y ago
    Why would a yubikey prevent this? They can still send the 2FA code to Google to start your session...
    - 10y ago
- jimmaswell 10y ago
  I feel like all these kinds of extra security burdens aren't worth it. If you could quantify and add up all the inconvenience caused by extra security past simple password logins, affecting all users always, it would surely be more than what would have been caused by the attacks prevented, temporarily affecting a few users.
  - jdavis703 10y ago
    What if they're able to comprise a person who works in HR who probably has copies of passports, social security numbers and other highly-sensitive PII in their email inbox? The fact is people send around all kinds of sensitive information via email, including IT/engineering who probably has discussions about various security holes they're working on patching.
drzaiusapelord 10y ago
>They were using bit.ly to obscure the address (in Russia). Clicking on links from email is such an edge case its bewildering we allow any link to be routable from an email client. I'd love to see my email client block this stuff by default. There's no case for me that an email should lead me to Russia, be it via a shortener or not. Or to a IP address that is on any honeypot list or has a suspicious rating. I think we need to rethink what is allowed to route out of emails. I can see a whitelist of legitimate and vetted companies with large warnings for anything else. A little AI would go a long way here. Maybe visit the domain, verify the site has SSL, verify its not another country, verify its not trying to impersonate sites, check reputation lists, etc. A handful of predicative rules put into a browser or email client would greatly help here. Its clear we can't spot phishing attempts well, but we may be able to make actually visiting the phishing site as difficult as possible. Links in emails should be seen as extremely hostile by default.

camtarn 10y ago

Holy crap. That is some serious ingenuity and skill being applied to the cause of evil.

colinbartlett 10y ago

Requiring 2-factor auth would prevent this from being exploitable, right? Probably impossible in a school environment but in an enterprise situation, more palatable perhaps.

IanCal 10y ago
I don't think so, I'm not sure how it could. One of the tweets points out that something like lastpass would help with this as it wouldn't allow you to autofill your password (as it's not on the google the domain), but then you could get it manually from there anyway.
- danielbarla 10y ago
  Well, when the attacker attempts to log in via the stolen credentials, they would get the 2FA check, and you would get an SMS. Normally this would alert you to the fact that someone is logging in to your account, and would stop the attacker since they lack the 2FA one time pass. In this case though, since you've already fallen for the "I'm trying to log in to Google again", the attacker will probably fake the 2FA screen as well, and you'll merrily type it in.
  - IanCal 10y ago
    I was thinking this would be done automatially. You enter username and password, they send to google and get a 2fa request. Show you the same screen and ask for your 2FA pass, which they then send on and they're in. Someone else mentioned U2F would work though as that's tied to the domain, but I don't really know much about that.
  - michaelt 10y ago
    1. You visit the attacker's page and give them your username and password. 2. The attacker immediately tries them, triggering an SMS to you and an 'enter SMS code' page for them. 3. The attacker shows the 'enter SMS code' page to you, and you enter the code from the SMS you just received, giving it to the attacker. 4. The attacker completes their login using the SMS code. 5. The attacker shows the user some believable error message (implying an error on Google's end, or a typo in the SMS code) then forwards the user to the legitimate Google login page.
    - danielbarla 10y ago
      Yep, that's what I'm saying too. If you've fallen for providing 1FA, you'll fall for 2FA too, since you think it's legit.
      - mikeash 10y ago
        Apple's 2FA for iCloud will likely avoid this if you're careful. They do a GeoIP lookup of where the request is coming from and show the approximate location of the login attempt before they show you the 2FA code. For example, when logging in legitimately from home, it'll say that there's a login attempt from the city where I live. In the likely case where the phisher's server isn't in this area, it'll show something else, and I'll know what's up. Obviously this isn't perfect because it depends on people actually paying attention to that, and on not having too many false positives due to GeoIP failures, but it seems like a nice improvement. Apple has a nice UI on it (no surprise, I'm sure) where they show a map centered on the location in question, but even SMS-based solutions could include a quick "Login attempt from City" along with the code.
- tscs37 10y ago
  Autofill should usually pull the user out of their tunnel vision and focus them on the site and what they are doing. Not perfect but atleast they're not blindly typing in passwords.
dankohn1 10y ago
No. A man-in-the-middle phishing attack can ask you for your second factor and pass it through to Gmail.
- midgetjones 10y ago
  That's assuming the attacker could log in with it before it expired, isn't it?
  - danieldk 10y ago
    Yes, but as per the standard TOTP codes are valid for a window of 1 minute. TOTP barely protects against phishing. What you want is an U2F key as the second factor. It's not like they are expensive anyway (usually 7-15 Euro) and quite some large services support U2F tokens already (Google, Dropbox, GitHub, Fastmail, etc.).
    - midgetjones 10y ago
      Thanks! Is the 1 minute window always the case? In the authenticator app, it seems like codes expire after ~30 seconds. If I wait till the last few seconds before using the code, does that make me any safer?
      - jpalomaki 10y ago
        In some cases the server is configured to accept multiple codes (prev, current, next) to handle timesync issues between server and client (where the app is running).
      - wopwopwop 10y ago
        No. How long does it take from you entering the code to the code reaching Google? A few tens of miliseconds? With a phisher in the middle it's a couple extra miliseconds.
      - danieldk 10y ago
        The RFC recommends a time step of 30 seconds + permitting at most one previous time step for handling out of sync clocks and slow/late entry: The validation system should compare OTPs not only with the receiving timestamp but also the past timestamps that are within the transmission delay. A larger acceptable delay window would expose a larger window for attacks. We RECOMMEND that at most one time step is allowed as the network delay. [...] We RECOMMEND a default time-step size of 30 seconds. This default value of 30 seconds is selected as a balance between security and usability. Since the client's clock could be in the behind or ahead of the server's clock, I have to correct myself and the window would be 90 seconds. One could be a bit strict and e.g. the previous time step only until 1/2-way the current time step, which would bring the window make to 60 seconds. At any rate, all these timeframes are far to large to avoid real-time phishing attacks.
Jarwain 10y ago
My school is actually rolling out optional 2-factor auth. I'm not a fan of the system they use^, but it's neat that a University is taking advantage of some security best practices. ^Instead of using "standard" 2-factor that generates a code on-the-fly within an app like GAuth or Authy, users receive a text message with 10 codes. The first digit of every code increases sequentially (0972,1042,2512,etc), must be used in that order (0 code on first login, 1 code on second, etc.), and the page informs the user which number they're on.
- oxguy3 10y ago
  Oh my god that's awful, what's the point of making it so counterintuitive?? I'll never understand the motivation of companies that roll their own 2FA instead of just using TOTP or Authy.
  - Jarwain 10y ago
    It was probably the worst way they could have implemented 2FA; we're still vulnerable to a MITM attack. One of the more annoying things is that the codes are sent from a random 386 number. Out of the 7+ texts I've received thus far, only 2 were from the same number. Apparently the company they're using is named https://duo.com/ https://duo.com/
    - nerdponx 10y ago
      Huh, I've heard good things about Duo. They're not a nobody at any rate.
    - grivescorbett 10y ago
      That's odd, we use duo at work and it's great. Every user is configured to get a push notification directly to the device which bypasses the issues with SMS.
      - Jarwain 10y ago
        That requires the user to use the Duo app though, right? I don't recall whether I had the option to use the app when I enabled MFA initially. However, after the fact, and as far as I can find, I cannot go back and enable the app.
wopwopwop 10y ago
Not really. The phisher can just ask for the second factor the same way they ask for the password.
- angrygoat 10y ago
  U2F knocks this on the head - a MITM site won't have the secret required to generate the token.
  - wopwopwop 10y ago
    Wrong. The target domain asks the MITM for the secret, the MITM asks the victim for the secret, the victim gives the secret to the MITM and the MITM gives the secret to the target domain. Just like with the password. You have no idea what you're talking about and yet you downvote first and ask questions later.
hobarrera 10y ago
Probably not; the fake page can also prompt for the second factor and then quickly do the real authentication using that.
- jdavis703 10y ago
  This is why having a warning for non-HTTPs sites is so important: http://boingboing.net/2016/11/05/chrome-is-about-to-start-warni.html http://boingboing.net/2016/11/05/chrome-is-about-to-start-wa....
  - hobarrera 10y ago
    Yup, hopefully that would make a difference, though if we keep getting news like today's GoDaddy validation bug, this'll gradually lose value. :(
  - anchpop 10y ago
    I don't see how that would help here. Couldn't the phishing site have HTTPS?
Niten 10y ago
U2F would prevent this from being exploitable, but one-time password schemes like TOTP would not.
- RedPanda250 10y ago
  Why would TOTP not suffice to prevent this exploit ?
  - extrapickles 10y ago
    They can use the TOTP token to auth themselves where as U2F will not work if you are the middle-man. U2F basically[0] signs the current URI and HTTPS key and sends it back. If there is a man-in-middle then the signatures will not match and the auth will fail. [0]: https://developers.yubico.com/U2F/Protocol_details/Overview.html https://developers.yubico.com/U2F/Protocol_details/Overview....
gaia 10y ago
2FA would make it harder to exploit, but phishing attacks are getting fancier. They capture the 2FA code you enter and immediately start a session elsewhere with your password and 2FA. Hardware 2FA, a security key, (such as a Yubikey) is the only likely way to prevent phishing (excluding targets of state actors) https://support.google.com/accounts/answer/6103523?hl=en https://support.google.com/accounts/answer/6103523?hl=en
- smeehee 10y ago
  Google can prompt you to confirm the login via your phone. It appears to work well: there's a time-out, and this time-out is also triggered if a second login attempt is made in parallel (and reaches the confirmation stage). So… whichever login attempt gets to confirmation stage last wins (not relevant in this situation), and the confirmation screen on (at least) my phone does not indicate anything regarding location (which is highly relevant). This looks a little weaker than TOTP (you're basically trading a little security for the convenience of not entering a code while keeping the second factor) and a lot weaker than U2F.
- shimon_e 10y ago
  > Hardware 2FA, a security key, (such as a Yubikey) is the only likely way to prevent phishing For now.
  - deleted 10y ago
    [deleted]
  - semi-extrinsic 10y ago
    Or manual challenge-response, like some internet banking tokens have.
- acchow 10y ago
  Why would a yubikey prevent this? They can still send the 2FA code to Google to start your session...
  - 10y ago
jimmaswell 10y ago
I feel like all these kinds of extra security burdens aren't worth it. If you could quantify and add up all the inconvenience caused by extra security past simple password logins, affecting all users always, it would surely be more than what would have been caused by the attacks prevented, temporarily affecting a few users.
- jdavis703 10y ago
  What if they're able to comprise a person who works in HR who probably has copies of passports, social security numbers and other highly-sensitive PII in their email inbox? The fact is people send around all kinds of sensitive information via email, including IT/engineering who probably has discussions about various security holes they're working on patching.

drzaiusapelord 10y ago

>They were using bit.ly to obscure the address (in Russia). Clicking on links from email is such an edge case its bewildering we allow any link to be routable from an email client. I'd love to see my email client block this stuff by default. There's no case for me that an email should lead me to Russia, be it via a shortener or not. Or to a IP address that is on any honeypot list or has a suspicious rating. I think we need to rethink what is allowed to route out of emails. I can see a whitelist of legitimate and vetted companies with large warnings for anything else. A little AI would go a long way here. Maybe visit the domain, verify the site has SSL, verify its not another country, verify its not trying to impersonate sites, check reputation lists, etc. A handful of predicative rules put into a browser or email client would greatly help here. Its clear we can't spot phishing attempts well, but we may be able to make actually visiting the phishing site as difficult as possible. Links in emails should be seen as extremely hostile by default.