Feeds

back to article European Parliament reports HACK ATTACK, turns off public Wi-Fi

The European Parliament has disabled its public Wi-Fi network following the detection of a suspected hacking attack which has been linked to the exposure of weak security practices at the institution by a French media outlet. The private network of the European institution is thought to be secure but techies are advising users …

COMMENTS

This topic is closed for new posts.
Anonymous Coward

It isn't a wifi issue, it's the weakness of SMTP broadcasting passwords in the clear.

Encrypt everything. Come on Dark Mail.

0
3
Pirate

SMTP only broadcasts passwords in the clear if the system administrators can't find their own asses with both hands in a small, well-lit room. Sadly, this description probably applies to the contractors they're using. (CSC? HP? Almost certainly a company whose core competency involves procurement lawyers, not technology.)

3
0
Bronze badge

Re: It isn't a wifi issue...

Suggest you read the references (specifically http://epfsug.eu/wws/arc/epfsug/2013-11/msg00051.html ): the public Wi-Fi of the Parliament (EP-EXT Network) wasn't encrypted, just like the vast majority of public hotspots... So a MiM attack is pretty straight-forward. It would seem the innovation in the attack was to mimic certain aspects of the EP IT systems so as to gain access credentials.

Also, like many quality deployments the EP Private Wi-Fi network (EP-PRIVATE) is secured through certificates.

The lesson to ALL is if you have a guest/public WiFi network and you permit access to corporate systems from this network then you are also potentially vulnerable to this style of attack.

1
0
Bronze badge

Re: It isn't a wifi issue...

Having read some more, it seems that the EP didn't and don't run any form of IDS, as otherwise a rogue AP using the EP-EXT SSID would of been flagged.

Perhaps the EP need to engage some qualified UK consultants to deploy a WiFi network based on Manual-Y. Which raises a question about the security standards used by the EP and who oversee's them.

0
0
Silver badge

I am gobsmacked!

Tell me it is not true. I thought that this network was completely secure. Not.

0
1
Silver badge

Re: I am gobsmacked!

Network <--//--> Secure

1
0

Not SMTPauth - HTTP SSLStripping

The linked post seems to be of the opinion that the cause of the problem was a bogus web login page (or, SSLstripping+sniffing).

If SMTP (and POP and IMAP and active sync) were hard configured to use SSL, then no details would have been revealed - the client would not fall back to a non-encrypted connection.

It begs the question of how the attacker was able to redirect a browser to the non-SSL login page - at a guess the login page must be the gateway to a captive portal.

"wasn't encrypted [...] So a MiM attack is pretty straight-forward" - disagree - the layer at which you implement encryption is not nearly as important as how you implement the encryption.

0
0
Bronze badge

Re: Not SMTPauth - HTTP SSLStripping

"wasn't encrypted [...] So a MiM attack is pretty straight-forward" - disagree - the layer at which you implement encryption is not nearly as important as how you implement the encryption.

? The WiFi network totally open, there was no encryption hence a MiM attack on the WiFi network to gain access to the traffic is pretty straight-forward. Yes the how encryption is implemented is important, hence the reason why you should use WPA2-Enterprise on your WiFi networks. WPA2-Private can be just as good if the PSK is properly managed, but as you note if the key is known to all the encryption is compromised.

Once the MiM is in and has full access control over the network traffic then the way security has been configured for end-to-end communications becomes important as you note. My take on the webpage is that it enabled the collecting of EP Intranet access credentials. Hence to gain email access details some additional server spoofing was performed by the MiM to get the email clients to initiate a connection and send login credentials. It would seem that the way security was set up on the EP mail servers combined with the automatic behaviour of some client systems facilitated the attack.

As for "how the attacker was able to redirect a browser to the non-SSL login page" that I suggest is relatively trivial as I regularly see websites that cause my browse to either downgrade an https session to http or upgrade http to https.

Obviously, we need more clarity about the details of this attack vector, because it isn't always possible to deploy a WPA2-enterprise solution.

0
0
This topic is closed for new posts.