Information Security News |
by Casey Johnston
A former Amtrak employee has been giving passenger information to the Drug Enforcement Administration in exchange for money for nearly two decades, according to reports from the Whittier Daily News. A total of over $854,460 changed hands over the last 20 years, despite the fact that information relevant to the DEA's work could have been obtained from Amtrak for free.
The employee, described as a "secretary to a train and engine crew" in a summary obtained by the AP, was selling the customer data with Amtrak's approval. Amtrak and other transportation companies collect information from their customers including credit card numbers, travel itineraries, emergency contact info, passport numbers, and dates of birth. When booking tickets online in recent years, Amtrak has also collected phone numbers and e-mail addresses.
The Whittier Daily News points out that Amtrak's corporate privacy policy allows the company to share this information with "certain trustworthy business partners," however, the secretary's actions didn't happen under this sanction.
Read 2 remaining paragraphs | Comments
by Robert Lemos
A one-two combination of malware programs has infiltrated the embassies and government systems of a number of former Eastern Bloc nations as well as European targets, according to a technical analysis by security researchers.
Using exploits and malicious downloads delivered through phishing attacks or on compromised websites, attackers first infect a system with a program, known as Wipbot, according to an analysis posted by security firm Symantec on Friday. The program conducts initial reconnaissance, collecting system information and only compromising systems that correspond with a specific Internet address. After the target is verified, a second program—alternatively known as Turla, Uroburos, and Snake—is downloaded to further compromise the system, steal data, and exfiltrate information camouflaged as browser requests.
The one-two combination has all the hallmarks of a nation-state intelligence gathering operation targeting the embassies of former Eastern Bloc countries in Europe, China, and Jordan, according to Symantec.
Read 8 remaining paragraphs | Comments
In last year or two, there has been a lot of talk regarding correct usage of SSL/TLS ciphers on web servers. Due to various incidents more or less known incidents, web sites today should use PFS (Perfect Forward Secrecy), a mechanism that is used when an SSL/TLS connection is established and symmetric keys exchanged. PFS ensures that, in case an attacker obtains the serverâs private key, he cannot decrypt previous SSL/TLS connections to that server. If PFS is not used (if RSA is used to exchange symmetric keys), then the attacker can easily decrypt *all* previous SSL/TLS connections. Thatâs bad.
However, the whole process of choosing a cipher is not all that trivial. By default, the client will present its preferred cipher to use and as long as the server supports that cipher it will be selected. This is, obviously, not optimal in environments where we want to be sure that the most secure cipher will always be selected, so administrators quite often enable their servers so they get to pick the preferred cipher.
This allows an administrator to enable only ciphers he wants to have used, and additionally to define their priorities â the server will always try to pick the cipher with the highest priority (which should be âthe most secure oneâ). Only if the client does not support that cipher, the server will move to the next one and so on, until it finds one that is supported by the client (or, if it doesnât, the SSL/TLS connection will fail!).
This is good and therefore I started recommending web server administrators to configure their servers so that PFS ciphers are turned on. However, at several occasions I noticed that the administrators incorrectly set the preferred cipher suite order on the server. This can result in non-PFS cipher suites selected, although both the server and the client support PFS.
As mentioned previously, this happens because the client sends the list of the supported ciphers and the server picks "the strongest one" according to its preferred list.Â
SSL Labs' (https://www.ssllabs.com/ssltest) shows this when testing with reference browsers, but I wanted to be able to check this myself, from command line, especially when I'm testing servers that are not reachable to SSL Labs (or I don't want them to see the results).
So I modified the Nmap's ssl-enum-ciphers.nse script to list preferred ciphers in addition to just enumerating ciphers. I use this script a lot to list the supported ciphers, but I was missing the preferred ciphers list. Letâs take a look at the following example:
$ nmap -sT -PN -p 443 127.0.0.1 --script ssl-enum-ciphers.nse
Starting Nmap 6.46 ( http://nmap.org ) at 2014-08-11 09:15 UTC
Nmap scan report for 127.0.0.1
Host is up (0.00021s latency).
PORT Â Â STATE SERVICE
443/tcp open  https
| ssl-enum-ciphers:
| Â SSLv3: No supported ciphers found
| Â TLSv1.0:
| Â Â ciphers:
| Â Â Â TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
| Â Â Â TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
| Â Â Â TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
| Â Â Â TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
| Â Â Â TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
| Â Â Â TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
| Â Â Â TLS_RSA_WITH_AES_128_CBC_SHA - strong
| Â Â Â TLS_RSA_WITH_AES_256_CBC_SHA - strong
| Â Â Â TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
| Â Â Â TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
| Â Â preferred ciphers order:
| Â Â Â TLS_RSA_WITH_AES_128_CBC_SHA
| Â Â Â TLS_DHE_RSA_WITH_AES_128_CBC_SHA
| Â Â Â TLS_DHE_RSA_WITH_AES_256_CBC_SHA
| Â Â Â TLS_RSA_WITH_AES_256_CBC_SHA
| Â Â Â TLS_RSA_WITH_3DES_EDE_CBC_SHA
| Â Â Â TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
| Â Â Â TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
| Â Â Â TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
| Â Â Â TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
| Â Â Â TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
| Â Â compressors:
| Â Â Â NULL
Now, things get interesting. You can see that the server supports the PFS ciphers (those starting with TLS_DHE are the PFS ciphers) in the original list (Â in green). However, take a look at the preferred cipher list (in red). Since the TLS_RSA_WITH_AES_128_CBC_SHA is the preferred cipher by the server, absolutely every browser today (Mozilla, Chrome, IE, Safari) will end up using this cipher â since they all support it. So, even though PFS ciphers are enabled, they will never get used!
Of course, this is an error in the web serverâs configuration. Letâs fix it so the PFS ciphers have higher priority and rerun the nmap script:
$ nmap -sT -PN -p 443 127.0.0.1 --script ssl-enum-ciphers.nse
Starting Nmap 6.46 ( http://nmap.org ) at 2014-08-11 09:15 UTC
Nmap scan report for 127.0.0.1
Host is up (0.00021s latency).
PORT Â Â STATE SERVICE
443/tcp open  https
| ssl-enum-ciphers:
| Â SSLv3: No supported ciphers found
| Â TLSv1.0:
| Â Â ciphers:
| Â Â Â TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
| Â Â Â TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
| Â Â Â TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
| Â Â Â TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
| Â Â Â TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
| Â Â Â TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
| Â Â Â TLS_RSA_WITH_AES_128_CBC_SHA - strong
| Â Â Â TLS_RSA_WITH_AES_256_CBC_SHA - strong
| Â Â Â TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
| Â Â Â TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
| Â Â preferred ciphers order:
| Â Â Â TLS_DHE_RSA_WITH_AES_128_CBC_SHA
| Â Â Â TLS_DHE_RSA_WITH_AES_256_CBC_SHA
| Â Â Â TLS_RSA_WITH_AES_128_CBC_SHA
| Â Â Â TLS_RSA_WITH_AES_256_CBC_SHA
| Â Â Â TLS_RSA_WITH_3DES_EDE_CBC_SHA
| Â Â Â TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
| Â Â Â TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
| Â Â Â TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
| Â Â Â TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
| Â Â Â TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
| Â Â compressors:
| Â Â Â NULL
Much better! Now the PFS ciphers are preferred and most browser will use them. We can even confirm this with SSL Labs â all relatively new browsers, that support PFS will pick those ciphers.
So, if you want to use this script to test your servers, you can find it at https://github.com/bojanisc/nmap-scripts - please report any bugs to me.
Finally, I also submitted it to Nmap so hopefully it will get added into the official distribution. There is a bug that Daniel Miller noticed â in case a server supports more than 64 ciphers, and the server is running on Microsoft Windows, the script will fail to list the preferred ciphers.
The reason for this is that, when a client connects, Microsoft (the Schannel component I presume) takes into account only the first 64 ciphers listed by the client. The other ciphers are ignored. This is the reason why the original ssl-enum-ciphers.nse Nmap script splits ciphers into chunks of 64. No idea why Microsoft did it this was (since the spec says that the client can include as many as it wants). However, itâs clearly a problem.
Now, I havenât seen any web servers that support more than 64 ciphers in the wild â let me know if you find one. Additionally, according to this article: http://msdn.microsoft.com/en-us/library/windows/desktop/bb870930%28v=vs.85%29.aspx, the list of cipher suites on Windows is limited to 1023 characters.
Since most cipher names are 20+ characters, this could mean that you can't really have more than ~50 ciphers active on a Windows machine - I haven't tested this though.
Â
--
Bojan
[email protected]
INFIGO IS
