Linkedin - security issue - Unvalidated Redirects and Forwards

This is a Linkedin shortened URL that seems to be pointing to Linkedin (when you try to reverse it) but in reality, it redirects to this blog post! https://lnkd.in/eSQcwhD

Below we are going to prove that this unvalidated redirect method (OWASP A10) can be used to deceive users and redirect them to malicious websites and malicious executable files by letting them think they are being redirected to Linkedin.

>> Responsible Disclosure: Before I start describing the issue I would like to mention that I followed LinkedIn's policy on reporting vulnerabilities process to the letter (responsible disclosure) and reported the issue exactly as it is described in this page:

https://help.linkedin.com/app/safety/answers/detail/a_id/37022/chapter/reporting_policy 

After sending a detailed description of the issue (on 27/May/2015), I received the following reply from Linkedin.

Thank you for contacting us and sending us your writeup.

We do perform validation for third-party links that users submit to LinkedIn, checking the destination for inclusion on malware and safe browsing blacklists. The hash you observed is used for that purpose. 

Regarding unwinding of our short links or obfuscation, URL encoding is working as expected and the depth of third-party inspectors is not something under our control. Note that some of our redirects use JavaScript, so they may not be capable of analyzing the content. Those redirects also clearly show an interstitial that a redirect is occurring.
If you believe we have misinterpreted your report, please let us know.
Thanks!

[name of responder not being disclosed]
LinkedIn House Security

From my point of view, Linkedin did not understand the extend of the issue I described. So, I replied to that person giving him a couple of examples why I believe this unvalidated redirect "feature" doesn't seem to be working as "expected". Simply because, it can redirect/trick/deceive users into downloading malware and/or visit a malicious website, while under the impression they are being redirected to Linkedin instead. So, my reply to Linkedin response was the following:

Logjam attack - Diffie-Hellman key exchange weakness (a quick and brief explanation)

A study was published regarding the security of the Diffie-Hellman key exchange. This popular cryptographic algorithm can be found among many protocols such as HTTPS, SSH, IPsec, SMTPS and it is used for sharing a key and establishing a secure connection. 

The weaknesses uncovered affect websites, mail servers, and other TLS-dependent services that support DHE_EXPORT ciphers. The exploitation of this vulnerability  was given the name Logjam attack [1] and depends on how Diffie-Hellman key exchange has been deployed in each case. 

The Logjam attack against TLS can be performed by downgrading vulnerable TLS connections to 512-bit export-grade cryptography, allowing the man-in-the-middle (MiTM) attacker to read and modify any data passed over the connection. At the moment, this attack affects all modern web browsers. 

ozwpan driver - Remote packet-of-death vulnerabilities in Linux Kernel

"The ozwpan driver accepts network packets, parses them, and converts them into various USB functionality. There are numerous security vulnerabilities in the handling of these packets. Two of them result in a memcpy(kernel_buffer, network_packet, -length), one of them is a divide-by-zero, and one of them is a loop that decrements -1 until it's zero." [1]

1. A remote packet can be sent, resulting in funny subtractions of
signed integers, which causes a memcpy(kernel_heap, network_user_buffer, -network_user_provided_length).

There are two different conditions that can lead to this:
https://lkml.org/lkml/2015/5/13/740
https://lkml.org/lkml/2015/5/13/744

2. A remote packet can be sent, resulting in divide-by-zero in softirq, causing hard crash:
https://lkml.org/lkml/2015/5/13/741

3. A remote packet can be sent, resulting in a funny subtraction, causing an insanely big loop to lock up the kernel: https://lkml.org/lkml/2015/5/13/742

4. Multiple out-of-bounds reads, resulting in possible information leakage, explained in the last paragraph of the introductory email here: https://lkml.org/lkml/2015/5/13/739

The above is a repost of this: http://seclists.org/oss-sec/2015/q2/446

You may find more information about ozwpan here: https://lkml.org/lkml/2015/5/13/739

