VMware Security Advisories / Patches released for 2 issues (NOT Heartbleed) - http://www.vmware.com/security/advisories/VMSA-2014-0003.html and http://www.vmware.com/security/advisories/VMSA-2014-0002.html , (Fri, Apr 11th)
We're getting reports of client applications that are vulnerable to the heartbleed issue. Just as with server applications, these client applications are dependant on vulnerable versions of OpenSSL.
Another "patch soon" problem, you say? The patch will be installed when the vendor ... oh, wait a minute. Just exactly when will your TV's manufacturer update the web browser on your TV? And when will you be applying that patch? How about your in-laws TV? This vulnerability on the client side has the potential to be much longer-lived than on servers.
This combines the problem of the specific heartbleed vulnerabilty with the problem of embedded devices that may never be updated. Or devices that are updated by vendors for a year or two after release, then abandoned when the new model comes out - home routers and TV sets are great examples of this situation, but so are medical devices.
To add to that list, there is a large contingent of Android phones that have updates maintained by the carrier instead of the manufacturer (google), and do not see frequent updates, or may never see an update. These devices are used daily for almost everything - online banking comes immediately to mind. The combination of a general purpose device and a vulnerability that exposes memory to an attacker (in this case, a malicious or infected server) has the potential for some widespread mayhem, for as long as that device remains in service (years instead of weeks or months)
Other applications that encrypt but we don't often think of as "clients" include traditional database software, cloud services clients, dedicated / custom browsers for online services like entertainment, even device drivers for hardware all need to be assessed. It's also easy to say "client application XX is vulnerable", but that client application might exist on your PC, multiple tablet or phone platforms, TVs, DVRs, excercise equipment, fridges, thermostats - the list grows to include things that are smaller and smaller, that are less and less likely to be updated.
Client applications that are currently reported as vulnerable are:
- MariaDB 5.5.36
- wget 1.15 (leaks memory of earlier connections and own state)
- curl 7.36.0
- git 1.9.1 (tested clone / push, leaks not much)
- nginx 1.4.7 (in proxy mode, leaks memory of previous requests)
- links 2.8 (leaks contents of previous visits!)
(from http://security.stackexchange.com/questions/55119/does-the-heartbleed-vulnerability-affect-clients-as-severely )
If you've got confirmation of other vulnerable client applications, please post the relevant information (with links) in our comment section.
With more mass-media attention to the heartbleed bug, we are getting more questions from "normal users" about the heartbleed bug.
The "Heartbleed" bug is not affecting end users using Windows. It does not affect standard Windows browsers (Internet Explorer, Firefox, Chrome). It may affect some selected third party software, but most likely, you do not need to patch anything. The only widely used consumer platform vulnerable is Android 4.1.1, but there isn't much you can do about it but wait for a patch for your phone.
However, it is possible that a web site you used is or was affected by "Heartbleed". The result may be that the password you are using on the site was captured by someone attacking this site. So you may need to change the password that you used on the site.How do I know if a site is/was vulnerable?
Your best bet is https://lastpass.com/heartbleed/ . They will show you if a site is vulnerable right now, or may have been vulnerable in the past. Tehre is a chance that the site received a new certificate that still uses the old issue date, which can lead to sites being identified as "not fixed".Should I change my password?
If you think the site was vulnerable, and is no longer vulnerable, then you should change your password. If in doubt, change your password. Changing your password while the site is still vulnerable probably doesn't hurt, but the new password may leak again, so the change may not help.Should I avoid sites that are still vulnerable?
YesI received an e-mail from a site I use asking me to change my password. Should I do so?
First of all: Don't click on any links in this email. Then go to the website and change your password (even if the e-mail was a fake, it doesn't hurt to change your password as long as you are sure you go to the right site). Use the "lastpass" URL above to check if the site is/was vulnerable.What else should I do?
Standard "safe computing" practices: use difficult to guess passwords, keep your system up to date, use anti-malware, be cautious with links distributed via e-mail.And how do I explain the problem that caused all this?
XKCD has a great cartoon explaining it: http://imgs.xkcd.com/comics/heartbleed_explanation.png . The short summary: If an SSL connection is idle, heartbeat messages are used to chck if the other side is still listening. For example, the browser sends a message "if you are still alive, reply by sending the 3 letter word 'dog'", and the server replies with "dog". To trigger the bug, the client would send "reply with the 500 letter word 'cow'". Since "cow" only got 3 letters, the server will make up the missing 497 bytes with data from memory, and this data may contain other things the server was working on, like users passwords or private encryption keys.
ISC StormCast for Thursday, April 10th 2014 http://isc.sans.edu/podcastdetail.html?id=3929, (Thu, Apr 10th)
There are a fair few sites popping up testing for this issue. I know this is possibly overly motherly, sorry, but be careful. You may not know who is running the site, what they are actually testing for and what is done with the information collected. Consider sticking to the main sites and known security organisations.
Metasploit now has a module out (https://github.com/rapid7/metasploit-framework/blob/master/modules/auxiliary/scanner/ssl/openssl_heartbleed.rb). NMAP likewise has a check. QUALYS has their SSLLABS page. Other security vendors are also providing checks in their scanning products.
Not saying the free scanners are "evil", just saying be careful what you use.
Mark H(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
- CACert - https://blog.cacert.org/2014/04/openssl-heartbleed-bug/
- Cisco - http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20140409-heartbleed
- Fortinet - http://www.fortiguard.com/advisory/FG-IR-14-011/
- Gentoo Linux - http://www.gentoo.org/security/en/glsa/glsa-201404-07.xml
- Juniper - http://kb.juniper.net/InfoCenter/index?page=content&id=KB29004 (login required)
- Juniper - http://kb.juniper.net/InfoCenter/index?page=content&id=JSA10623
- F5 - http://support.f5.com/kb/en-us/solutions/public/15000/100/sol15159.html
- Novell - http://support.novell.com/security/cve/CVE-2014-0160.html
- OpenVPN - https://community.openvpn.net/openvpn/wiki/heartbleed
- Aruba - http://www.arubanetworks.com/support/alerts/aid-040814.asc
- CheckPoint - https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk100173
- openssl - https://www.openssl.org/news/secadv_20140407.txt
- redhat - https://access.redhat.com/security/cve/CVE-2014-0160
- Slackware - hxxp://www.slackware.com/security/viewer.php?l=slackware-security&y=2014&m=slackware-security.533622
- sparklabs/viscosity openvpn client - https://www.sparklabs.com/viscosity/releasenotes/
- watchguard - http://watchguardsecuritycenter.com/2014/04/08/the-heartbleed-openssl-vulnerability-patch-openssl-asap/
- viscosity - https://www.sparklabs.com/blog/
Special Simulcast Presentation from SANS 2014 in Orlando: OpenSSL Heartbleed Briefing by Jake Williams. 8:15pm ET https://www.sans.org/webcasts/openssl-heartbleed-vulnerability-98105, (Wed, Apr 9th)
ISC StormCast for Wednesday, April 9th 2014 http://isc.sans.edu/podcastdetail.html?id=3927, (Wed, Apr 9th)
(this article is work in progress and will be updated as we have new information. Also see the comments for links to signatures and other information provided by readers)
We decided to go to Infocon Yellow to alert readers of this vulenrability.
For those of you using OpenSSL 1.0.1 (most recent Unix systems), it is critical that you patch the openssl library, as well as binaries compiled statically with openssl, as soon as possible. 
The attack will allow a remote attacker to read up to 64kBytes of system memory from your system per attack attempt. The attack works against servers as well as against clients. While not all software using SSL necessarily uses the OpenSSL library, many do. (see our prior diary)
A proof of concept exploit has been made available and I have tested it. It can be used to remotely scan for vulnerable systems.  We have not yet detected wide spread use of the exploit, but it is literally hours old. At this point, we don't think the vulnerability was known in the underground before the official release, but it is possible.What should you do first:
Check if you are vulnerable. "openssl version -a" will return the version information. If your version is 1.0.1, you MAY be vulnerable. Only version 1.0.1g is NOT vulnerable. Other major versions (0.9x, 1.0.0 ...) are not vulnerable.
Rule of thumb: If you are using OpenSSL, and if you are supporting TLS 1.2 (check ssllabs.com) , then you are vulnerable unless patched.If I am vulnerable, what should I do:
Patch! Ubuntu, CentOS and others have patches available. OS X Mavericks has NO PATCH available. Windows is likely not vulnerable, but if you are running open source software like Apache that uses OpenSSL, then you may be vulnerable.
You may want to consider replacing SSL certificates if you are afraid that the exploit was already used against your site. But the exploit is not limited to secret SSL key. All data in memory is potentially at risk.Can I test remotely?
The PoC exploit above can be used to scan your network remotely.How Can I Tell if Someone is Using the Exploit Against Me
We don't have IDS signatures (yet... wait for updates here). There is no log entry in your web server log as the exploit happens after the SSL session is established, and before the HTTP request is sent.
nginx, after being patched, logs the following from the PoC exploit:
2014/04/08 12:37:18 [info] 4151#0: *724561 peer closed connection in SSL handshake while SSL handshaking, client: 22.214.171.124, server: 0.0.0.0:8443
Overview of the April 2014 Microsoft patches and their status.# Affected Contra Indications - KB Known Exploits Microsoft rating(**) ISC rating(*) clients servers MS14-017 Vulnerabilities in Microsoft Word and Office Web Apps Could Allow Remote Code Execution
(Replaces MS14-001 ) Microsoft Word
CVE-2014-1757 KB 2949660 . Severity:Critical
Exploitability: 1 Critical Important MS14-018 Cumulative Security Update for Internet Explorer
(Replaces MS14-012 ) Internet Explorer
CVE-2014-0235 KB 2950467 . Severity:Critical
Exploitability: 1 Critical Important MS14-019 Vulnerability in Windows File Handling Component Could Allow Remote Code Execution
(Replaces MS12-081 ) Windows
CVE-2014-0315 KB 2922229 . Severity:Important
Exploitability: 1 Important Important MS14-020 Vulnerability in Microsoft Publisher Could Allow Remote Code Execution
(Replaces MS13-042 ) Microsoft Publisher
CVE-2014-1759 KB 2950145 . Severity:Important
Exploitability: 1 Important Important We will update issues on this page for about a week or so as they evolve.
We appreciate updates
US based customers can call Microsoft for free patch related support on 1-866-PCSAFETY (*): ISC rating
We use 4 levels:
- PATCH NOW: Typically used where we see immediate danger of exploitation. Typical environments will want to deploy these patches ASAP. Workarounds are typically not accepted by users or are not possible. This rating is often used when typical deployments make it vulnerable and exploits are being used or easy to obtain or make.
- Critical: Anything that needs little to become "interesting" for the dark side. Best approach is to test and deploy ASAP. Workarounds can give more time to test.
- Important: Things where more testing and other measures can help.
- Less Urgent: Typically we expect the impact if left unpatched to be not that big a deal in the short term. Do not forget them however.
- The difference between the client and server rating is based on how you use the affected machine. We take into account the typical client and server deployment in the usage of the machine and the common measures people typically have in place already. Measures we presume are simple best practices for servers such as not using outlook, MSIE, word etc. to do traditional office or leisure work.
- The rating is not a risk analysis as such. It is a rating of importance of the vulnerability and the perceived or even predicted threat for affected systems. The rating does not account for the number of affected systems there are. It is for an affected system in a typical worst-case role.
- Only the organization itself is in a position to do a full risk analysis involving the presence (or lack of) affected systems, the actually implemented measures, the impact on their operation and the value of the assets involved.
- All patches released by a vendor are important enough to have a close look if you use the affected systems. There is little incentive for vendors to publicize patches that do not have some form of risk to them.
(**): The exploitability rating we show is the worst of them all due to the too large number of ratings Microsoft assigns to some of the patches.
------(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Security Updates available for Adobe Flash Player - http://helpx.adobe.com/security/products/flash-player/apsb14-09.html, (Tue, Apr 8th)
-- Rick Wanner - rwanner at isc dot sans dot org - http://namedeplume.blogspot.com/ - Twitter:namedeplume (Protected)(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
OpenSSL 1.0.1g has been released to fix "A missing bounds check in the handling of the TLS heartbeat extension can be used to reveal up to 64kB of memory to a connected client or server. This issue did not affect versions of OpenSSL prior to 1.0.1." known as the Heartbleed Bug .
/*** update by Johannes Ullrich ...: ***/
Ubuntu released a patch for affected versions:
Ubuntu also updated OpenSSH.
CentOS/RHEL has a patch available.
For CentOS, the OpenSSL version did not change. Instead, only the compile time changed. To test if you are running the right version, look at the second line of the "openssl version -a" output:
Fixed version:$ openssl version -a | head -2 OpenSSL 1.0.1e-fips 11 Feb 2013 built on: Tue Apr 8 02:39:29 UTC 2014 Old version: OpenSSL 1.0.1e-fips 11 Feb 2013 built on: Wed Jan 8 18:40:59 UTC 2014 You probably want to make sure you at least restart affected daemons that load OpenSSL, or just reboot the system. If you are concerend that the vulnerability was already used to read memory from your systems, you at least should change your SSL keys.
The quickest way to figure out which version of OpenSSL you are using is:
openssl version -a
But not that some software may be compiled statically with openssl.
For a vulnerable system, this will return a version of 1.0.1f (or anything but 'g'). Also there will be no complier flag-DOPENSL_NO_HEARTBEATS.
For example, on a current OS X Mavericks system, you will get:$ openssl version -a OpenSSL 1.0.1f 6 Jan 2014 built on: Mon Jan 6 23:30:17 PST 2014 platform: darwin64-x86_64-cc options: bn(64,64) rc4(ptr,char) des(idx,cisc,16,int) idea(int) blowfish(idx) compiler: /usr/bin/clang -fPIC -fno-common -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -arch x86_64 -O3 -DL_ENDIAN -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM OPENSSLDIR: "/opt/local/etc/openssl" OS X is not listed in  as vulnerable, but it is assumed that the list published in  is incomplete. The following output comes from a CentOS system, and I used a custom compiled 1.0.1e RPM that had the -DOPENSSL_NO_HEARTBEATS option turned on. # openssl version -a OpenSSL 1.0.1e-fips 11 Feb 2013 built on: Mon Apr 7 21:56:27 EDT 2014 platform: linux-x86_64 options: bn(64,64) md2(int) rc4(16x,int) des(idx,cisc,16,int) idea(int) blowfish(idx) compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -DOPENSSL_NO_HEARTBEATS -m64 -DL_ENDIAN -DTERMIO -Wall -O2 -g -Wa,--noexecstack -DPURIFY -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM OPENSSLDIR: "/etc/pki/tls" engines: dynamic
Guy Bruneau IPSS Inc. gbruneau at isc dot sans dot edu(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
-Kevin -- ISC Handler on Duty(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
ISC StormCast for Wednesday, April 2nd 2014 http://isc.sans.edu/podcastdetail.html?id=3917, (Wed, Apr 2nd)
One of our readers have reported that he has seen a broadcast traffic to udp/137 . He suspected that the traffic cause a denial of service to some of his systems.
If you have seen such traffic and you would like to share some packets we would appreciate that.
(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
The researchers have discovered a new type of vulnerability called Pileup flaws, the vulnerability exist in the Package Management Service.
When a new app installed on old version of Android request a permission for features that don’t exist on that version of Android, however when the user upgrade to the new version, Android keeps all the permissions which mean that they will work in the new version of Android.
The researchers have developed a detection service, called SecUp, which deploys a scanner on the user’s device to capture the malicious apps designed to exploit Pileup vulnerability.
Like many other threats, the best mitigation is installing trusted software only.
 http://www.scmagazine.com/pileup-flaws-enable-privilege-escalation-during-android-updates-researchers-find/article/339854/(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Yesterday, we talked about a scanner looking for Synology devices that was running on a ARM CPU equipped DVR. Looking at a few other sources of these scans, we did see a couple that didn't originate from similar DVRs. The first guess was that the scan originated from a device that was sitting behind a NAT gateway and wasn't exposed. At this point, it could have been "anything", even a good old infected Windows PC.
To our surprise, at least in one case it turned out that a binary by the same name, "cmd.so", was running on the NAT router itself. In addition, a second process was running that looked just like the bitcoin miner we saw running in the infected DVRs. Sadly, we were not able to retrieve the binaries, but the processlist looks similar enough to make us believe that this is the same basic binary just compiled for MIPS in this case (the router in question uses a MIPS CPU).
The first image shows the processlist with "cmd.so". In this case, the binary was dropped in /var/run, not /dev, likely due to the different architecture of the router allowing write access to /var/run. The screen show shows a partial output of the "ps" command executed using the routers web based admin interface.
Figure 1: Partial Process List with "cmd.so". Click on image for larger version.
Figure 2: Partial "ps" output showing the suspected bitcoin miner. In this case, it is called TgW66Q.
The process we think is a copy on minerd uses the same command line parameters as the process we identified as minerd on the DVR.
If you got a router like this, take a look what you find. We do still need a copy of the respective executables to confirm our suspicion.
ISC StormCast for Tuesday, April 1st 2014 http://isc.sans.edu/podcastdetail.html?id=3915, (Tue, Apr 1st)
More Device Malware: This is why your DVR attacked my Synology Disk Station (and now with Bitcoin Miner!), (Mon, Mar 31st)
Update: Just found what looks like a bitcoin miner on the infected DVR. There are two more binaries. D72BNr, the bitcoin miner (according to the usage info based on strings) and mzkk8g, which looksl ike a simplar http agent, maybe to download additional tools easily (similar to curl/wget which isn't installed on this DVR by default). I will add these two files to https://isc.sans.edu/diaryimages/hikvision.zip shortly.
Last week, we reported that some of the hosts scanning for port 5000 are DVRs (to be more precise: Hikvision DVRs, commonly used to record video from surveillance cameras  ).
Today, we were able to recover the malware responsible. You can download the malware here https://isc.sans.edu/diaryimages/hikvision.zip (password: infected) .
The malware resides in /dev/cmd.so . A number of additional suspect files where located in the /dev directory which we still need to recover / analyze from the test system. The compromisse of the DVR likely happened via an exposed telnet port and a default root password (12345).
Analysis of the malware is still ongoing, and any help is appreciated (see link to malware above). Here are some initial findings:
- The malware is an ARM binary, indicating that it is targeting devices, not your typical x86 Linux server.
- The malware scans for Synology devices exposed on port 5000. The http request sent by the malware: