News Categories
(34)Malware (39)Malicious emails (11)Web 2.0 (24)Facebook (22)Social Networks (44)Spam (2)Defensio (1)Comment Spam (15)Phishing (9)Web spam (4)Click-jacking (38)Compromise (20)Analysis (38)Exploits (14)Research (3)Presentations (3)Conferences (4)security conference (9)Mass Injection (10)Rogue AV (4)Blackhat SEO (2)Neosploit (23)Targeted attacks (7)Video (14)Zeus (5)Microsoft (4)Monthly Reports (1)twitter (3)Google (18)Vulnerabilities (9)Adobe (12)Java (4)Mobile (4)Apple (1)hacked (1)TAB (1)Black Hat USA 2011 (1)Google+ (20)0-day (1)CVE-2010-2884 (1)CVE-2011-1255 (1)Worm (14)Blackhole exploit kit (1)Incognit Exploit kit (2)Tuesday Patch (6)APT (6)Typosquatting (3)Vulnerability Analysis (1)CVE-2011-3402 (4)Web Research (4)Predictions (3)Adult (5)News (3)Black Hat SEO (6)Data loss (8)Scam (1)QR codes (6)Twitter (1)CVE-2012-0003 (1)CVE-2011-3389 (1)CVE-2012-0004 (1)Phoenix Exploit Kit (1)CrimePack (3)Reverse Engineering (2)Captcha (1)Valentine's day (2)Kelihos (1)SC Magazine Award Winner (1)Wordpress (1)MS12-010 (1)CVE-2012-0002 (1)Infosec (2)CVE-2012-0507 (8)Toolkits (1)Skywiper (2)Flame (1)Flamer (2)Passwords (1)freedom of expression (1)censorship (2)Plugins (3)Malvertising (14)Exploit (1)CVE-2012-1723 (1)CSI (2)ThreatSeeker (2)Adventures in Spam (1)CVE-2012-4681 (1)LBS (2)RAT (1)module Apache/2 (1)Cyber Monday (1)Black Friday (1)Pastebin (4)CVE-2012-4792 (1)iPad (1)super bowl (1)iPhone (2)iOS (4)Spear Phishing (1)Threat Report (3)ThreatScope (1)Dynamic DNS (1)China (1)SSL (1)APT1 (2)DLP (3)Hack (1)CVE-2012-4969 (2)threat lifecycle (1)ThreatSeeker Network (1)ACE (10)exploit kit (1)blackhole (2)Black Hole (1)DNS poisoning (1)RedKit Exploit Kit (4)exploit kits (1)threat stages (1)Certificates (1)Topical (1)Waterhole (1)CVE-2013-2463 (1)Neutrino exploit kit (1)CVE-2013-2473 (1)CVE-2013-3893 (2)Collective Threat Intelligence (1)CVE-2013-3963 (1)Targeted Attack (3)Advanced Malware (1)CVE-2013-3897 (1)Tor (5)cyber-crime (1)Mevade (2)Ransomware (3)Social Engineering (1)CookieBomb (2)LinkedIn (1)CVE-2013-3906 (2)Pony (3)Cryptolocker (2)Upatre (1)application telemetry (1)meta-data (3)dr. watson (1)windows error reporting (1)big data (2)data theft prevention (1)DTP (1)telemetry (2)CVE-2014-0322 (2)MSIE 0-day (1)Deputy Dog (1)Ephemeral Hydra (1)CVE-2013-0074 (1)CVE-2013-3896 (1)Silverlight (2)crash reports (1)POS (1)anomaly detection (1)goon (4)angler (1)ru:8080 (1)magnitude (3)flash (1)CVE-2013-2465 (1)malicious iframes (1)FIESTA (1)Exploits Kit (1)iframe (3)CVE-2014-0160 (2)OpenSSL (3)Heartbleed (3)Citadel (2)CVE-2014-1776 (1)VGX.DLL (1)necrus (1)cutwail (2)gameover (3)vulnerability (3)zbot (1)control panel (1)carberp (1)zberp (1)Caphaw (2)Nuclear exploit kit (1)Shylock (1)Dragonfly (1)Zeus PIF (1)bitly (1)fraud (2)RIG Exploit Kit (1)POS malware (1)Point Of Sale Malware (1)Ukraine (1)Russia (1)Shellshock (1)CVE-2014-6271 (1)poodle (1)cve-2014-3566 (1)sslv3 (1)Ebola (1)CVE-2014-4114 (1)CPA (1)Regin (1)CVE-2015-0311 (1)CVE-2015-0235 (1)linux (1)GHOST (1)CVE-2015-0072 (1)Internet Explorer (1)XSS (1)IE (1)TorrentLocker (1)Product Information (1)Money Laundering (1)APSA10-05 (1)Skype spam
RSS Feed
Broken Hearted? A Practical Look at the Heartbleed Vulnerability
Posted by Jason Hill on 11 April 2014 07:45 PM

