📜 ⬆️ ⬇️

Security Week 18: VirusTotal for justice, vulnerability in Android, leak of Slack tokens

Let's start the release with a very fresh news, which, however, is only indirectly related to the landscape of threats. On May 4, a seemingly inconspicuous post appeared on the VirusTotal blog blog, now owned by Google. The service that allows you to aggregate information about the verdicts of various antivirus engines, will now differently “give” information about detects. Now, in order to receive data about detected files automatically, using the API, it is required to connect your own product to the VirusTotal system without fail.

Why is it important? Initially, VirusTotal was a project for researchers: to determine whether defensive solutions were detecting a specific file meant saving time and spending it on more interesting things. As the service grew, new features also appeared: information about when a file was uploaded sometimes also could tell a lot about its purpose and origin (especially if the file was downloaded by the affected user, or even by the author of the malicious program). Now millions of files pass through VirusTotal: in the past seven days, 1.2 million, of which 400,000 have been detected by one or more anti-virus engines.

In short, if there is access to this information, then it is only on its basis that you can create your own, fairly well-functioning type of protective solution. Or, at least, to get an unfair advantage by getting data from the industry, but not giving anything back. Not anymore. The VT post contains an interesting set of rules for using the service, where its creators criticize a couple of well-established myths. More about them - under the cut.
All editions of the digest are available by tag .

Let's start with the fattest hint: "VirusTotal cannot be used as a substitute for antivirus solution." Further more: VirusTotal data (as participating vendors in the project detect files) should not be used as the only evaluation criterion for creating signatures. More importantly: VirusTotal should not be used to compare the effectiveness of security solutions. This service is focused on the work of anti-virus engines. Its creators directly say that the correct protective solutions are not limited to the antivirus engine - that is, if VirusTotal shows that the antivirus does not detect a specific file, this does not mean that the solution will not be able to block the threat .
')
Finally, to obtain data from VirusTotal, applicants must not only provide their antivirus engine, but also actively participate in independent testing according to AMTSO standards. This practice is supported by virtually the entire security industry, with the exception of companies that for some reason do not want to publish the results of a comparison of the effectiveness of their solutions. Well, it is clear for what. In general, this is such an important production news. VirusTotal turned out to be one of the data exchange points between competing companies. Such an exchange is very valuable, and innovations in the service correct a small bias in his work, in effect eliminating the possibility of using information without giving anything in return.

Amazon-like security hole found in Slack
News Research

Slack is a popular group communication platform used by many companies, including the largest ones. In addition to a variety of functionality for collective chats, the service allows you to connect "bots" - both ready and written by the client independently. Bots greatly expand the capabilities of Slack by adding the most trivial options like RSS import and complex functionality - shut down the server, notify employees of service failures, report weather outside the window.

"Vulnerability", discovered by researchers at Detectify Labs, turned out to be trivial. The code of some bots is laid out on GitHub, and in this code you can find a token to access the working environment of a group of users or a company. As it turned out, the token gives access to virtually all information within the group: chat rooms, files, and so on. In general, the repeatedly described rakes, for example, with laying out the keys to machines in Amazon EC2, are still popular.



Slack quite reasonably reacted to the discovery in the style of “this is not a bug, this is a feature,” and this is indeed the case. Not all bots need to be given full access, but some are necessary, and nothing can be done about it. As a result, the company conducted its own audit of the code on GitHub and sent messages to all those who were at fault. The conclusion here is clear: hard keys are very, very bad. It’s interesting in the whole history and this moment: no matter how harsh the security measures inside the company’s perimeter are, services like Slack are out of it, and the huge flow of extremely sensitive data is out of control. And in fact, even prohibiting will not help: intracorporate protected services often lose outright in public convenience.

Another vulnerability in Android allows you to quietly drag an exploit into a legitimate application.
News Research

FireEye reports about a serious new vulnerability found in various versions of Android, from 2.3 to 5.0, although smartphones and tablets with Android 4.3 and earlier versions are at risk - that is, those that most likely will not be updated. Vulnerability, in short, allows you to bypass the limitations of the system to access data and, through one place (more specifically, through a network daemon), steal, say, SMS information.



Apparently, the vulnerability was entered into the code base of the Android Open Source Project by Qualcomm (she also provided the patch), therefore, hardware devices from this manufacturer are primarily affected. But not necessarily: the netd daemon code (formerly network_manager) is open and can be used by anyone. In general, the hole was so advantageously located that any application that requests access to the network, that is, every first one, can use it. As a result, a malicious application (or legitimate, but with additional “features”) can get the same data access rights as the system user “radio”. That is why, starting with Android 4.4, there are few chances to get useful information in this way: security has been enhanced, and the rights of network processes (including netd) are curtailed.

Cases of exploitation of vulnerabilities have not yet been noticed: fortunately, most of the holes in Android so far only hint that something needs to be done with platform fragmentation. But nothing positive in this direction is happening: in fact, regular security updates are received only by “own” Nexus devices. There is one significant commentary on the article about the vulnerability in ArsTechnica: while on the Android platform there is a massive infection a la the Slammer epidemic on Windows, nothing will change. I would like to hope that this will not happen.

But virus writers, as always, are at the forefront of progress: another Trojan stealing data is distributed under the guise of a system update for Android.

What else happened:
Two very serious vulnerabilities in OpenSSL.

Closed a big hole in Office 365.

Antiquities:
Anti-Pascal Family

A family of five very dangerous non-resident viruses. Not more than two files in all directories on the current drive and on the C: drive are infected or spoiled. When searching for uninfected files, a recursive directory traversal is used. They infect .COM-, .BAK- and .PAS-files. In the case of a .COM file, the virus is recorded at its end (virus versions of lengths 400, 440, and 480) or the beginning (the remaining versions of the virus). When infecting .BAK- and .PAS-files is written to the beginning of the file, while the old beginning is not saved, that is, the file is irretrievably lost. Some versions of the virus rename .BAK and .PAS files to .EXE.

Quote from the book "Computer viruses in MS-DOS" Eugene Kaspersky. 1992 Page 24.

Disclaimer: This column reflects only the personal opinion of its author. It may coincide with the position of Kaspersky Lab, or it may not coincide. Then how lucky.

Source: https://habr.com/ru/post/283084/


All Articles