[1] https://lkml.org/lkml/2015/5/13/739

VENOM Vulnerability - Virtualized Environment Neglected Operations Manipulation

VENOM is short for Virtualized Environment Neglected Operations Manipulation and it is a vulnerability in the QEMU’s virtual Floppy Disk Controller (FDC). The vulnerable code is used in numerous virtualization platforms and appliances such as Xen, KVM, and the native QEMU client. 

The vulnerability has been assigned the following CVE (CVE-2015-3456). As far as we know, VMware, Microsoft Hyper-V, and the Bochs hypervisors are not impacted by this. 

The interesting fact about VENOM is that it applies to a wide range of virtualization platforms (using the default configurations) and it allows for arbitrary code execution. Due to the fact that the vulnerability exists in the hypervisor’s codebase, it affects all host and guest Operating Systems. 

However, the vulnerability can be exploited only with escalated privileges (root, administrator). 

To Flash, or not to Flash?

Adobe suffers its third critical vulnerability (CVE-2015-0313) for this year. The vulnerabilities are exploited by the use malicious advertisements known as malvertising attacks. Due to the fact advertisements are designed to load once a user visits a site, the infection happens automatically. 

The affected version of this third vulnerability were:

• Adobe Flash Player 16.0.0.296 and earlier versions for Windows and Mac OS X
• Adobe Flash Player 13.0.0.264 and earlier 13 x versions

There are two Flash player updates already released by Adobe to mitigate the two previous vulnerabilities (CVE-2015-0310, CVE-2015-0311) and new updates are expected during this week for the latest vulnerability. 

In the meanwhile, make sure your flash does not load automatically by enabling the click-to-play feature of your web browser, make sure your AntiVirus solution is up-to-date, make sure you have the latest Flash player installed downloaded only by the legitimate Adobe website and last but not least, use an ad-blocker. 

POODLE SSLv3 Vulnerability

Bodo Möller, Thai Duong and Krzysztof Kotowicz from Google who discovered this, released a security advisory which you can find on OpenSSL website [2]. 
The Padding Oracle On Downgraded Legacy Encryption aka #POODLE vulnerability, has already a good write-up [1]. Jesper Jurcenoks explains the vulnerability on his blog [3] in a very detailed manner but at the same time, easy to understand. I am happy to see that Jesper used for his blog-post the logo I made for the poople vulnerability! :) Also, if you are thirsty for more technical details, you should also read this blog-post from ImperialViolet [4]. If you want to see some statistics on how vulnerable we are today in regards to this, you should read this article on netcraft [5]. The following post outlines the steps on how to disable SSLv3 [6]. If you wanna do a quick test and see if your browser supports SSLv3 regarding the poodle vulnerability, then you can visit: www.poodletest.com. On the other hand, www.howsmyssl.com can provide some useful information about the SSL/TLS client you used to render its page. Last but not least, if you need to a server given its domain name for this vulnerability, you may use www.poodlescan.com

CVE­-2014-­3566 has been allocated for this protocol vulnerability.

I had an idea for a logo for this vulnerability which I posted on twitter when the vulnerability came out and I would like to share it with you. We are trying to ditch SSLv3 for quite some time now, the logo had to look a little bit old style, retro and maybe vintage. Let me know what you think. ( you are free to use this logo, it would be nice if you reference it with: @drgfragkos )

Do you want to test manually?
Use this command: 
openssl s_client -connect google.com:443 -ssl3
If the handshake fails then the server doesn't support SSLv3 

Bash-ing (Bash Bug, Shell Shock) - All the information you need

