Moderator's introduction
So, actually this ninth conference has turned out, actually, a bit strange for us. Because, as you may have noticed, through pretty much the whole talks section we, basically, this year, didn't mention Apple devices much. Maybe that happened because at the last conference my colleague said they're impregnable. Maybe for some other reasons, but back to their impregnability, and we'll bust that myth right now. Please welcome Andrey Shavlovsky, Investigative Committee. Let's support him with applause and talk specifically about Apple and macOS. Andrey, the microphone and the clicker.
Talk and Q&A
Good afternoon, dear colleagues. I'd like to thank the organizers for the opportunity to speak at this conference. My name is Andrey Shavlovsky, I'm a digital forensics specialist, I've been doing computer forensic examinations for 8 years now, digital forensics. And in this talk I'd like to cover some issues related to the method of dynamic examination, memory analysis on personal computers running Apple macOS. The topic is quite relevant. Actually, I've touched on some of the issues related to it. You could actually talk about this for quite a long time. But overall we'll talk, well, basically digital forensics has well-known, generally accepted approaches that don't need extra interpretation to be discussed in detail.
That is, the object is examined, the integrity and immutability of the data it contains is ensured, an exact sector-by-sector copy is created, then the data it contains is analyzed, the data is interpreted, and the results obtained are saved. That is, overall there are plenty of methodological guidelines on this. Overall this is, roughly speaking, the basic static analysis that is performed on disk images, on electronic storage media.
Overall, the previous speakers described dynamic analysis in detail, and static analysis. Overall it's clear that static analysis is the examination of information on a computer system or storage medium that isn't running, when it isn't launched for execution but is examined as is. And dynamic analysis is when a running object is examined, when it's launched for execution. That is, there are some indicators of malicious behavior and others. Overall, static analysis is the gold standard of digital forensics. Most examinations, of course, are done precisely by static analysis, because as a rule you can ensure integrity and immutability of the information, there's repeatability, there's the possibility of repeating the examination.
The results, accordingly, are reproducible and repeatable. But there are also problems, when some data may be missed from protected memory areas. So, for example, overall, dynamic examination methods are applied to the Microsoft Windows operating system, when the user's password hash is pulled out of the registry files, it's cracked, that is, it has fairly weak cryptographic strength, and then an exact copy is either virtualized or examined by other means. Data is extracted from browsers, authentication tokens and other data that may have forensic value.
So what about macOS? Overall, what's known about macOS is that it's a proprietary operating system with its own proprietary file system.
It has a very important built-in mechanism for storing keys and passwords, the Keychain, access to which is possible only after authentication with a password or biometrics. An analogue of Windows DPAPI.
The directory structure is different, somewhat similar to Linux and to Windows. Overall, the file structure has a system level, a user level, an application level, and a level where temporary and cache files are stored.
By analogy with Windows, when a user is registered a home directory is created, conventionally called the user's home directory, whose name matches the user name. By default it's located at paths similar to Windows, but it can, for example, be moved to external storage as well.
Data, application settings, configuration files, configuration data, accounts, activity logs in macOS are stored in plists. So that's no secret. But plist files come in different formats.
The main formats are XML, a text format with tags and indentation. It's used, accordingly, for editing and debugging. And the more popular format is binary. This is, essentially, a machine-oriented format. It's not readable without special conversion.
There's also the JSON format, but it's used less often. So, if you open in text editors a binary plist file and a text one, the XML format, then it's clear you need to convert from the binary format to XML. Why aren't all plist files in XML format? Well, there are two main reasons. It's, of course, that the binary data format is more compact, smaller in size than XML, doesn't require indentation, tags, like XML does. And the processing speed of binary plists is much higher than XML, so by default plist files are used precisely in the binary format.
So, if we move on to the question of obtaining the user's password, that is, where its hash is stored, then in general the user account data is stored in one of the system directories, namely the dslocal directory.
[music]
So, when a user account is registered, a separate file is created for each registered user, whose name matches the username. This file is in binary format, and accordingly, to view it, you need to convert it to XML format. Accordingly, we're interested in the ShadowHashData data section.
Once access to the file is secured, and the conversion from binary to XML is performed, you can actually work with the data we see. To convert from binary to XML format, you can use various commands. For example, the plutil command, a utility built into macOS, in the bash terminal, which you can use. You can use special software, text editors with plugins.
After the conversion is done, ShadowHashData stores the data, that is, it's encoded in Base64. It also needs to be converted.
Also, in principle, these are accessible methods. There are many online decoders, there are software tools that perform decoding. This can also be done in the terminal. And as a result of decoding we obtain information about the password hash. Accordingly, we see that it's encoded using the PBKDF2-SHA512 hash function. This is a cryptographic algorithm, that uses the PBKDF2 function in combination with the SHA-512 function. So, a cryptographically strong algorithm. And the data is divided into several, roughly speaking, values. The first is the entropy. This is the hash function's final result. Stored in hexadecimal form.
Iterations. This is the set number of iterations. how many times the function, the hash function, is executed. And the salt is a unique sequence of bytes, which is added to the user's passwords in order to then perform the hashing.
What's the distinctive feature compared to, for example, Windows? Windows uses the NT hash, which is stored in registry files. Accordingly, it's used without salt and without iterations.
And besides that, the NT hash is computed with the MD4 hash function, a fairly outdated one, its cryptographic strength is very low, so, the password brute force speed for NT hashes is very high compared to Macs. The salt prevents, for example, the use of rainbow tables. That is, for example, if two different users have the same password in macOS, then the hashes of these passwords differ, because the salt is always unique, unlike in Windows. That is, for example, any leaks that are used to guess passwords, rainbow tables, they're very often used to guess passwords for Microsoft Windows accounts.
Accordingly, the passwords, the hashes stored in macOS, are more cryptographically strong. And the brute force takes longer.
Also specifically in hexadecimal form. And the final result, of course, is the entropy. That is, after performing the required number of operations, this entropy should come out. If it matches, then the password fits.
We've covered the step-by-step extraction and conversion of the password hash and preparing it for further brute forcing. So what tools can you use to automate this process? You can use special scripts, which are fed the corresponding plist file as input with the ShadowHashData, that is, specifically for this user account. or, accordingly, get as a result a format, a representation in a format that you can then brute force in hashcat. In principle, for the format we can also use software tools. In Mobile Criminalist Expert I didn't find that it can convert the password hash data for a macOS user, but maybe they've fixed it by now.
I used other software tools that are available, but overall I ran into a problem — we won't name this software tool, but I ran into a problem where the software tool in question converts the data, but displays it incompletely. That is, part of the hash is lost, it's missing. Accordingly, it's not possible to brute force such a hash. In general this situation clearly shows that automated software tools don't always give an absolute result. You have to be able to double-check this data.
So, the data is obtained, hashcat is launched, it's passed the corresponding file that contains our password hash. It's given the information about which hashing algorithm to run this brute force with. In this case it's 7100.
In the instructions for hashcat, all this information is available, it's publicly accessible. And overall the guessing is done either by mask or by dictionary.
And you can get a result, if, of course, you manage to gain access. Not everyone likes working in console programs. You can also use graphical interfaces. There are programs built on hashcat with graphical interfaces. One of them is MK Brute Force. An excellent program, it's developing, a lot is being added. Unfortunately, at the moment it doesn't support the 7100 password guessing mode. And to test it for guessing the password of a user hash in macOS wasn't possible. But let's hope that later there will be updates and such a capability appears. For this, other tools were used that are also built on hashcat and can perform user password guessing.
Accordingly, our file is passed as the input parameters, which contains the password hash. The user selects the required mode. So, the mask, or the dictionary, to run the brute force by. And, accordingly, you can already clearly see the guessing speed, the graphics card temperature, and so on. Of course it's best to brute force not on a single graphics card, but to have a GPU cluster overall. In principle, here you need to use more advanced methods too, in the sense that simple brute force is fairly long, labor-intensive, and the time can run into years, which nobody needs, so, of course, one compiles, well, basically, you need to build custom dictionaries, Based on data from notebooks, data from digital devices, I can recommend the web resource wikpass.com, it contains many custom dictionaries that can also be used for brute forcing.
In the end the password is established, and then you can move on directly to the examination itself. The two main methods are: one where the object is virtualized, that is, its virtual environment is set up on a previously taken exact copy.
If, of course, creating a virtual environment, a virtual copy of the object, was not possible, then, at least, the law permits examining the object with changes made to it. But at the same time, clearly, if we're talking about a forensic examination, then prior permission must be obtained from the initiator of the examination to make such changes. Because there's Article 57, which tells us that a forensic expert is not entitled to use examination methods, that could cause the full or partial destruction of the object, or a change in its main properties and appearance.
Accordingly, having the user's password, you can decrypt data from the keychain, pull out authentication tokens, pull out passwords, that is, obtain far more data than, for example, without the password. And accordingly, in some cases we can directly examine the information content itself, as the user sees it. We can look at, for example, messengers, desktop ones installed in the operating system, and that may not be parsed by static analysis, but that can be extracted dynamically, including with the help of the same Mobile Criminalist Scout.
It's given the appropriate privileges, and you can also extract this data, tokens, passwords from browsers. And this is also quite interesting and pretty good. Overall, you have to understand that automated software tools, they make our work much easier, because the volumes of information are large, and honestly, working through that quickly is quite difficult. But you have to keep in mind that software tools can make mistakes, that is, their code may contain bugs. And their output should not always be treated as absolutely reliable. You need to take a critical view of the results you get, including re-checking them, re-checking the key results, the key information, with alternative methods, including manually, ensuring the verifiability and reliability of the results obtained.
And the methods of static and dynamic analysis, on the whole, they complement each other, they provide a combined approach to examining digital traces, and taken together they let you extract the maximum amount of digital data that an Apple macOS computer may contain. And they help make the examination as complete and comprehensive as possible, by extracting the maximum amount of forensically significant information.
Thank you.
Andrey, thank you for the talk. Questions from colleagues. —
— Yuri Mikhailovich, please. So the disk wasn't encrypted? How did you pull the file out?
In this case it was a Fusion Drive. We managed to reassemble it, and the data was pulled out, extracted. Obviously, if we're talking about encrypted disks, then if you decrypt it, you get the user's password as well. That's all logical. But if, as in this case, there's no encryption, you can try to gain access in various ways. —
— Next question. Good afternoon, thanks for the talk. Here's my question. On Linux, say, we can't get access to the shadow file with passwords under a user account, but on macOS we can? I mean, if we have a live system, say, the password's been entered, we won't be able to read the plist file? —
— Yes, thank you for the question. There are certain difficulties, especially if the device is a modern one, so, there's hardware encryption, the Secure Enclave is used. And here, of course, even with access, well, without root you can't get in, unfortunately. There are certain difficulties. So mainly, of course, if you have full access to the file structure, you can pull out that file, the plist, and then work with it. The whole point is to get that plist file out. If, of course, you can't get it out, then, unfortunately, there are certain limitations here. Well, it's no secret that there are a lot of problems with Apple devices.
And modern iPhones, as we know, are also quite problematic to examine, even if you have the passcode, including extracting the full file system. Well, there are certain limitations, so they have to be taken into account. —
— Right, colleagues, more questions? No more questions. Andrey, yes, we're letting you go. Thank you very much. Let's give him another round of applause.