As long as people can be tricked, there will always be phishing (or social engineering) on some level or another, but there’s a lot more that we can do with technology to reduce the effectiveness of phishing, and the number of people falling victim to common theft. Making phishing less effective ultimately increases the cost to the criminal, and reduces the total payoff. Few will argue that our existing authentication technologies are stuck in a time warp, with some websites still using standards that date back to the 1990s. Browser design hasn’t changed very much since the Netscape days either, so it’s no wonder many people are so easily fooled by website counterfeits.
You may have heard of a term called the line of death. This is used to describe the separation between the trusted components of a web browser (such as the address bar and toolbars) and the untrusted components of a browser, namely the browser window. Phishing is easy because this is a farce. We allow untrusted elements in the trusted windows (such as a favicon, which can display a fake lock icon), tolerate financial institutions that teach users to accept any variation of their domain, and use a tiny monochrome font that can make URLs easily mistakable, even if users were paying attention to them. Worse even, it’s the untrusted space that we’re telling users to conduct the trusted operations of authentication and credit card transactions – the untrusted website portion of the web browser!.
Our browsers are so awful today that the very best advice we can offer everyday people is to try and memorize all the domains their bank uses, and get a pair of glasses to look at the address bar. We’re teaching users to perform trusted transactions in a piece of software that has no clear demarcation of trust.
The authentication systems we use these days were designed to be able to conduct secure transactions with anyone online, not knowing who they are, but most users today know exactly who they’re doing business with; they do business with the same organizations over and over; yet to the average user, a URL or an SSL certificate with a slightly different name or fingerprint means nothing. The average user relies on the one thing we have no control over: What the content looks like.
My inbox has been lighting up with questions about Confide, after it was allegedly found to have been used by staffers at the White House. I wish I had all of the free time that reporters think I have (I’d be so happy, living life as a broke beach bum). I did spend a little bit of time, however reverse engineering the binary and doing a simple forensic examination of it. Here’s my “literature in a rush” version.
Note: When I first wrote this blog post, I apparently had run into some corruption or some other strangeness going on with the framework; I suspect one of the tools I normally use might have decrypted it for me, and done a shoddy job without even telling me, so I have decrypted it by hand dumping memory from a debugger, and have updated my findings accordingly.
With the current US administration pondering the possibility of forcing foreign travelers to give up their social media passwords at the border, a lot of recent and justifiable concern has been raised about data privacy. The first mistake you could make is presuming that such a policy won’t affect US citizens. For decades, JTTFs (Joint Terrorism Task Forces) have engaged in intelligence sharing around the world, allowing foreign governments to spy on you on behalf of your home country, passing that information along through various databases. What few protections citizens have in their home countries end at the border, and when an ally spies on you, that data is usually fair game to share back to your home country. Think of it as a backdoor built into your constitutional rights. To underscore the significance of this, consider that the president signed an executive order just today stepping up efforts at fighting international crime, which will likely result in the strengthening of resources to a JTTFs to expand this practice of “spying on my brother’s brother for him”. With this, the president also counted the most common crimes – drugs, gangs, racketeering, etc – as matters of “national security”.
Once policies that require surrendering passwords (I’ll call them password policies from now on) are adopted, the obvious intelligence benefit will no doubt inspire other countries to establish reciprocity in order to leverage receiving better intelligence about their own citizens traveling abroad. It’s likely the US will inspire many countries, including oppressive nations, to institute the same password policies at the border. This will ultimately be used to skirt search and seizure laws by opening up your data to forensic collection. In other words, you don’t need Microsoft to service a warrant, nor will the soil your data sits on matter, because it will be a border agent connecting directly your account with special software throug the front door.
I am not a lawyer, and I can’t provide you with legal advice about your rights, or what you can do at a border crossing to protect yourself legally, but I can explain the technical implications of this, as well as provide some steps you can take to protect your data regardless of what country you’re entering. Disclaimer: You accept full responsibility and liability for taking any of this information and using it.
Here are the slides from my talk at Dartmouth College this week; this was a basic introduction / overview of the macOS kernel and how root kits often have fun with the kernel. There’s not much new here, but the deck might be a good introduction for anyone looking to get into develop security tools or conduct security research in macOS. Note: Root kits aren’t exploits; there’s no exploit code in this deck. Sorry!
Last week, I live tweeted some reverse engineering of the Meitu iOS app, after it got a lot of attention on Android for some awful things, like scraping the IMEI of the phone. To summarize my own findings, the iOS version of Meitu is, in my opinion, one of thousands of types of crapware that you’ll find on any mobile platform, but does not appear to be malicious. In this context, I looked for exfiltration or destruction of personal data to be a key indicator of malicious behavior, as well as performing any kind of unauthorized code execution on the device or performing nefarious tasks… but Meitu does not appear to go beyond basic advertiser tracking. The application comes with several ad trackers and data mining packages compiled into it – which appear to be primarily responsible for the app’s suspicious behavior. While it’s unusually overloaded with tracking software, it also doesn’t seem to be performing any kind of exfiltration of personal data, with some possible exceptions to location tracking. One of the reasons the iOS app is likely less disgusting than the Android app is because it can’t get away with most of that kind of behavior on the iOS platform.
The new Touch Bar is often marketed as a gimmick, but one powerful capability it has is to function as a lockdown mechanism for your machine in the event of a physical breach. By changing a few power management settings and customizing the Touch Bar, you can add a button that will instantly lock the machine’s screen and then begin a countdown (that’s configurable, e.g. 5 minutes) to lock down the entire system, which will disable the fingerprint reader, remove power to the RAM, and discard your FileVault keys, effectively locking the encryption, protecting you from cold boot attacks, and prevent the system from being unlocked by a fingerprint.
One of the reasons you may want to do this is to allow the system to remain live while you step away, answer the door, or run to the bathroom, but in the event that you don’t come back within a few minutes, lock things down. It can be ideal for the office, hotels, or anywhere you feel that you feel your system may become physically compromised. This technique offers the convenience of being able to unlock the system with your fingerprint if you come back quickly, but the safety of having the system secure itself if you don’t.
A clear technical definition of the term backdoor has never reached wide consensus in the computing community. In this paper, I present a three-prong test to determine if a mechanism is a backdoor: “intent”, “consent”, and “access”; all three tests must be satisfied in order for a mechanism to meet the definition of a backdoor. This three-prong test may be applied to software, firmware, and even hardware mechanisms in any computing environment that establish a security boundary, either explicitly or implicitly. These tests, as I will explain, take more complex issues such as disclosure and authorization into account.
The technical definition I present is rigid enough to identify the taxonomy that backdoors share in common, but is also flexible enough to allow for valid arguments and discussion.
Social media is ripe with analysis of an FBI joint report on Russian malicious cyber activity, and whether or not it provides sufficient evidence to tie Russia to election hacking. What most people are missing is that the JAR was not intended as a presentation of evidence, but rather a statement about the Russian compromises, followed by a detailed scavenger hunt for administrators to identify the possibility of a compromise on their systems. The data included indicators of compromise, not the evidentiary artifacts that tie Russia to the DNC hack.
One thing that’s been made clear by recent statements by James Clapper and Admiral Rogers is that they don’t know how deep inside American computing infrastructure Russia has been able to get a foothold. Rogers cited his biggest fear as the possibility of Russian interference by injection of false data into existing computer systems. Imagine the financial systems that drive the stock market, criminal databases, driver’s license databases, and other infrastructure being subject to malicious records injection (or deletion) by a nation state. The FBI is clearly scared that Russia has penetrated more systems than we know about, and has put out pages of information to help admins go on the equivalent of a bug bounty.
Apple has been fighting for a secure iPhone since 2007, when the first jailbreaks came out about two weeks after the phone was released. Since then, they’ve gotten quite good at keeping the jailbreak community on the defensive side of this cat and mouse game, and hardened their OS to an impressive degree. Nonetheless, as we see every release, there are still vulnerabilities and tomhackery to be had. Among the most notable recent exploits, iOS 9 was patched for a WebKit memory corruption vulnerability that was used to deploy the Trident / Pegasus surveillance kit on selected nation state targets, and Google Project Zero recently announced plans to release a jailbreak for iOS 10.1 after submitting an impressive number of critical vulnerabilities to Apple (props to Ian Beer, who should be promoted to wizard).
I’ve been thinking about ways to harden iOS against jailbreaks, and came up with three recommendations that would up the game considerably for attackers. Two of them involve leveraging the Secure Enclave, and one is an OS hardening technique.
Security is about increasing the cost and time it takes to penetrate a target. These recommendations are designed to do just that: They’d greatly frustrate and upset current ongoing jailbreak and malware efforts.
I wasn’t originally going to dig into some of the ugly details about San Bernardino, but with FBI Director Comey’s latest actions to publicly embarrass Hillary Clinton (who I don’t support), or to possibly tip the election towards Donald Trump (who I also don’t support), I am getting to learn more about James Comey and from what I’ve learned, a pattern of pushing a private agenda seems to be emerging. This is relevant because the San Bernardino iPhone matter saw numerous accusations of pushing a private agenda by Comey as well; that it was a power grab for the bureau and an attempt to get a court precedent to force private business to backdoor encryption, while lying to the public and possibly misleading the courts under the guise of terrorism.
Sorry, folks, while experts are saying the encryption checks out in WhatsApp, it looks like the latest version of the app tested leaves forensic trace of all of your chats, even after you’ve deleted, cleared, or archived them… even if you “Clear All Chats”. In fact, the only way to get rid of them appears to be to delete the app entirely.
To test, I installed the app and started a few different threads. I then archived some, cleared, some, and deleted some threads. I made a second backup after running the “Clear All Chats” function in WhatsApp. None of these deletion or archival options made any difference in how deleted records were preserved. In all cases, the deleted SQLite records remained intact in the database.
Just to be clear, WhatsApp is deleting the record (they don’t appear to be trying to intentionally preserve data), however the record itself is not being purged or erased from the database, leaving a forensic artifact that can be recovered and reconstructed back into its original form.
Apple has long enjoyed a security architecture whose security, in part, rests on the entanglement of their encryption to a device’s physical hardware. This pairing has demonstrated to be highly effective at thwarting a number of different types of attacks, allowing for mobile payments processing, secure encryption, and a host of other secure services running on an iPhone. One security feature that iOS lacks for third party developers is the ability to validate the hardware a user is on, preventing third party applications from taking advantage of such a great mechanism. APIs can be easily spoofed, as a result, and sessions and services are often susceptible to a number of different forms of abuse. Hardware validation can be particularly important when dealing with crowd-sourced data and APIs, as was the case a couple years ago when a group of students hacked Waze’s traffic intelligence. These types of Sybil attacks allow for thousands of phantom users to be created off of one single instance of an application, or even spoof an API altogether without a connection to the hardware. Other types of MiTM attacks are also a threat to applications running under iOS, for example by stealing session keys or OAuth tokens to access a user’s account from a different device or API. What can Apple do to thwart these types of attacks? Hardware entanglement through the Secure Enclave.
To the Honorable Congress of the United States of America,
I am a proud American who has had the pleasure of working with the law enforcement community for the past eight years. As an independent researcher, I have assisted on numerous local, state, and federal cases and trained many of our federal and military agencies in digital forensics (including breaking numerous encryption implementations). Early on, there was a time when my skill set was exclusively unique, and I provided assistance at no charge to many agencies flying agents out to my small town for help, or meeting with detectives while on vacation. I have developed an enormous respect for the people keeping our country safe, and continue to help anyone who asks in any way that I can.
With that said, I have seen a dramatic shift in the core competency of law enforcement over the past several years. While there are many incredibly bright detectives and agents working to protect us, I have also seen an uncomfortable number who have regressed to a state of “push button forensics”, often referred to in law enforcement circles as “push and drool forensics”; that is, rather than using the skills they were trained with to investigate and solve cases, many have developed an unhealthy dependence on forensics tools, which have the ability to produce the “smoking gun” for them, literally with the touch of a button. As a result, I have seen many open-and-shut cases that have had only the most abbreviated of investigations, where much of the evidence was largely ignored for the sake of these “smoking guns” – including much of the evidence on the mobile device, which often times conflicted with the core evidence used.
The Burr Encryption Bill – Discussion Draft dropped last night, and proposes legislation to weaken encryption standards for all United States citizens and corporations. The bill itself is a hodgepodge of technical ineptitude combined with pockets of contradiction. I would cite the most dangerous parts of the bill, but the bill in its entirety is dangerous, not just for its intended uses but also for all of the uses that aren’t immediately apparent to the public.
The bill, in short, requires that anyone who develops features or methods to encrypt data must also decrypt the data under a court order. This applies not only to large companies like Apple, but could be used to punish developers of open source encryption tools, or even encryption experts who invent new methods of encryption. Its broad wording allows the government to hold virtually anyone responsible for what a user might do with encryption. A good parallel to this would be holding a vehicle manufacturer responsible for a customer that drives into a crowd. Only it’s much worse: The proposed legislation would allow the tiremanufacturer, as well as the scientists who invented the tires, to be held liable as well.
Sir, you may not know me, but I’ve impacted your agency for the better. For several years, I have been assisting law enforcement as a private citizen, including the Federal Bureau of Investigation, since the advent of the iPhone. I designed the original forensics tools and methods that were used to access content on iPhones, which were eventually validated by NIST/NIJ and ingested by FBI for internal use into your own version of my tools. Prior to that, FBI issued a major deviation allowing my tools to be used without validation, due to the critical need to collect evidence on iPhones. They were later the foundation for virtually every commercial forensics tool to make it to market at the time. I’ve supported thousands of agencies worldwide for several years, trained our state, federal, and military in iOS forensics, assisted hands-on in numerous high-profile cases, and invested thousands of hours of continued research and development for a suite of tools I provided at no cost – for the purpose of helping to solve crimes. I’ve received letters from a former lab director at FBI’s RCFL, DOJ, NASA OIG, and other agencies citing numerous cases that my tools have been used to help solve. I’ve done what I can to serve my country, and asked for little in return.
First let me say that I am glad FBI has found a way to get into Syed Farook’s iPhone 5c. Having assisted with many cases, I understand from firsthand experience what you are up against, and have enormous respect for what your agency does, as well as others like it. Often times it is that one finger that stops the entire dam from breaking. I would have been glad to assist your agency with this device, and even reached out to my contacts at FBI with a method I’ve since demonstrated in a proof-of-concept. Unfortunately, in spite of my past assistance, FBI lawyers prevented any meetings from occurring. But nonetheless, I am glad someone has been able to reach you with a viable solution.
An adversary has an unknown exploit, and it could be used on a large scale to attack your platform. Your threat isn’t just your adversary, but also anyone who developed or sold the exploit to the adversary. The entire chain of information from conception to final product could be compromised anywhere along the way, and sold to a nation state on the side, blackmailed or bribed out of someone, or just used maliciously by anyone with knowledge or access. How can Apple make this problem go away?
The easiest technical solution is a boot password. The trusted boot chain has been impressively solid for the past several years, since Apple minimized its attack surface after the 24kpwn exploit in the early days. Apple’s trusted boot chain consists of a multi-stage boot loader, with each phase of boot checking the integrity of the next. Having been stripped down, it is now a shell of the hacker’s smorgasbord it used to be. It’s also a very direct and visible execution path for Apple, and so if there ever is an alleged exploit of it, it will be much easier to audit the code and pin down points of vulnerability.
A number of people have been asking me my thoughts on the viability of a software exploit against Secure Enclave enabled devices, so here’s my opinion:
First, is interesting to note that the way the FBI categorizes this tool’s capabilities is “5c” and “9.0”; namely, hardware model and firmware version. They won’t confirm that it’s the only combination that the tool runs on, but have noted that these are the two factors they’re categorizing it by. This is consistent with how exploit-based forensics tools have functioned in the past. My own forensics tools (for older iPhones) came in different modules that were tailored for a specific hardware platform and firmware version. This is because most exploits require taking Apple’s own firmware and patching it; those patches require slightly different offsets in the kernel (and possibly boot loader). The software to patch is also going to be slightly different for each hardware and firmware combination. So without saying really anything, FBI has kind of hinted that this might be a software exploit. Had this been a hardware attack, such as a NAND mirroring technique, firmware version likely wouldn’t be a point of discussion, as the technique’s feasibility is dependent on hardware revision. This is all conjecture, of course, but is worth noting that the hints are already there.
If the FBI did in fact use a software exploit, the question then becomes one of how viable it is on other platforms. Typically, a software exploit of this magnitude could very well take advantage of vulnerabilities that have long existed in the firmware, making it more than likely that the exploit may also be effective (possibly with a little tailoring) to older versions of iOS. Even if the exploit today was tailored specifically for this device, adjusting offsets and patching slightly different copies of Apple’s firmware is a relatively painless process. A number of open source tools even exist to find and patch the correct bytes in decrypted Apple kernels.
As expected, the FBI has succeeded in finding a method to recover the data on the San Bernardino iPhone, and now the government can see all of the cat pictures Farook was keeping on it. We don’t know what method was used, as it’s been classified. Given the time frame and the details of the case, it’s possible it could have been the hardware method (NAND mirroring) or a software method (exploitation). Many have speculated on both sides, but your guess is as good as mine. What I can tell you are the implications.
This is a simple “concept” demonstration / simulation of a NAND mirroring attack on an iOS 9.0 device. I wanted to demonstrate how copying back disk content could allow for unlimited passcode attempts. Here, instead of using a chip programmer to copy certain contents of the NAND, I demonstrate it by copying the data using a jailbreak. For Farook’s phone, the FBI would remove the NAND chip, copy the contents into an image file, try passcodes, and then copy the original content back over onto the chip.
I did this here, only with a jailbreak: I made a copy of two property lists stored on the device, then copied them back and rebooted after five attempts. When doing this on a NAND level, actual blocks of encrypted disk content would be copied back and forth, whereas I’m working with files here. The concept is the same, and serves only to demonstrate that unlimited passcode attempts can be achieved by back-copying disk content. Again, NO JAILBREAK IS NEEDED to do this to Farook’s device, as the FBI would be physically removing the NAND to copy this data.
Other techniques can be used to speed this up. For example, the clock could possibly be fudged by giving the device a data connection and rerouting time requests to a local server. Think IMSI catcher. This could be used to continuously bump the time five or ten minutes so that more passcode attempts could be tried per reboot without as many delays. The NAND chip could also be socketed or reworked in other ways to make switches seamless. Lastly, the same techniques used in IP BOX such as entering pins through the usb, and using a light sensor to detect an unlock, could help to automate this to be more efficient. Overall, I think this puts to bed any notion that the technique “doesn’t work”.
As I sit here, trying to be the good parent in reviewing my daughter’s text messages, I have to assume that I’ve made my kids miserable by having a father with DFIR skills. I’m able to dump her device wirelessly using a pairing record and a tool I designed to talk to the phone. I generate a wireless desktop backup, decrypt it, and this somehow makes my kids safer. What bothers me, as a parent, is the incredible trove of forensic artifacts that I find in my children’s data every month. Deleted messages, geolocation information, even drafts and thumbnails that had all been deleted months ago. Thousands of messages sometimes. In 2008, I wrote a small book with O’Reilly named iPhone Forensics that detailed this forensic mess. Apple has made some improvements, but the overall situation has gotten worse since then. The biggest reason the iPhone is so heavily targeted for forensics and intelligence is because of the very wide data recovery surface it provides: it’s a forensics gold mine.
To Apple’s credit, they’ve done a stellar job of improving the security of iOS devices in general (e.g. the “front door”), but we know that they, just like every other manufacturer, is still dancing on the lip of the volcano. Aside from the risk of my device being hacked, there’s a much greater issue at work here. Whether it’s a search warrant, an unlawful traffic stop in Michigan, someone stealing my backups, an ex-lover, or just leaving my phone unlocked on accident at my desk, it only takes a single violation of the user’s privacy to obtain an entire lengthy history of private information that was thought deleted. This problem is also prevalent in desktop OS X.