The Bash Bug is a severe vulnerability discovered by by Stephane Chazelas of Akamai, who most probably deserves a pwnie award [1]. 
The discovery of this particular vulnerability is a serious risk, similar (maybe proven to be a lot bigger) to the Heartbleed bug [2]. Mostly because Linux not only runs the majority of the servers but also in a large number of embedded devices. Keep in mind that there are approximately about 25 years’ worth of Bash versions! Effectively, Mac OS X [11] and Android devices may also be running the vulnerable version of bash. 
Also, for Windows systems, msysgit contains a vulnerable version of bash (by Joshua McKinney) [12]. Which means, we are going to have more of these popping up very soon under the Windows platform as well.
Just to give you a hint about the severity of this vulnerability, NIST Vulnerability DataBase rated this with "10 out of 10". [3]

Black Hat: Hackers execute code on mobile POS devices, play their version of Flappy Bird

Researchers who discovered vulnerabilities in mobile point-of-sale devices (mPOS), which could allow malicious code execution on targeted payment systems, demonstrated their findings at Black Hat 2014 in Las Vegas. 

[1] http://www.scmagazine.com/black-hat-hackers-execute-code-on-mobile-pos-devices-play-their-version-of-flappy-bird/article/365390/

Gamma International; a Hacker's Hacking Guide

The original document was found at pastebin [1]. 

[1] http://pastebin.com/raw.php?i=cRYvK4jb

                _   _            _      ____             _    _ 
               | | | | __ _  ___| | __ | __ )  __ _  ___| | _| |
               | |_| |/ _` |/ __| |/ / |  _ \ / _` |/ __| |/ / |
               |  _  | (_| | (__|   <  | |_) | (_| | (__|   <|_|
               |_| |_|\__,_|\___|_|\_\ |____/ \__,_|\___|_|\_(_)
                                                 
     A DIY Guide for those without the patience to wait for whistleblowers

London Trust Forum

I was invited to attend the London Trust Forum organised by NCC where Andy Davis talked about CANimation and highlighting the security threats to automotive systems. A very interesting talk on how you can hack into cars when you have physical access to them or in some occasions, remotely! 

It was really nice to see familiar faces at the event and catch up with Dr. Jessica Barker (@drjessicabarker), David Middlehurst (@dtmsecurity) , @netbiosX and @Emil_i.

Looking forward to the next Trust Forum event already!

Critical OpenSSL vulnerability

OpenSSL released a security advisory yesterday (7/Apr/2014) regarding the TLS heartbeat read overrun (CVE-2014-0160). [1] This is a CRITICAL vulnerability affecting 1.0.1 and 1.0.2-beta releases of OpenSSL, including 1.0.1f and 1.0.2-beta1.

An attacker can read memory contents of the remote server . The server will not crash or otherwise exhibit suspicious behaviour. Successful exploitation leaks usernames, passwords, web application session cookies or other sensitive information. 

Currently, some of the vulnerable websites are: 
yahoo.com
okcupid.com
flickr.com

The quickest way to test your server is by using the following link:
http://filippo.io/Heartbleed/

Remediation:
Affected users should upgrade to OpenSSL 1.0.1g. The alternaltive at this point if you cannot upgrade to OpenSSL 1.0.0g is to recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS

For remediating against an Apache install you will also need to upgrade libssl (libssl1.0.0).

Note that Ubuntu 1.0.1-4ubuntu5.12 of OpenSSL resolves the issue.

Temporary Snort signatures:
a) alert tcp $EXTERNAL_NET any -> $HOME_NET 443 (msg:"Heartbleed attack with ssltest.py";flow:to_server,established; content:"|18 03 02 00 03 01 40 00|"; rawbytes; isdataat:!1,relative; reference:cve,2014-0160; sid: 6000000; rev:1;)

b) alert tcp $EXTERNAL_NET any -> $HOME_NET 443 (msg:"Heartbleed attack";flow:to_server,established; content:"|18 03|"; rawbytes; depth:2; byte_test:1, &, 3, 0, relative; byte_test:2, >, 200, 3, relative, big; reference:cve,2014-0160; sid: 6000001; rev:2;)


[1] http://www.openssl.org/news/secadv_20140407.txt