Today, a new vulnerability affecting the widely used Samba software was released. Samba is the SMB/CIFS protocol commonly used in *NIX operating systems. CVE-2017-7494 has the potential to impact many systems around the world. This vulnerability could allow a user to upload a shared library to a writeable share on a vulnerable Samba server and result in the server executing the uploaded file. This would allow an attacker to upload an exploit payload to a writeable Samba share, resulting in code execution on any server running an affected version of the Samba package. This currently affects all versions of Samba 3.5.0 (released March of 2010) and later. To emphasize the severity and low complexity: a metasploit one-liner can be used to trigger this vulnerability.
A patch has already been released to address the issue. Additionally, there is a mitigation available within the configuration of Samba itself. Adding the argument “nt pipe support = no” to the global section of the smb.conf file and restarting the service will also mitigate the threat. This threat is only beginning to be recognized by potential attackers with POC code having already been released on the Internet. It is only a matter of time before adversaries begin to use it more widely to compromise additional systems, both externally and internally.
This post was authored by Martin Zeiser with contributions by Joel Esler
At Talos we are constantly on the lookout for threats to our customers networks, and part of the protection process is creating Snort rules for the latest vulnerabilities in order to detect any attacks.
To improve your understanding of the rule development process, consider a theoretical remotely exploitable vulnerability in server software Server2010. A proof-of-concept exploit is developed, the server software set up on a virtual machine, traffic is captured on the network between attacker and victim, rule development can start, right?
But what if months or years later, the rule needs to be re-inspected, because circumstances have changed? This requires another vulnerable version of Server2010 to be found, reinstalled and reconfigured to the vulnerable parameters, to run tests again and again, so that network traffic can be inspected. Then when the server is installed, the particular exploit used does not work anymore, because the language it was written in has since changed and the code needs to be fixed accordingly. All this requires plenty of time, which is why it doesn’t happen that way. Instead, a vulnerability is identified, an exploit is written, the exploit is ran, and the attack captured using Wireshark. From then on, the traffic in said pcap file can be used to develop a correct rule. The traffic recorded in a pcap file can easily be put back on the wire using a tcp replay utility, or read directly by Snort. This is why rule developers generally work with pcaps of attacks, instead of exploits.
Regarding file-based vulnerabilities, the original process used to involve starting a local webserver and using a browser to download the exploit file, while recording the transfer using Wireshark. File2pcap revolutionized this requirement by simulating the traffic and creating the proper pcap without any hassles.
Streams of malicious emails Talos inspects every day usually consist of active spamming campaigns for various ransomware families, phishing campaigns and the common malware family suspects such as banking Trojans and bots..
It is however often more interesting to analyze campaigns smaller in volume as they might contain more interesting malware. A few weeks ago I became interested in just such a campaign with a smaller number of circulating email messages. The email, first of them submitted from Middle East, purports to be coming from a Turkish trading company, which might further indicate the geographic area where the attacks were active.
Analyzing malware is often like solving a puzzle, you have to do it piece by piece to reach the final image. In this case I spent more time analyzing the campaign than I initially planned. The campaign has many stages of the infection chain and all needed to be unraveled before the final payload level was reached. Furthermore, each of the stages used different development platform and was obfuscated in a different way. But let us start from the beginning.
When the WannaCry attack was launched a little over a week ago, it was one of the first large scale attacks leveraging the data that was leaked by the Shadow Brokers. At the time the real concern was how quickly we would begin to see other threats leverage the same vulnerabilities. Over the past couple of weeks, Talos has observed other malware variants that are using the ETERNALBLUE and DOUBLEPULSAR exploits from the Shadow Brokers release as part of their campaigns. Among them were Adylkuzz, Uiwix, and EternalRocks.
Adylkuzz is a piece of malware that uses ETERNALBLUE and DOUBLEPULSAR to install cryptocurrency mining software on the infected system. This attack actually pre-dates the WannaCry attack and has continued to deliver the cryptocurrency miner.
Uiwix uses a similar technique to install ransomware on the infected system. When the files are encrypted, the file names include “UIWIX” as part of the file extension. The key difference with this malware is that, unlike WannaCry, the Ransomware doesn’t “worm itself.” It only installs itself on the system.
Talos is monitoring the major Exploit Kits(EK) on an ongoing basis. While investigating the changes we recently observed in the RIG EK campaigns, we identified another well known candidate: Terror Exploit Kit.
Terror EK is one of the new players who showed up after the big Exploit Kit market consolidation last year. When Angler and friends disappeared new EKs started to try their luck. Many of them were far from Angler’s quality. One of these was Terror EK which appeared end of last year. It started with a very simple version,carpet bombing the victims with many exploits at the same time, no matter if the exploit matched the victim’s browser environment or not. Unfortunately, they improved the kit step by step and we saw a fast evolution up to the latest version analysed in this report.
We identified a potentially compromised legitimate web site acting as a malware gate, redirecting visitors initially to a RIG exploit kit landing page, then switching to Terror exploit kit one day later.
This may indicate how these campaigns collaborate and share resources, or possibly one campaign pirating another. Terror seems to constantly evolving. In this campaign it has added further exploits and no longer carpet bombs the victim. Instead it evaluates data regarding the victim’s environment and then picks potentially successful exploits depending on the victim’s operating system, patch level, browser version and installed plugins. This makes it harder for an investigator to fully uncover which exploits they have.
It is interesting to note that the adversaries are using an URL parameter in cleartext for the vulnerability they are going to exploit, e.g. cve2013-2551 = cve20132551 in the URL.
When Talos decided to make a threat intelligence podcast, we wanted to make it different than your typical buttoned down, subdued security podcast. The BWT crew: Craig, Joel, Nigel, and Mitch, decided to do that by making a podcast that is a lot like the discussions that you would have after work with colleagues – if your colleagues were both ridiculously opinionated and hyper-focused on security research. Occasionally we’ll even have some special guests join us.