UK Parliament hack: Really, a brute-force attack? Really? Just under 90 Parliamentary email accounts were compromised by a brute force attack on the parliamentary network over the weekend. And there is a long-established technology which can normally see off this kind of attack. Two factor authentication (2FA) technology has been ubiquitous among enterprises as an verification …
This is for remote logins. I found dropping all connection attempts from the source IP address for only ten minutes was sufficient for the attacker try somewhere else. The attacker stood no chance as I disable password authentication before making a machine accessible over the internet. (The number of attempts to brute force user names and passwords was an annoying waste of bandwidth.)
Good news! When May makes public key cryptography illegal I will have to go back to allowing password authentication. Come to think of it, the ban will include ssh and we will all have to go back to using telnet.
As someone who works in Local Government we are forced by Central Government to limit the amount of attempts before disabling an account (something we already did before there rules were brought in). But does this mean it's one rule for us, and a different one for them?
That was my first thought. My second is to only allow password-less logins via the MP creating a public/private key pair and handing over the public key to the IT guys in a controlled setting.
Works fine for ssh (where I can upload my key and store it in the authorized_keys file, then disable login via a password), so I'm pretty sure that it should work for TLS/SSL as well (and is apparently resistant to MITM, with ssh, at least). You might have a bit more work to do with regard revocation of an authorised login key, but that's par for the course.
All of this comes down to a trade-off between how strong the system can be, versus how much whine you are prepared to tolerate from the users. Since the users in this case are MPs who are trusted with state secrets and are almost the highest authority in the land, I rather suspect that it is they and their great power which is the main cause of trouble.
From a sysadmin point of view, even just the simple TCP rate limit function provided by UFW is useful, in that it stops single IPs from banging away at a machine. Fail2Ban provides a much better level of protection, especially when the "findtime" is extended enough that somewhat more clever botnet attackers are detected and excluded. The problem with both is that a fat-fingered or dyslexic user will get passwords wrong, and will repeatedly get locked out until they demand that the security levels be decreased for them.
This is why 2FA is so important and so essential; use 2FA and only the dozy users who cannot follow instructions get left behind, and the cure for them is simple: get their secretary to handle all the technology for them a la Tony Blair.
"This is why 2FA is so important and so essential; use 2FA and only the dozy users who cannot follow instructions get left behind, and the cure for them is simple: get their secretary to handle all the technology for them a la Tony Blair."
Unless, of course, they have Most Secret clearance and therefore CAN'T use secretaries (because they don't have the clearance, eh?). Or the ministers only trust themselves and so on. AND they're in safe districts so you can't count on them being forced out.
Again, this article appears to make the assumption that Email is a web based login.
It is not possible to apply 2FA to email clients that use IMAP, SMTP, MAPI or EAS logins, which means that accessing your email by Thunderbird, Outlook, or smartphone Mail Apps, you can't use 2FA.
If access to the mail server was only possible over a VPN, then you can apply 2FA to the VPN logins, but that's not what happened here.
I access my gmail over imap and I have 2FA enabled.
Yes, that's because the IMAP protocol is tacked on to a web-based email service. Pure IMAP has no facility to provide 2FA.
You don't access email over SMTP
No, my bad, I meant POP3. However, if a server is using POP-before-SMTP, then it is possible to enumerate logins over SMTP.
MAPI is a programming interface.
Not just a programming interface, MAPI/RPC is the protocol used by older Outlook clients to talk to Exchange servers.
EAS can be secured using certificates thereby making the device the something you have.
a certificate is NOT 2FA, it's too easy to proxy.
There's no reason why IMAP can't accept OTP. It's not something I've looked into, but I imagine it's possible to, for example, get Dovecot to use PAM for authentication and then configure the Google Authenticator PAM module.
Dovecot does seem to have a built-in OTP mechanism, but a very brief search in their documentation doesn't give any details on how it works.
If you used the PAM approach above you'd be able to configure to accept the OTP code by appending it to your password. That way you avoid having to modify the IMAP protocol in any way.
There is one reason - failed logins.
Consider the following.
1) you have a mobile device set to snychronise every 30 mins, 1 hour or couple of hours
2) it is doing that in the background to give you notifications
3) 2FA is enabled to change your password
At some point, you are going to have a mail client trying to check your emails in the background using an old 2FA password. Whether that be because your sync time exceeds the 2FA timeout or maybe you go out of signal for a while and come back without opening your phone to update the password.
You then open your phone to check your emails and find yourself locked out because your client has been using the wrong 2FA password.
I think the point of this is that any attempt at 2FA is a bodge unless you have a client that supports it natively, or the client is wrapped up in something else that handles the 2FA before allowing you access to your email.
@beddo: I don't know what you mean by "2FA password", but I assume it's the token. And it is *not required at all* with an application password. The "something you have" is the device itself, which is why a separate application password is issued for each device and not recorded (you copy it straight into the device and then close the web page that generated it).
In my case, the 2FA token is valid for only around a minute, because it uses TOTP. I log in weekly using the web interface to have a look at the spam folder and to read some less important messages that I sort to IMAP folders using a server-side sieve script. Normally I read mail on a desktop using a client which has an application password twice daily, and I don't need my phone near me for a TOTP token. If the machine were to be stolen, it could not be used to access my email, because when I'm away it's locked using my Mac login password, and this "locks" the encrypted macOS keychain on which the mail client stored the application password. Although my Mac login password is reasonably strong, it still needs to be memorable so isn't as strong as some others I use. So, if the machine is stolen, the reasonable login password should slow the perpetrator down long enough for me to invalidate the application password using the server's web interface and I'm golden. And after I do that, I can still use all my other devices (and their application passwords), or my master password and TOTP, to read my mail.
"MAPI/RPC is the protocol used by older Outlook clients"
RPC is the protocol, MAPI is a programming interface. Outlook shouldn't be connecting directly to exchange over the Internet, there should be a VPN involved.
"a certificate is NOT 2FA, it's too easy to proxy."
Not sure I follow you. The server holds the public key, client holds the private key. This key pair is unique to the user/client combination. If the device is lost/compromised the key is revoked. How does a proxy affect this?
The point here is that you can force some form of 2FA for all email users. If you say you can't because you need to support xyz crappy outdated client then you don't have a secure system. Security vs usability is always a balancing act. If you're the government you should probably be tipping the scales towards security
Outlook anywhere is in 2010, not sure about 2007. No MAPI (MAPI) is a programming interface. I'm guessing you mean RPC over HTTPS. It doesn't use that either though. Outlook anywhere doesn't support any kind of 2FA (as far as I know). Outlook anywhere is very convenient, but it's not particularly secure as it's only protected by a password. If you're using Outlook you should use a VPN.
t is not possible to apply 2FA to email clients that use IMAP, SMTP, MAPI or EAS logins, which means that accessing your email by Thunderbird, Outlook, or smartphone Mail Apps, you can't use 2FA.
Errm... I'm looking at my 2FA-protected (it is to laugh!) iPad at this very moment. Apple Mail is 'guarded' by 2FA, though in Apple's case this is purest security theatre. Should I log into Mail from somewhere not 'trusted', or should a 'trusted' device be suspicious of my login attempt, 2FA kicks out a challenge and I must say that I am really me, and then 2FA sends six numbers to all 'trusted' devices, including the one that I'm attempting to log in from, and I need merely enter those six numbers in the indicated space. Yes, Apple really does send the 2FA challenge/reply pair to the device you're logging in from. Madness.
Now, if they didn't do that, then 2FA would actually work. And we'd have an actual working, 2FA-protected, email client using IMAP and SMTP.
Microsoft tries to protect Outlook.com email, and screws that up, just not the same way that Apple does. There are many, many, MANY ways to get this wrong, so I'm not surprised that people think that it can't be done.
It doesn't matter if there's no 2FA support in your IMAP/POP client, because 2FA systems typically require an "application password" for those clients that is automatically generated and then copied into the client's configuration. Because the user doesn't get to choose the application password, if properly implemented it will never be weak. Because it can be invalidated or reset from the server without affecting the master password/2FA pair, the user doesn't even need to know what it is or record it.
This isn't theory: the paid email service I use works exactly like this. And, it isn't Gmail, but I believe that works the same way.
//The incident raises bigger questions - for the private sector as well as government - around how it's often the case that adequate defences are only put in after an attack.//
Often? It's practically always, for everything.
People can complain about something for years, but it isn't important until an entire towerblock burns.
The reason is down to cost, which is up front and comes out of my budget and benefits which are nebulous and will probably be reaped by some other department.
Anyway the system works so why spend money on something that will be perceived by users and upper management as another bloody thing IT have done to stop me doing my work.
Can I be the first to point out the stupidity of this hack.
So you brute force parliamentary passwords setting off an alarm in the process letting them know you are brute forcing passwords.
What's going to happen next?
Do they really think they are not going to get everyone to change passwords and potentially upgrade the system?
I'm just waiting for someone to claim backdoors in encryption will stop this sort of thing from happening.
generally while you're brute forcing the passwords in an obvious way and giving the techs the runaround to sort that out, they're too busy to notice you discretely dropping trojans or hacking the system somewhere else ...
More likely to be an idiot script-kiddie though and, as a terrorist act involving a computer, we'll need to ban encryption obviously ...
This post has been deleted by its author
"Can I be the first to point out the stupidity of this hack.
So you brute force parliamentary passwords setting off an alarm in the process letting them know you are brute forcing passwords.
What's going to happen next?"
Not sure I'm seeing the stupidity here. What's already happened is they read and probably downloaded all the emails from the accounts they've managed to access. What happens next is they sell them to the highest bidder, hand them over to journalists and/or wikileaks, or just keep it to themselves for the next time their agency/diplomats need some leverage. What doesn't happen next is that the people who already stole a load of data care in the slightest that it might be harder for someone else to do the same thing. Changing passwords and upgrading the system isn't going to uncompromise the data that was already taken.
Right so they're politicians, safe to assume they all used their last name, their wife's maiden name, or their dog's name as passwords and they wonder how they got pwned?
Just like most people in their position, the minute the IT lacky said they needed a password with min 10 chars, one upper case, one number and a symbol they boomed, "Do you know who I am?! I haven't got time to remember all that. Now make it simple or else!".
- All staff working in the parliamentary estate use the system, not just MPs. That includes over 2,000 staff of Parliament itself and however many staff members are employed by individual MPs.
- As an internal operational matter of the operations of Parliament this is likely to be covered by parliamentary privilege, so short of some resulting major criminal breach no action will be taken.
Send an e-mail with a link to content on your own Web Server to an @parliament.uk address. Wait two minutes and check the web server logs. The content of your e-mail and any attached document will be scanned and you will get a visit from Germany, the US or London to check the contents of any links provided. Apparently it is 'a service' provided by MessageLabs. I would be more concerned about that than some Russian trying to hack passwords. America already has full access to your personal discussions with a member of Parliament or a member of The House of Lords.
So, I emailed Parliament, as I did yesterday, but this time I sent my server link.
It took a whole minute and then
70.39.157.193 - - [27/Jun/2017:11:38:12 +0200] "GET / HTTP/1.1" 200 616 "-" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)" "-"
apparently Windows 7 32bit/64bit Internet Explorer 9, maybe
CustName: GTT, Tier-1 Cloud, City: McLean, StateProv: VA, PostalCode: US-22102 assigned to PacketExchange vaguely located in Wauconda, Illinois?
a thorough sniff c/o http://anti-hacker-alliance.com/index.php?ip=70.39.157.193
shows that only 1 anti-spam org out of 96 blocks this sensor I.P.v4, and that reputationally speaking there are only nine bad nearby I.P.v4's. I don't think this is too bad service, at least it employs a few guys in IT, and hopefully it will stop clowns opening poisoned pdfs, eh adobe?
Yup.. GTT. That's one of them. Presumably related to,
http://static.symanteccloud.com/estore/Datasheets/en/Product/SHAV_SHAS/AV_AS_Datasheet.pdf
Anti Spam and Anti Virus.
"Unique ‘Link following’ feature (scanning of URLs within emails for potential links to malware), providing an additional layer of protection for your business."
It will/does download pdfs but does not scan links within them so you could still manage to provide a link within a document that would/could lead the recipient to a nasty. As such it is not bullet proof.
OK Fine it's a 'useful' service but it is still gifting what might be potentially sensitive and ideally privileged information about your communications with your parliamentary representatives.
I've been doing all of these for a while with various systems in my care.
And as the article points out, these techniques have been around for quite a while, and if whoever was in charge of PM's mail etc systems didn't bother to use any of them, that's very bad practice indeed.
One moderately laughable piece I wrote recently focuses mainly on auto-clobbering bruteforcers, but has pointers to other resources too: http://bsdly.blogspot.com/2017/04/forcing-password-gropers-through.html
"weak passwords that did not conform to guidance issued by the Parliamentary Digital Service"
The problem wasn't weak passwords, the problem was allowing weak passwords in the first place, and in the second instance, not detecting them by running your own hashing/cracking attempts on them. That's before we get on to 2FA etc.
Since the Reg just published this story of an SME being find because they did no peentration testing and some other things
(https://www.theregister.co.uk/2017/06/27/boomerang_video_hack_ico_fine/)
How much will the ICO be able to fine Whitehall?
Or will Whitehall argue they outsourced penetration testing to North Korea?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