Following on from our previous Heartbleed post, there have been countless reports on the far-reaching scale of this critical security flaw along with numerous discussions as to what 'exactly' an attacker can gain from exploiting the vulnerability.


Given the online and 'connected' nature of modern society, security and trust are the fundamental requirements of any online transaction in which personal or confidential data is transmitted. All of us, both technical and non-technical, have come to rely on the 'padlock in the address bar' - an indication that the website is handling our data securely, be that credentials, emails, financial records or status updates, with protection handled by the SSL or TLS protocols. It comes as no surprise that when the very thing that should be protecting us is compromised, in this case a feature within OpenSSL, that the implications can be far and wide.


Contributors: Abel Toro, Jason Hill, Alex Watson

 What does this all mean?

As with any organized attack and as described by our 7 Stages of Advanced Threats, target reconnaissance precedes all other stages and, in this case will commence with determining  which sites are (still) vulnerable to this OpenSSL vulnerability. As expected, given the widespread media exposure and severity of this flaw, numerous 'proof-of-concept' (PoC) scripts have been developed and are widely available thus allowing anyone with a command-line and an internet connection to start probing web-servers. Once a vulnerable site has been located, a threat actor can attempt to exploit the vulnerability, in this case by sending a specially crafted heartbeat packet which, rather than the original intended use, requests a larger than expected response which subsequently reveals up-to an additional 64k of memory. Once received, the threat actor can then attempt to sift through the returned data looking for 'interesting' items that can be further leveraged, for example, credentials or session IDs which would allow them to gain unauthorized access to the site in question or even, as widely suggested, private cryptography keys which could be used to compromise or impersonate the identity of a trusted site or person.



In practice - Obtaining Alice's credentials?

Targeting a specific user may prove impractical for a threat actor, especially on larger 'well-used' sites. For example, if our threat actor wanted to steal Alice’s login credentials for a specific site they wouldn't be able to specifically target 'Alice' and would have to keep running the exploit over a protracted period in the hope of harvest credentials which may or may not contain 'Alice's'. On the other hand, if the target site was smaller, less frequented or if it was known when Alice was likely to authenticate, the threat actor may have a higher chance of success although they would still need to be in the right place at the right time.


Given this, if you're thinking of changing your credentials it may be pertinent to ensure that the site is not vulnerable to the exploit.



Grabbing user names and passwords are relatively easy, private keys are more difficult.

Our research has shown that getting usernames, passwords and session IDs is quite feasible for an attacker in a real life scenario.  The credentials can be stolen very quickly, without a trace and without much technical expertise.


However, while it is theoretically possible to retrieve the server’s private key using the Heartbleed vulnerability, in the real-world this is much more difficult than the aforementioned compromise of user names and passwords. At the time of writing, we have only seen one known successful PoC which can fully or partially extract the private key which required somewhat perfect conditions (for the threat actor):


  1. The exploit must account for the specific OS being targeted, in the case of the most widely available PoC: FreeBSD
  2. The threat actor must be the first one to communicate with the server after it is restarted in order for the private key to be in memory
    (If the server has been running for a while the attack is not feasible and therefore a threat actor make seek to 'cause' the server to restart)
  3. In a many cases the private key can only be partially extracted, given this, it may be necessary for the attack to be replayed numerous times in order to attempt to obtain all of the parts
  4. It is suggested that some fairly standard server configurations will make it much more difficult to get the private key - further reducing the chances of success


