February 20, 2016 at 16:53Security Week 07: Apple vs. FBI, global glibc vulnerability, crypto-lockers and medicine
The week with an extra working day was saturated and balanced. The events surrounding the dispute between Apple and US government agencies represented by the FBI and the Justice Ministry continue to develop, but it is now clear that they will seriously affect the development of the security industry in terms of protecting personal information. Unlike this purely political story, the critical vulnerability in the glibc library is completely technical news, but, directly or indirectly, also affects everyone. I want to say that this week a debate has intensified over the opportunity to influence the development of technologies: between, so to speak, techies and
However, this is only a hypothesis. It is possible that while we are all actively discussing hacking encrypted data, someone somewhere digs another critical hole in another glibc, and when he digs up, everything else on the topic of security will become generally irrelevant. We consider both cases in more detail. All digest editions are available by tag .
Apple v. FBI: Case of Blocked iPhone, Terrorism, and 1789 Law.
The news .
On December 2, 2015, a terrorist attack occurred in San Bernardino, California. An American citizen of Pakistani descent, along with an accomplice, shot his colleagues from the district health department. The attackers managed to escape, but they were blocked three kilometers from the crime scene. In the ensuing shootout, the criminals were shot dead. During the investigation, the phone of the offender was discovered: Apple iPhone 5c, a corporate smartphone officially owned by the employer. Presumably, Apple, at the request of government agencies, provided a backup copy of data from the phone from the cloud service with iCloud. But there was an outdated copy of the data in the cloud dated October 19, after which, again, presumably, the owner of the phone turned off the backup function.
The FBI's intention to get absolutely all the data from the smartphone was expressed in a court order for Apple (the source laid out EFF), which pretty clearly spelled out what the company should do to help the investigation. Namely: (1) to disable the function that destroys data on the phone after ten incorrect attempts to enter the passcode (2) to provide the ability to enter the passcode electronically (3) to disable the delay between attempts to enter.
In other words, the FBI wants to pick up a passcode by brute force, and requires Apple to circumvent all the built-in restrictions that make the selection impossible. The Intercept notes that the success of this scenario depends on the length of the password: it takes seconds for a four-digit pincode, seven days for a seven-digit pincode, and 25 years for a ten-digit one. But this is if Apple obeys, but so far the company does not want to do this. In an appeal to the CEO of Apple, Tim Cook said that the company transferred to the state authorities all the data that it had that could help the investigation. And he rightly called the “busting plan” a backdoor: “The US government has asked us to give what we simply don’t have and to do what we consider too dangerous.”
The facts ended there, then a heated discussion began. But we are dealing with a political issue, which has a very distant relation to technology, and a possible victory or loss for Apple is likely to result from negotiations, influenced by public opinion, arguments of lawyers in court, statements by interested parties in the media, and so on. Putting together the main (today) results of such a “discussion” is easiest in the format of questions and answers.
What is the rationale for Apple's requirements in terms of US law?
Very interesting question, thanks. The requirement is based on Act 1789of the year known as the All Writs Act. It is part of the law, which actually created the entire judicial system of the United States, after the signing of George Washington, the first president of the country. In general, this happened back in those days when California, where Apple’s headquarters will be located more than two hundred years later and the terrorist attack takes place, together with Mexico was a colony of Spain, and was not part of the United States. To simplify everything, the act left a loophole for the imperfect legislative system of the young American state: it gave the courts the freedom to make the necessary decisions, not referring to laws already adopted.
In a detailed review of the legislative part of this story, Gizmodo citesjudicial practice with the application of this act. Now, when there are no problems with the legislation, the All Writs Act is not used often, but regularly. For example, in 1977, a telecommunications company was ordered to help track down the negotiations of a criminal gang engaged in racketeering. That is, it turns out that the ancient law is applied because the rules for hacking smartphones are not spelled out anywhere else. If the US Congress did not bother to put such a practice in order, then the court has to use these shortcuts. Gizmodo’s material also cites a rare case when a judge refused to apply this act, asking a fair question (though in a different case and in another matter): there is no legislative base because Congress did not have time to create it, or because it did not want to?
Why is the FBI asking Apple to crack the iPhone instead of doing it on its own?
Obviously, because the feds themselves cannot do this. The whole situation suggests that the information protection methods introduced by Apple work. There is another nuance that surfaced just yesterday. Apple organizeda conference call with reporters, on some unprecedented conditions. Representatives of the company shared their vision of the problem, while journalists were forbidden to quote them verbatim! Moreover, even the names of company representatives were not disclosed. According to anonymous Apple employees, the FBI shot herself in the foot, accidentally resetting the password for the iCloud account to which the smartphone was attached. If this did not happen, the phone, if it was turned on but still locked, would synchronize itself with iCloud, from where the data, presumably, could be obtained using the company. After the reset, this opportunity was missed: the password on the phone is incorrect, and which one is correct , no one knows and cannot find out.
What are the positions of the parties?
Apple announced its position on February 16: the proposed solution is equivalent to creating a backdoor, this puts all our customers at risk, we do not want to do this. Moreover, the statement was made in a public field. Representatives of the state responded on February 19, and not publicly, but in the form of a statement to the court in this case. According to representatives of the Department of Justice, Apple has the technical ability to implement a password brute force system, but does not want to obey, giving preference not to the Law, but to a “marketing strategy”. “Not willing to obey” in this case may have direct legal consequences in court, and it sounds like a threat.
Can Apple get around the security system?
Unknown Tim Cook’s statement does not contain a clear answer to this question: “it is dangerous”, “they ask for what we don’t have,” and so on. It is clear that Apple, as a developer of both software and hardware for iPhones, can do a lot. The main question is: will the company obey?
According to opponents of Apple, there is no particular danger. The court statement expressly states that the company can tie this dirty hack to a single phone, moreover, it is not obliged to transfer software made for password guessing to the state. On the other hand, even the knowledge that Apple was able to implement such a scenario could theoretically enable the state or attackers to create their own backdoor. Naturally, the perception of the security of Apple smartphones will suffer if the company obeys. Everyone will know that, in which case, the state will get to your data.
So the story is really important. It takes place against the backdrop of a general discussion about where the balance is between the protection of personal data and the interests of the state, including in the investigation of crimes, acts of terror and so on. Here is a piece of news from December last year: the FBI (and not only) claims that backdoors to encryption systems are normal if access to them is available only to specially trained people by court order. Data protection specialists, of course, do not agree: anyone can use backdoors. The dispute between Apple and the FBI in this context becomes a case in point: its outcome can seriously affect the security of the devices that we all use. We stock up on popcorn.
Losing Apple will not mean that strong cryptography will be unavailable or prohibited. It will simply become less common, and in the further development of data protection technologies, companies such as Apple, Google, Facebook, Twitter (the last three supported Apple in the dispute) will play a lesser role. And they, of course, would like to avoid this.
Cherry on a cake: John McAfee volunteered to crack an iPhone for free, in three weeks, using "predominantly social engineering methods." The Internet is wondering how exactly McAfee is going to apply social engineering methods to the owner of the phone, shot dead three months ago.
Critical vulnerability found in glibc
News .
A critical vulnerability has been discovered in the GNU C Library (glibc) that affects all versions since 2.9, which was released in 2008. The getaddrinfo () function was responsible for the query to the DNS server. The problem is that an arbitrary code can be added to the response from the server, and, after causing a buffer overflow, execute it on the victim's system. Vulnerability discoveredresearchers at Google, and by chance - their attention was attracted by the constant crash of the SSH client with a segmentation fault when accessing a specific server. That is, in order to conduct an attack using this vulnerability, you need to configure the DNS server in a certain way and somehow make the victim make a request. This is not so difficult, and can be implemented, for example, in the course of a man-in-the-middle attack, when instead of a legitimate DNS server, the query path turns out to be false.
As for how easy it is to run arbitrary code, opinions differ. Security technologies such as ASLR can interfere with this, but it is not at all necessary that they work on all devices - for example, in routers with a traditionally minimalistic linux environment, all the necessary protections may not be available. In the detailed description A vulnerability made by Red Hat employees indicated that realistic scripts for running arbitrary code exist.
The severity of the vulnerability lies in the fact that glibc is used everywhere. I can’t help but cite this tweet as an illustration :
The library of standard functions is a dependency for a huge number of programs and packages for Linux. Accordingly, it is difficult to properly assess which programs and how are affected by this vulnerability. For example, Android (the system itself) is not affected, since instead of glibc it uses the Bionic alternative developed by Google. This does not mean that all native Android applications are not affected. Previous serious glibc vulnerability known as GHOST, caused the same questions, although there were fewer opportunities for real remote operation. Result: a lot of problems for developers and administrators of a huge amount of software and hardware. It is noteworthy that researchers at Google and Red Hat discovered the bug independently of each other. Moreover, it turned out that glibc maintainers learned about the problem back in July 2015. It is not clear why the problem has not been closed for so long, and how it turned out that the vulnerability appeared. But unlike the history of Apple, there is nothing to discuss here, first of all, you need to roll patches. Many patches in the most unexpected places in software and hardware.
Hollywood Hospital paid a ransom after an attack by a cryptoclocker
News .
Well, for starters, a story from the world of ordinary malware. The industry of cryptographic Trojans, alas, brings millions of losses, but ordinary users become a typical victim of such a cyber divorce. Everything is much more complicated when companies are attacked. In this case, the victim was a hospital in Hollywood (the same one). Apparently, the attackers were able to encrypt all or almost all of the data, after which they demanded a record ransom from the hospital management - three million dollars (more precisely 3.4 million or 9000 bitcoins). Or they didn’t demand it - the messages from the places are contradictory, and the official statement of the organization refutes the fact of requesting such a huge amount.
Nevertheless, the scammers received a ransom, although a smaller one - 17 thousand dollars. The hospital said that this was the only way to quickly restore the hospital’s IT systems. Sadly, it is clear that, first of all, an attack by cryptographers should be avoided. And if it happens, make sure that the damage will be limited to data on one system (and not on all network folders at once). The news attracted much attention because of the specifics of the organization that came under attack - no one wants to leak the most sensitive data about their health. Hospital computer networks, meanwhile, remain vulnerable not only and not so much to ordinary Trojans. Security Analyst Summit talked about this at a conference.our expert Sergey Lozhkin: with fairly simple tools, he was able to detect vulnerable specialized software available from the Internet, such as, for example, software for MRI.
Antiquities:“Typo-Boot”
A dangerous virus, the “Brain” method infects the boot sectors of the hard drive and floppy disks when reading from them. The disk is located in the standard way. It works only on IBM PC / XT computers, as it contains the command 'MOV CS, AX' (inter-segment JMP), which is executed only by the 8086 processor. It hooks int 13h, 17h. Replaces characters that are displayed on the printer.
Quote from the book "Computer viruses in MS-DOS" by Eugene Kaspersky. 1992 year. Page 103.
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.