Security Week 02: vulnerable webcams, continuation of 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 browser versions will stop receiving updates even if serious vulnerabilities are discovered. The news is obvious enough not to waste a lot of space in the digest, but it leads me to another thought. Those who use IE 8 should be updated a long time ago, and perhaps the cessation of support will finally push them to this step. Updating is quite simple, although someone will have to buy a new computer for this, but this is not a big problem.

Problems will begin when there are “computers” with a similar approach to development and development, when typical software and hardware become outdated in a maximum of 2-3 years, there will be several dozens in each apartment, from the electricity meter to the kettle and electric stove. Noticeable emphasis on “smart” home appliances at CES(while mostly rather 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 extended to irons and coffee grinders. It will turn out unsafe devices that need to be updated, unsafe devices that are not supported by the manufacturer, unsafe devices that even the manufacturer himself does not know that they are unsafe.

Some kind of not very bright prospect, but so far I do not see other development options. Manufacturers of "smart things", alas, will have to fill the same bumps on their foreheads, which for manufacturers of "large" operating systems have long passed the stage. All digest editions are here .

Methods of screwing the backdoor to a cheap D-Link webcam
News . Research .

Vulnerabilities in webcams are always of great interest. It is clear why: a picture immediately appears in my head as an attacker spies on you and your loved ones. A study by Vectra Networks reveals a serious, but not the worst, problem with such devices. Having bought one of the cheapest D-Link cameras, experts disassembled its firmware and found out what to insert a backdoor into it (in this case, a piece of code that knocks on a potential voyeur’s serverattacker) - easy. Well, how simple it is: you still need to access the device, merge the firmware, fill in a new one. Or you don’t need to get access if you convince the owner of the camera to download the infected “update”. However, it is also unlikely.



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



Speaking of Foscam. This week in the USA there was news that someone not only hacked into the baby monitor of this manufacturer, but also frightened a three-year-old child, talking with him in a scary voice at night. The parents of the child in an interview with the media said that now security is their top priority. Well, at least someone like that.

Juniper decided to remove the vulnerable protocol DUAL_EC_DRBG. The audience is perplexed.
The news .

In the final digest of last year, I suggestedthat the history of the detection of a backdoor and a vulnerability that allows decrypting traffic in Juniper devices will definitely get a continuation. And guessed it. At the beginning of the year, the topic was developed, although it cannot be said that it became clearer. Let me remind you that traffic decryption became possible due to a) the use of the DUAL_EC_DRBG algorithm in the code; b) incorrect implementation of the output of this algorithm. Presumably, some “unauthorized” change in the code made the decryption of traffic possible, but a fair question arises: why was this algorithm for generating pseudorandom numbers inserted into the code? Especially in such a strange form, when the output of this algorithm is additionally processed by another, more secure?

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

That is, it is still possible that this was a series of unintentional errors, but there are too many coincidences to stick to this version further. However, speculation and unconfirmed hypotheses, which are described in more detail, are already beginning from this place.in this stuff wired. Actually, the news of this week is that Juniper decided to completely abandon the use of the dubious algorithm, thus completely closing the vulnerability. But the patch, released in December, did not solve the problem to the end.

Microsoft closes the hole in Silverlight, experts at the Lab talk about how they found the vulnerability
News . Research .

Microsoft's weekly update to cover newly discovered product vulnerabilities this week includedincludes a patch for Microsoft Silverlight, a plug-in that implements approximately the same tasks as Adobe Flash. Vulnerabilities in it are just as dangerous as numerous "holes" in Flash, adjusted for the popularity of the plugin. Vulnerability allows arbitrary code to be executed on the attacked machine. In general, it’s a completely ordinary hole, but there is one “but”: a Kaspersky Lab expert’s study details the history of the discovery, with details that usually remain “behind the scenes” for various reasons.

And the story is interesting. It all started with the infamous hack and leak of HackingTeam archives last year. In the archive itself, exploits were discovered for previously unknown vulnerabilities, in particular in Adobe Flash. But the starting point for finding vulnerability in Silverlight was HackingTeam’s correspondence with the “exploit hunter” - it was analyzed in this article by ArsTechnica. Among other things, reward numbers flashed there for those who prefer to work in the gray zone and cooperate with companies like HackingTeam (or the Zerodium mentioned in my last issue) - for example, $ 20 thousand for information about the vulnerability with a working proof of concept. That is, some kind of exploit was sent, money was received for it, but these are all the introductory ones that were available.

A search by the name of the “hunter” gave information about another vulnerability in Silverlight: the same Vitaly Toporov posted a description on the PacketStorm website and, importantly, proof of concept. PoC is a harmless demonstration of vulnerability, usually researchers show that with the help of a gap you can do anything by running a standard Windows calculator. Assuming that the programming style in the well-known proof of concept and the 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 supposedly could be in the exploit, you need to find them. For search, we used both the Kaspersky Security Network Labs cloud network and the capabilities of the VirusTotal service. At the end of November, the bait worked: first in KSN, and after a few hours a malicious file was uploaded to VirusTotal. Then it remains to analyze this file, determine the vulnerability parameters 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 noteworthy in that it is fundamentally different from most others. Usually they start from the moment the executable file is received and analyzed. And here an example is given that obtaining an executable is also usually a rather difficult task. But not hopeless, even with the very minimum of introductory. More details here .

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

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

Antiquities:
"Feist-760"

A resident dangerous virus, it infects COM and EXE files by default when they are launched and opened. Writes his TSR copy at 9800: 0000, without changing anything in the MCB fields, which can cause the system to freeze. It hooks int 21h.

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

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.