Security Week 09: Cloudflare Vulnerability, IoT Bears Privacy

Day at the branch of the bank "Breakthrough" Ivan Petrovich Khatatapasov not asked. On the eve they sent a muddy and promising paper from the center about the introduction of some new practices and metrics. In the morning, a truck drove into the courtyard of the bank and unloaded a shapeless pile of money right on the ground. By telephone, Ivan Petrovich was told that as part of the optimization of the regional network, a small part of the funds would be temporarily stored in this department, for which Ivan Petrovich could receive a commission: “Well, take a bucket of money there. No, receipts are not needed, but only one bucket. ”



Having spent the whole night with a rifle on a heap of dough, Ivan Petrovich protested, but he was made to understand that this is a new progressive edzhyle banking technique incorporated on the basis of the best examples of world case studies, and there is nothing here to arise at all. The pile was left unattended: it was successfully sprinkled with snow, and in general it was not so noticeable from the street, although attempts to recount the money all the time gave a different amount: incomprehensible young people on the trucks periodically took something and brought it by eye.



That is, ahem, what is it about me. The above absurdity in the context of storing personal data online regularly turns into a harsh reality: then Yahoo! billions! passwords! stolen!, then from Cloudflare as a result of an error ( news ) important data will spray a thin layer on the sites of clients and Google. Today's issue is about privacy. And the correct risk assessment.



What happened to Cloudflare?

It all started with this tweet:

')





A researcher from the Google Project Zero team, Tavis Ormandi (I already wrote about him earlier ) found in the infrastructure of the company Cloudflare, which provides content delivery services, protection from DDoS attacks and others, a serious vulnerability. It is difficult to describe it in simple words, except perhaps only such: “the robots have broken”. The various Cloudflare services are based on a single principle: a layer is built between the site and the visitor, data is transmitted through a proxy, as a result of which it becomes possible to balance the load, cut off DDoS garbage traffic and so on.



It is with the proxy infrastructure, which is essentially common to all clients, and the problem occurred. In addition to sending web pages on the way from the server to the client, they could have been modified: the code for analytics was inserted, e-mail addresses and the like were obfuscated. The process that controlled the modification on the proxy side had a bug in it that inserted some garbage into the code. As Tavis Ormandi found out, it was not garbage at all, but pieces of data from the RAM of the proxy server, containing, among other things, private data. Cookies, authorization tokens and other very valuable information. The issued web pages were eventually indexed by search robots.



I must say that the investigation of this vulnerability was almost a reference. The vulnerability was closed by disabling non-critical services on the side of Cloudflare within 24 hours. At the same time, serious work was done with search engines (primarily on Google, but not only) on removing indexed private information. Reports on the nature of the problem - detailed, with code examples. More information - at Cloudflare blogpost and Tavis bug report.



It is more difficult to answer the question: Who has suffered and what now to do with it? I will try, by virtue of my capabilities, to highlight this topic, but first I will tell about smart, but vulnerable teddy bears.



Bears, Karl!



More than two million voice messages were recorded to smart children's toys.

News The blog post researcher Troy Hunt.



There is such a company Cloudpets . Produces children's toys with enhanced functionality. You can remotely deliver voice messages using a wireless network connection to a bear (or whatever, whatever). The user of the bear (oh everything) sees the receipt of a new message in the form of a flashing heart, and can lose it by making a hug session with the device (aaaaaa!).







AAAAAAAAAAAAA!

No, and what? Brave new world. Everything would be fine, but a database of users, including personal data and recorded voice messages, was placed on a badly protected server. For data storage, the MongoDB DBMS was used, due to the crooked settings available from the Internet without authorization. Unprotected DBMSs are increasingly falling victim to hackers and extortionists - I wrote about this at the beginning of the year.



In the process of disclosing information about the vulnerability of the vendor, everything went wrong. The problem was discovered immediately by two researchers independently of each other. Their messages to the manufacturer were ignored. Only the researcher Troy Hunt was able to force the vendor to react when he reported a problem on his blog. In response, Cloudpets reported that (a) the data were actually available, but information can only be obtained by knowing the password of a specific user and (b) the storage and management of the database was carried out by a third-party organization, for which the vendor cannot be responsible.







Seriously, they said so. They also explained the lack of response to the initial messages: “We cannot accept such serious information when it is not clear who sends it.”



Come on! About passwords: it is clear that the requirements for such a service are very minimal, and it is quite easy to pick up many of them (more than 800,000 users were affected, if we take it into account). The problem is not even in the leakage of personal data (the database was open for a long time and anyone could download it), the problem was not the most adequate reaction of the vendor. Well, and a note for the future: even if the contractor is to blame for the leak, the customer will still suffer damage. Alas.



What to do?



So, about the risk assessment. In the case of teddy bears, only end users suffered, most of them, unfortunately, do not even know about the problem. The potential victims of Cloudflare are medium and large companies. So it turns out that businesses have to spend significant funds on the development of their own expertise, including in order to properly assess the risks of another threat .



If somewhere on the Internet something happened, you need to understand how this affects the risks of your business. On the example of Cloudflare, it is clear that the polar variants: “this does not concern us” and “aah, everything is lost, we all will die” are equally bad. Such estimates from the shoulder - rather the lot of the media and weekly digests . The only adequate analysis of the problem from this point of view is published here , and then, in my opinion, it is too alarmist. Considering that the Cloudflare service has led to a random leakage of any data that is at the time of the bug in the server’s memory, it can be argued that all the clients of this company are at risk. Who exactly is impossible to know, information from the search engines is worn out. At the same time, no one excludes the presence of leaks on the side of informal robots-assemblers, who do not work not on search, but in general with not very clear goals. The chances that the bad guys have the data are there, but it is impossible to verify.



And now what? Reset passwords to all users? Recall authorization tokens? The general conclusion is probably the following: no sharp movements should be made, but we must assume that the probability of a leak is different from zero, know the possible parameters of this leak and be prepared for the fact that the data can be used to attack. The story of Cloudflare - it’s not about real trouble, it’s more about how information security is no longer limited to patching up fresh holes. This is a tactic, and still need a strategy. You need to build protection based on the fact that your data are dumped somewhere in a heap in some backyard.



With bears easier. When buying a toy for a child, you need to understand that your messages are already being heard by someone else. This is not paranoia, this is reality. It is not enough to make a beautiful and smart toy, it is required to provide at least some evidence that you, as a vendor, have thought about the security of other people's data.



Slightly crazy about what is happening, the editorial board of the weekly digest goes on a short vacation. Do not switch, we will return.

Antiquities

"Socha-753"



Resident is a very dangerous virus, it typically infects .COM files when they are opened. When launching files (except ME $ .OVL and NCMAIN.EXE), the command line is added to the file C: \ M_EDIT \ ME $ .OVL. It is propagated if the system timer indicates 1981. Intercepts int 21h, contains the strings: “Socha”, “C: \ m_edit \ me $ .ovl”, “comCOM”.



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



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.