Security Week 02: Vulnerable Webcams, Continuing the Story with Juniper, Zero-Day in Silverlight and How It Was Found

This week one of the most talked about news was the end of support for Microsoft Internet Explorer 8, 9 and 10. These versions of browsers will stop receiving updates even in case of detection of serious vulnerabilities. The news is obvious enough not to waste a lot of space on it in the digest, but it gives me one more thought. Those who use IE 8, it is time to upgrade, and perhaps the termination of support will finally push them to this step. It is quite simple to upgrade, although someone will have to buy a new computer for this, but this is not a big problem.

The problems will begin when “computers” with a similar approach to development and development, when typical software and hardware become obsolete in a maximum of 2-3 years, will be several dozen in each single apartment - from an electric meter to a kettle and electric stove. A noticeable emphasis in the direction of "smart" household appliances at CES (so far mostly quite strange and insanely expensive refrigerators and washing machines) shows that this will happen pretty soon. In its current form, such devices can work for decades. And in the future? Imagine the Android ecosystem that is common to irons and grinders. There will be unsafe devices that need to be updated, unsafe devices that are not supported by the manufacturer, unsafe devices that even the manufacturer does not know that they are unsafe.

Some not very bright prospects, but so far I do not see other options for development. The producers of “smart things”, alas, will have to fill the same bumps on their foreheads, which for manufacturers of “big” operating systems have long passed stage. All issues of digest - here .

Methods of screwing the backdoor to a cheap webcam D-Link
News Research
')
Vulnerabilities in webcams are always of great interest. It is clear why: a picture immediately appears in my head, as the attacker spies on you and your loved ones. Vectra Networks research reveals a serious but not the most terrible problem with such devices. Having bought one of the cheapest D-Link cameras, the experts disassembled its firmware and found that inserting a backdoor into it (in this case, a piece of code that knocks on the server of a potential attacker voyeurist ) is easy. Well, how easy it is: you must still get access to the device, merge the firmware, fill in a new one. Or do not get access, if you convince the owner of the camera to download the infected "update". However, it is also unlikely.



The main complaint of researchers to D-Link is that the authenticity of the code is not checked anywhere in the device. It is quite reasonable, but more serious things about security happen with webcams. It is enough to recall the last year’s hacking of Foscam webcams, in which there wasn’t any hacking - just cameras with default settings were accessible from the network without any protection.



Speaking of Foscam. This week in the US there was news that someone not only hacked the baby monitor of this manufacturer, but also frightened a three-year-old child, talking to him at night in a terrible voice. Parents of the child in an interview with the media reported that now safety is their top priority. Well, at least someone like that.

Juniper decided to remove the vulnerable DUAL_EC_DRBG protocol. The audience is at a loss.
News

In the final digest of last year, I assumed that the story of the discovery of the backdoor and the vulnerability that allows decrypting traffic on Juniper devices will definitely be continued. And guess. At the beginning of the year, the topic was developed, although it cannot be said that it has become clearer. Let me remind you that traffic decoding was made possible thanks to a) the use of the DUAL_EC_DRBG algorithm in the code b) the incorrect implementation of the output of this algorithm. Presumably, a certain “unauthorized” change in the code made traffic decoding possible, but a fair question arises: why did this algorithm for generating pseudo-random numbers at all inserted into the code? Especially in such a strange way, when the output of this algorithm is additionally processed by another, more secure one?

At the Real World Crypto conference, a representative group of researchers was also unable to answer this question, but shared the results of analyzing the code of different versions of ScreenOS, a system that runs NetScreen devices. It turned out that the algorithm appeared there in 2008 or 2009 - exactly after it became finally clear in 2007 that something was wrong in DUAL_EC. Before ScreenOS version 6.2, only the ANSI X9.31 algorithm was used. In the same version, together with this algorithm, DUAL_EC began to be used, and the output of the latter was increased from 20 bytes to 32 - this particular nuance made the attack possible.

That is, it is still possible that this was a series of unintended errors, but too many coincidences in order to continue to adhere to this version. However, conjectures and unconfirmed hypotheses, already described in detail in this material by Wired, are already starting from this point. Actually, the news of this week is that Juniper decided to completely abandon the use of a dubious algorithm, thus finally closing the vulnerability. But the patch, released in December, did not completely solve the problem.

Microsoft closes the hole in Silverlight, the experts of the "Lab" tell how they found the vulnerability
News Research

The weekly update of Microsoft, closing the newly discovered product vulnerabilities, this week included a patch for Microsoft Silverlight, a plug-in that implements roughly the same tasks as Adobe Flash. Vulnerabilities in it are just as dangerous as numerous “holes” in Flash, adjusted for the plugin’s popularity. Vulnerability allows to execute arbitrary code on the attacked machine. In general, this is quite an ordinary hole, but there is one “but”: a study of Kaspersky Lab experts tells in detail the history of detection, with such details that usually remain “behind the scenes” for various reasons.

And the story is interesting. It all started with the infamous hacking and leaking archives of HackingTeam last year. In the archive itself, exploits were discovered for previously unknown vulnerabilities, in particular in Adobe Flash. But the starting point for searching for vulnerabilities in Silverlight was HackingTeam's correspondence with the “exploit hunter” - it was analyzed in this article by ArsTechnica. Among other things, there were flashes of remuneration figures for those who prefer to work in the “gray” zone and cooperate with companies like HackingTeam (or the one I mentioned in the previous issue of Zerodium) - for example, $ 20,000 for information about vulnerability with a working proof of concept. That is, some exploit has been sent, the money received for it, but this is all the introductory data that was available.

A search by the name of the “hunter” gave information about another vulnerability in Silverlight: on the PacketStorm website, the same Vitaly Toporov posted the description and, importantly, the proof of concept. PoC is a harmless demonstration of vulnerability, usually researchers show that with the help of a flaw, you can do anything you want by running the standard Windows calculator. Assuming that the programming style in a well-known proof of concept and an unknown exploit written by one author may coincide, the experts created a YARA rule that looks like this:



Everything is simple here - there are text strings that can presumably be in the exploit, you need to find them. For the search, both the Kaspersky Security Network's Laboratories cloud network and the capabilities of the VirusTotal service were used. At the end of November, the bait worked: first in KSN, and after a few hours a malicious file was uploaded to VirusTotal. It remains to analyze this file, determine the parameters of the vulnerability and report the information to Microsoft - it turned out that this is still a new vulnerability, previously unknown. Interestingly, the file was compiled just 2 weeks after the leak of the HackingTeam archives - that is, someone probably carefully analyzed the archives, not being limited by law, ethics or anything else.

The study is remarkable in that it is radically different from most others. Usually they start from the moment of receiving the executable file and its analysis. And here is an example that getting the executable is also usually a rather difficult task. But not hopeless, even with the very minimum of input. Read more here .

What else happened:
17 vulnerabilities closed in Adobe Reader and Acrobat.

Arrested members of the group that stole money from ATMs using a malicious attack Tyupkin .

Antiquities:
"Feist-760"

Resident dangerous virus, typically affects COM- and EXE-files when they are launched and opened. Records its TSR copy at 9800: 0000, without changing anything in the MCB fields, which can cause the system to hang. Intercepts int 21h.

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

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.