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

    On July 14, Canonical found out that someone owns (and is probably trying to sell) a database of usernames and passwords for two million users of Ubuntu forums . The investigation quickly showed that the information was similar to the truth, after which the forums were simply temporarily disabled. I must say that this is a very correct move, although in another company and in a different situation they might not have decided: how could it be, after all, everyone will find out that we have security problems, and that they might not hack anyone. 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 plugininstalled on vBulletin using SQL injection. The attack became possible due to the use of an outdated version of the plugin. The injection allowed read access to the entire database of the forum, but, according to Jane Silber, director of Canonical, the cracker managed to download only part of the user database with "outdated" passwords, which were also hashed with salt.

    That the current passwords have not leaked, Canonical is sure. They also suggestthat the cracker failed to develop an attack and gain access to something else. For all the exemplary behavior of the company in this case, one cannot fail to note this general uncertainty. In other words, they were convinced where the logs allowed to do it, and then - well, who knows. Everything seems to be fine, especially since before raising the forum, it was almost reinstalled from scratch. The story is with a happy end, but perhaps there is something to fight against in the field of information security, so it is with such uncertainty. Well, I want to learn about hacking not from well-wishers, but on my own, and immediately, but here I’m so lucky.

    HTTPoxy: vulnerability in CGI interface implementation affects a large number of network software
    News .

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



    And the essence of the vulnerability is quite simple. In a situation when it is required to set a working environment in Linux a proxy server for accessing the network, the HTTP_PROXY variable is often used for this. Some implementations of the CGI interface describe a Proxy header that can be passed 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 set from the outside. Anyone leading to an attack like Man in the middle. Interestingly, the specification of a variable is nowhere plainly (for example, in RFC 3875) are not spelled out. The solution is obvious: you need to block the transmission of such a header. But this is for starters, but in general it is necessary to edit the implementation of processing this variable wherever possible.

    Fun fact for a snack: vulnerabilities of 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 escaped the vulnerable implementation of the standard (and wrote about it in the documentation) In the 13th and 15th years, according to researchers of HTTPoxy, VendHQ, the problem surfaced several times on forums and in mailing lists. In one case, the top starter was so struck by the platitudes of misfortune that it added, “I must have missed something here.” But no. A good story about a special direction in security: the correct collection, processing and interpretation of information available to everyone (for years!).

    Oracle closes 276 vulnerabilities in its
    News products .

    In January this year, Oracle releasedrecord cumulative patch, closing in one fell swoop 248 vulnerabilities. In July, the record was 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 must certainly be assessed as positive, although at the end of the year the vendor will probably 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, once the most frequently attacked program, and now giving way to the dubious leadership of Adobe Flash, only 13 vulnerabilities were discovered and closed, 9 of them with the possibility of remote exploitation. This is the third news today with the effect of "spoons were found, sediment remained." Oracle, of course, well done. But I do not think that the administrators of Oracle corporate software will be very glad to need to drop everything and roll such gigantic patches. But you have to.

    What else happened: The
    topic of behavioral analysis and blocking of cryptolockers by the nature of changes in encrypted data is developing. Researchers from two American universities have developedan algorithm that detected all of the 500 (not so much for a serious test) ransomware Trojan samples. But, alas, with the loss of files, apparently due to the fact that the algorithm did not immediately recognize characteristic changes. In each of the tests, the trojans had time to encrypt something. 3 to 29 files were lost depending on the situation. Vulnerability in Juniper network devices is

    closed .

    A super-cheap ransomware Trojan was found in darkweb, only $ 39. Each victim requires about $ 600 and, unusual, after a certain time, encrypted files begin to be deleted slowly. Criminal business class economy.

    Antiquities:
    "V-1260"

    Non-resident harmless ghost virus. It affects .COM files using the Vienna virus algorithm. Encrypted, while using two interesting algorithms. The first algorithm implements the “ghost” property, due to which the two strains of this virus with high probability will not coincide on any byte. The main body of the virus is encrypted depending on the timer in 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 successfully interferes with virus tracing - it uses dynamic ras / encryption of virus codes using int 1 and int 3.

    Quote from the book “Computer viruses in MS-DOS” by Eugene Kaspersky. 1992 year. Page 90.

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

    Also popular now: