{"id":15017,"date":"2014-10-14T17:42:47","date_gmt":"2014-10-14T17:42:47","guid":{"rendered":"http:\/\/kasperskydaily.com\/b2b\/?p=2716"},"modified":"2020-02-26T10:56:37","modified_gmt":"2020-02-26T15:56:37","slug":"how-a-linux-bug-may-affect-windows-based-infrastructure","status":"publish","type":"post","link":"https:\/\/www.kaspersky.com\/blog\/how-a-linux-bug-may-affect-windows-based-infrastructure\/15017\/","title":{"rendered":"How a Linux bug may affect Windows-based infrastructure"},"content":{"rendered":"

The recent developments with \u201cbig bugs<\/a>\u201d such as Heartbleed<\/a> and Shellshock<\/a> created a global security strain with a lot of questions. Both bugs were open-source software-related, but indirectly they could constitute a threat to Windows-based infrastructure.<\/p>\n

How a Linux bug may affect Windows-based infrastructure #enterprisesec<\/p>Tweet<\/a><\/blockquote>\n

Many IT workers agree that to determine how a Linux bug might affect Windows-based infrastructure, certain clarifications are required. They have pinpointed a few scenarios where a successfully exploited flaw in Linux, or some additional software used with it, may be used to inflict harm on Windows-based infrastructure. Depending on the position of the Linux-based machine in the network, the consequences may be more or less dramatic.<\/p>\n

\n<\/p>

1. <\/strong>At the gates\u2026<\/strong><\/p>\n

The worst-case scenario is when the flawed Linux-based machine is the main gateway of a company\u2019s local network.<\/p>\n

If it goes down, so does the entire network: it stops distributing the network addresses, no traffic is going through it so you get disconnected from the Web, and the local network is crumbling. It doesn\u2019t matter if the endpoint workstation is based on Windows, Mac OS X, or another OS (some desktop variant of Linux perhaps). If attackers have \u201cpwned\u201d and crashed the gateway, the entire system is gone. However, it is more likely that commercial-minded attackers would use this machine to set up a foothold within the corporate network for some time \u2013 possibly a very long time given that the network devices are often overlooked, and the Linux-based machines are considered safe and resilient to attacks.<\/p>\n

The same server may be also used to redirect all traffic to or through some malicious website, seeding Windows malware all over the endpoints. A few years ago a handful of DNS-changing Trojans ran rampant, among them the notorious Zlob Trojan. One of its variants was called DNSChanger and it took the FBI\u2019s \u201cOperation Ghost Click\u201d to take it down. The FBI hijacked<\/a> DNSChanger\u2019s C&C servers, and then kept them up for months while actively promoting the measures to clean the endpoint PCs so that people wouldn\u2019t lose connection to the Internet completely.<\/p>\n

Some other Zlob variants were attempted \u2013 often quite successfully \u2013 to hack any detected router and change the DNS settings. Then it would re-route traffic from legitimate websites to suspicious or malicious ones, while displaying the stacks of adult-themed banners in the browser.<\/p>\n

If we speak specifically to Shellshock, the concerns that it can be used in order to conduct attacks against broadband routers surfaced almost immediately<\/a>. And since Shellshock grants a potential ability to run an arbitrary code on the affected system, it\u2019s not hard to imagine a multi-stage attack with the goal to set the entire network of a targeted company on fire \u2013 or just spy on it.<\/p>\n

\"wide-7\"<\/a><\/p>\n

2. Where the wild files grow<\/strong><\/p>\n

Another scenario: Attackers would love to get the server under their control so that they will have access to all corporate data stored there and shared between the employees, given that it\u2019s unencrypted.<\/p>\n

It is common for a company to use some Linux-based file-server for their collaboration and file-sharing needs while the endpoints are Windows-based. Attackers might spear-phish some of the target company\u2019s employees, delivering spying malware on his or her desktop and getting it under their control. Then they\u2019d try to identify the file-server, given it is located on the same network as the attacked desktop, and after making sure that it runs on Linux with unpatched Bash, exploit its vulnerability to take it over as well. From there, they can theoretically do anything with data stored there \u2013 export, modify, delete or even install extra malware which would be distributed across the whole network, infecting other desktops. If the data isn\u2019t encrypted, that\u2019s all an easy task.<\/p>\n

Taking over a server is just like taking the high ground. #enterprisesec<\/p>Tweet<\/a><\/blockquote>\n

The possibility of such \u201cmulti-route\u201d attacks where attackers use malware for different operating systems had been envisioned by Kaspersky Lab\u2019s experts many years ago<\/a>; even then it was clear that despite the general opinion, Linux wasn\u2019t safe from malware attacks.<\/p>\n

There is also a question of attacking a virtual infrastructure where most of the VMs run on Windows, while the hypervisor is a Linux-based solution. This will be covered in one of our upcoming posts.<\/p>\n","protected":false},"excerpt":{"rendered":"

The recent developments with “big bugs” such as Heartbleed and Shellshock created a global security strain, with many questions emerging. Both bugs were open-source software-related, but indirectly they would constitute a threat to Windows-based infrastructure. In this post we review a few scenarios of an attack on mostly Windows-based network with Linux servers at certain points.<\/p>\n","protected":false},"author":209,"featured_media":15916,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1999,3052],"tags":[588,562,36,838],"class_list":{"0":"post-15017","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-smb","9":"tag-heartbleed","10":"tag-linux","11":"tag-malware-2","12":"tag-shellshock"},"hreflang":[{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/how-a-linux-bug-may-affect-windows-based-infrastructure\/15017\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/how-a-linux-bug-may-affect-windows-based-infrastructure\/15017\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/how-a-linux-bug-may-affect-windows-based-infrastructure\/15017\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.com\/blog\/tag\/heartbleed\/","name":"Heartbleed"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/15017","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/users\/209"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/comments?post=15017"}],"version-history":[{"count":5,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/15017\/revisions"}],"predecessor-version":[{"id":33351,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/15017\/revisions\/33351"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/media\/15916"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/media?parent=15017"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/categories?post=15017"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/tags?post=15017"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}