Security Week 29: Ubuntu forum leak, proxy vulnerability in PHP, Go and Python, 276 Oracle patches

On July 14, Canonical learned that someone owns (and probably is trying to sell) a base of logins and passwords for two million users of the Ubuntu forums . The investigation quickly revealed that the information was similar to the truth, after which the forums were simply temporarily disabled. It must be said, this is a very correct move, although in another company and in a different situation you could not decide on it: how can it be, after all everyone will know that we have security problems, and so no one can be hacked. Actually, we all know this thanks to a detailed description of the incident on the Ubuntu developers site, so everything seems to have ended well.



Or not? The leak (a detailed description of the events in this news ) began with the exploitation of a vulnerability in the Forumrunner plugin installed on vBulletin using SQL injection. The attack became possible due to the use of an outdated version of the plugin. The injection opened read access to the entire forum database, but, according to Jane Sylber, director of Canonical, the hacker managed to download only part of the user base with “outdated” passwords, which were also hashed with salt.



The fact that the actual passwords are not leaked to Canonical sure. It also suggests that the attacker failed to develop the attack and gain access to something else. With all the exemplary behavior of the company in this case, it is impossible not to note this general uncertainty. In other words, they were convinced where the logs allowed, and then - who knows? It seems to be all right, especially since before raising the forum, it was almost reinstalled from scratch. The story of a happy ending, but perhaps with what you need to fight in the field of information security, so it is with such uncertainty. Well, I don’t want to find out about the burglary from well-wishers, but on my own, and immediately, but then how lucky you will be.



HTTPoxy: CGI implementation vulnerability affects a large amount of network software.

News

')

We have another vulnerability with an attractive brand and even a logo, but it seems we have become accustomed to this. Moreover, the vulnerability is noteworthy for its wide coverage of the affected software. As a rule, such universal holes are found in reusable libraries: we can recall last year’s example of Apache Commons Collections. HTTPoxy ( vulnerability site ) is steeper along the damage radius, since this vulnerability is not in the software, but in the implementation of the CGI interface. These are, for example, standard libraries for PHP, Go, and Python programming languages, and, accordingly, web applications and scripts implemented on them. There is a huge amount of them, both ready and self-written, and the best solution is to block the possibility of exploiting vulnerabilities for everything at once, making changes to the Apache, NGINX, lighttpd configs and other software.







And the essence of the vulnerability is quite simple. In a situation when you need to set a Linux proxy server to access the network, the HTTP_PROXY variable is often used for this. In some implementations of the CGI interface, a proxy header is described that can be transferred to the server during data exchange, and on the server side this information is stored in the HTTP_PROXY variable. Actually everything, the problem is just a name conflict, and this allows in many situations to send data through a proxy server, which was specified outside. Anyone that leads to a Man in the middle attack. Interestingly, the specifications for the variable are not available anywhere (for example, in RFC 3875 ). The solution is obvious: you need to block the transfer of such a header. But this is for the beginning, but in general it is necessary to correct the implementation of the processing of this variable wherever possible.



Fun fact for a snack: vulnerabilities 15 years. It was first discovered and fixed in the libwww_perl library in March 2001. In April of the same year, a similar problem was fixed in the curl utility. In 2012, Ruby developers avoided the vulnerable implementation of the standard (and wrote about it in the documentation ). In the 13th and 15th years, according to VendHQ’s HTTPoxy researchers, the problem surfaced several times in forums and mailings. In one case, the topstarter was so overwhelmed with the banality of misfortune that it added “for sure I missed something here.” But no. A good story about a special direction in security: the correct collection, processing and interpretation of information available to all (for years!).



Oracle closes 276 vulnerabilities in its products

News



In January of this year, Oracle released a record cumulative patch, covering 248 vulnerabilities in one fell swoop. In July, the record is broken with a margin: a monthly security update closes 276 vulnerabilities in 84 products. Knowing how difficult it is to test many products at once in different scenarios, this news should certainly be assessed as positive, although at the end of the year the vendor will most likely fall into the next incorrect list of the most unsafe developers. However, the identified problems do not become easier from this: out of 276 vulnerabilities, 159 can be exploited remotely, 19 (in nine products) are rated at 9.8 points on the CVSS scale.





However, in Java, which was once the most frequently attacked program that has now ceded the dubious leadership of Adobe Flash, only 13 vulnerabilities were discovered and closed, 9 of them with the possibility of remote operation. This is the third news for today with the effect of "spoons were found, sediment remained." Oracle, of course, well done. But I do not think that administrators of Oracle corporate software will be very happy about the need to drop everything and roll such giant patches. But you have to.



What else happened:

The topic of behavioral analysis and blocking of crypto-fiber by the nature of changes in encrypted data is developing. Researchers from two American universities have developed an algorithm that detects all of 500 (not so many for a serious test) samples of ransomware Trojans. But, alas, with the loss of files, apparently due to the fact that the algorithm did not recognize the characteristic changes immediately. In each of the tests, the Trojans had something to encrypt. Depending on the situation, between 3 and 29 files were lost.



Vulnerability in Juniper network devices.



A dark-blooded extortionist Trojan was found in the Darkbow, for a total of $ 39. About 600 dollars are demanded from each victim and, which is unusual, after a certain time, encrypted files are slowly being deleted. Criminal business class economy.



Antiquities:

"V-1260"



Nonresident innocent virus "ghost". It infects .COM-files according to the “Vienna” virus algorithm. Encrypted, while using two interesting algorithms. The first algorithm implements the “ghost” property, so that two strains of this virus will most likely not be the same on one byte. The main body of the virus is encrypted depending on the timer for the 16777216 variants, and the decryptor is selected from more than 3,000,000,000,000,000,000,000 variants (the length of the decryptor is 39 bytes). The second algorithm quite successfully interferes with the tracing of the virus - it uses dynamic propagation / encryption of virus codes using int 1 and int 3.



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



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.