As detailed in our previous post, Websense strongly recommends mitigation actions such as regenerating private keys and revoking/reissuing certificates.




In order to demonstrate this vulnerability in a real-life scenario, Websense Security Labs conducted a brief practical analysis of the vulnerability by exploiting a test web-server in our lab environment.


Having scanned our test server and determined that it was vulnerable, it was trivial to start reviewing the returned memory results and arguably took under a minute to harvest credentials and gain access to that user’s account. However, as previously stated we needed to be in the right place at the right time and therefore required our victim to authenticate/interact with the website in order for their credentials to actually be 'in memory'.


Furthermore, confirming our earlier statement, so long as the server remained un-patched, it was possible to monitor password changes. This clearly highlights the need to exercise caution when interacting with vulnerable hosts such as in this example:


User changes an existing password to ‘secret1234’:




Which is subsequently exposed when exploited:



Through the use of session cookies, it is also practical for a threat actor to steal credentials even if the user is never prompted to login. Browsing to a site from an already established session is often common practice for web-based email and social network users:


Given this, is would be wise to avoid even browsing to vulnerable sites and system administrators should invalidate all session cookies. While a WordPress site on a vulnerable platform was used for testing purposes, other vulnerable sites are likely to exhibit similar results, albeit unlikely to be in such as clean and predictable manner. In this scenario we simulated a victim browsing to their favorite site and, as they know about the Heartbleed bug, they go onto change their password. Additionally, the use of sessions can expose your credentials so you're not safe just because a login page wasn't displayed.


Almost universally, the security mechanisms that we depend upon are based around trust in both cryptography and its implementation. This vulnerability has demonstrated the risk that can be associated with such ubiquitous adoption of a single implementation of a cryptography library (in this case, OpenSSL) and demonstrates the value for organizations to utilize a layered defense-in-depth strategy whenever possible.

Read more »


Websense® Security Labs™ has been tracking news of a vulnerability in the implementation of OpenSSL which has far-reaching implications for it's users and those impacted by it's use.


The vulnerability, CVE-2014-0160, allows a remote attacker to read the memory of systems protected by vulnerable versions of OpenSSL.  Data that may be stolen includes certificates, private keys, Personally Identifiable Information (PII) and any other sensitive data.


For those not familiar with OpenSSL it is an Open Source toolkit implementing the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols as well as a full-strength general purpose cryptography library.  It is deployed in many scenarios such as within email servers and VPN systems, and can be embedded within operating systems.  Any such system using the vulnerable version of OpenSSL is thus vulnerable to exploitation.


The vulnerability exists in OpenSSL v1.0.1 through v1.0.1f (also v1.0.2-beta1).  Please refer to for detailed information.


Please note: an updated (fixed) version of OpenSSL is now available in v1.0.1g


Confirmation of this can be found on (in anticipation of the openssl website being under heavy load, we have provided a screenshot of their advice below):


We strongly recommend that you establish whether vulnerable instances of OpenSSL are used in your environment, and if so, you should upgrade OpenSSL, or the software that uses OpenSSL, immediately.


Codenomicon, recognised as one of the discovering parties, have provided detail on this vulnerability as well as other mitigation actions that you should consider, which include:

  • Recompile your existing OpenSSL version with -DOPENSSL_NO_HEARTBEATS option (to disable the vulnerable component).
  • Revoke and reissue all certificates from the past 2 years (since the bug has been in existence).
  • Generate new private keys.
  • Invalidate all session keys and cookies.
  • Any end users who suspect that they may have interacted with a web server that is, or was, vulnerable to this flaw should consider resetting their passwords.


It is understood that web server logs will not show whether the vulnerability has been used, thus making an attack difficult to detect from that perspective.


Our ThreatSeeker® Intelligence Cloud has identified that numerous Proof Of Concept tools have been launched online that can be used to show whether a particular website is vulnerable to CVE-2014-0160.  We have seen reports to suggest that upwards of 600 of the Top 10,000 websites (as ranked by Alexa) are still vulnerable.


Websense Security Labs will continue to monitor the impact of this vulnerability.

Read more »