November 5, 2013
Yesterday I wrote about the the information leak at the Railjet Wifi. Today I’m traveling back to Tirol again with a Railjet and I found something other disturbing. I believe its even more problematic as it concerns the mail system. I used a openssl client to check various SSL and TLS connections to my servers, and when I called following:
$ openssl s_client -connect smtp.xxx.at:25 -starttls smtp
I got something I didn’t expect:
didn't found starttls in server response, try anyway...
Hey, my server does not support STARTTLS? I’m sure it does. I did a SSH to a server of mine and checked typed the same command and got my server certificate complete with chain. So something is not right here. I switched to Wireshark (which is running all the time … Ok, I launched it 😉 ) and looked at the traffic:
server: 220 profinet.at SurgeSMTP (Version 6.3c2-2) http://surgemail.com
client: EHLO openssl.client.net
server: 250-profinet.at. Hello openssl.client.net (18.104.22.168)
server: 250-AUTH LOGIN PLAIN
server: 250-X-ID 5043455352563431333833323030373135
server: 250-SIZE 50000000
server: 250 HELP
server: 500 Sorry SSL/TLS not allowed from (22.214.171.124)
Hey? Thats not my mail server. Its not my IP address and its sure not the mail server software I use. WTF?
Someone is intercepting my SMTP traffic and if my mail clients would use the default setting (use TLS if possible) I would now send my login data (which is for most people the same as for fetching mails) in the clear over an unprotected WiFi. Block port 25 if you have fear of spammers, but don’t force unencrypted traffic over a open wifi.
Anyway whats that profinet.at stuff …. can’t be profi as in professionals. The Whois tells following:
Organisationsname: OeBB Telekom Service GmbH
Strasse: Bruenner Strasse 20
Ok, thats the OeBB by itself. Real experts. 😉
So keep an eye on your SMTP/IMAP configuration and make sure you’re forcing TLS/SSL otherwise someone in the same train is seeing your data.
November 4, 2013
Today I traveled with the OEBB Railjet which provides a free WiFi. As the journey took some hours I had time to look at my networks traces and found something. After the captive portal with the Terms of Services was acknowledged, a page with some infos is shown. One of the infos is the original URL the user requested. If the users clicks on the link a separate tab opens with the page. The problem is that the URL the browser was given to access this info page has following format:
Which is sent as referrer to the original requested page if you click onto the link. As you see this referrer contains the full MAC address of the requesting device. Normally the MAC address is only visible via Layer 2 but with the information leak in my case www.orf.at knows my MAC address and if I have already gotten a cookie, they could add now my MAC to the list of know IDs. Ok, I guess the ORF doesn’t do that, but others might.
A solution would be simple for the OEBB, but until then don’t click on this link – type the URL again.
November 3, 2013
I just had the problem that I was not able to resume a suspended KVM guest. It happened when I powered my KVM server down to add a new hard disk. My server did not power the guest down but did instead suspended them. I realized that only after I did have no “Run” .. just a “Restore” to choose from.
When I tried to “Restore” it I go following:
The problem was that I removed a mapped USB device some time ago but at resuming KVM checked for it. The solution was to remove the corrupted suspended virtual machine session so I could boot the machine again – naturally I did lose the suspended session, but that was ok.
[root@kvmserver ~]# virsh managedsave-remove <NameOfGuest>
Removed managedsave image for domain servicesint
Maybe there is a graphical way to do it, but I didn’t look further – as it worked.