The Logjam attack allows a man-in-the-middle attacker to downgrade vulnerable TLS connections to 512-bit export-grade cryptography. This allows the attacker to read and modify any data passed over the connection. The attack is reminiscent of the FREAK attack, but is due to a flaw in the TLS protocol rather than an implementation vulnerability, and attacks a Diffie-Hellman key exchange rather than an RSA key exchange. The attack affects any server that supports DHE_EXPORT ciphers, and affects all modern web browsers. 8.4% of the Top 1 Million domains were initially vulnerable.
Yet another vulnerability allowing an attacker to downgrade the TLS connection to use weaker ciphers. The solution in this case is easy:
- Generate strong DH group: openssl dhparam -out /etc/nginx/certs/dhparams.pem 2048
- Configure web server (e.g. with nginx): Add ssl_dhparam /etc/nginx/certs/dhparams.pem; to nginx.conf
Good explanation and proof of concept on how some devices connected to your WiFi might help an attacker in extracting your WiFi password.
In short, this is how this Man-on-the-Side attack is carried out:
- An innocent user is browsing the internet from outside China.
Interesting approach, DDoS by using their capability to MitM any connection and adding a JS causing any user going to Baidu to hit GitHub. The mitigation by GitHub was clever, returning an alert tag when connecting to the target URLs, effectively blocking the user's browser.
On Friday, March 20th, we became aware of unauthorized digital certificates for several Google domains. The certificates were issued by an intermediate certificate authority apparently held by a company called MCS Holdings. This intermediate certificate was issued by CNNIC.
CNNIC is included in all major root stores and so the misissued certificates would be trusted by almost all browsers and operating systems. Chrome on Windows, OS X, and Linux, ChromeOS, and Firefox 33 and greater would have rejected these certificates because of public-key pinning, although misissued certificates for other sites likely exist.
Reminder to go through all trusted Root CAs in Keychain Access / Certificate Manager tools and delete/untrust all "shady" roots (CNNIC, Turktrust, etc.)
[...] able to successfully hide all four executables from detection in 9 of the 12 products (in some cases, evasion was unnecessary for one or two of the files as the original, unencoded files were not even detected. The only products that provided at least partial protection were Avast, Bitdefender, and BullGuard.
A quick glance at the table, will demonstrate that despite a few of the products detecting some of the executables, the best method of evading AV detection is by cloaking a backdoored executable (as I did with strings.exe). In fact, as you’ll see below, one of the products actually automatically whitelisted my backdoored executable without any action on my part!
Evaded AV detection in 9 of 12 products of a meterpreter reverse tcp executable by just encoding instructions (only using add, sub, xor) and making use of nops and sequential inc/decs.
Works even with the “Erase data after 10 attempts” configuration setting enabled. Our initial analysis indicates that the IP Box is able to bypass this restriction by connecting directly to the iPhone’s power source and aggressively cutting the power after each failed PIN attempt, but before the attempt has been synchronized to flash memory. As such, each PIN entry takes approximately 40 seconds, meaning that it would take up to ~111 hours to bruteforce a 4 digit PIN.
Interesting approach in that by cutting power it prevents iOS from storing the attempt information. Long story short, always use a passphrase, not a PIN.