- \n
- Authentication on computers vs smartphones<\/li>\n
- Threat model<\/li>\n
- Blackberry password managers<\/li>\n
- iOS Password managers (free vs paid software)<\/li>\n
- Summary & Conclusions<\/li>\n<\/ul>\n
Authentication<\/h4>\n
On PC's, there typically are a number of options available to developers, Andrey says :<\/p>\n
- \n
- Trusted Platform Module, often supported by the hardware<\/li>\n
- Biometrics, fairly easy to implement today (something you are)<\/li>\n
- Smartcard + pin (something you know and something you leave at home) : often used in corporate environments<\/li>\n
- Password\/Passphrase : still the most popular one, which explains why Elcomsoft is still in business.<\/li>\n<\/ul>\n
![\"20120316](\"https:\/\/www.corelan.be\/wp-content\/uploads\/2012\/03\/20120316_090746.jpg\" "\\"20120316_090746.jpg\\"")
<\/p>\nOn smartphones, the situation is different. \u00a0There usually is no TPM, biometrics are not available and neither are smart cards. In other words, we usually rely on passwords for authentication. \u00a0Andrey explains that some smartphones have some kind of processor that might be helpful to further secure authentication, but access to this component is only allowed for the system, and not applications.<\/p>\n
Passwords are usually either pins, or lock patterns (which are essentially numeric combinations).<\/p>\n
Andrey explains that, because of the limited keyboard size on smartphones, passwords usually are pretty weak on smartphones, compared to what people use on a PC.<\/p>\n
From a password cracking perspective, the actual process or cracking passwords is usually offloaded to other devices (PC's with GPU's, etc). Cracking passwords on a smartphone is uncommon because of the weak CPU performance.<\/p>\n
Finally, on PC's, users usually only log into the workstation just once. \u00a0On smartphones, people have to unlock their device a lot more often. \u00a0Handling passwords on a smartphone is much more difficult. \u00a0Because of the nature of the device, a smartphone really requires stronger password protection, but in real life it provides less capabilities to do so.<\/p>\n
<\/p>\n
Threat model<\/h4>\n
Some assumptions :<\/p>\n
The attacker has<\/p>\n
- \n
- physical access to the device; or<\/li>\n
- backup of the device; or<\/li>\n
- access to the password manager database file.<\/li>\n<\/ul>\n
The attacker wants to recover the master password to open the password manager on the mobile device and extract the passwords.<\/p>\n
It's pretty realistic to state that smartphones get lost of stolen quite often, so physical access is a very likely assumption to make.<\/p>\n
iOS devices need a device passcode or iTunes pairing in order to be able to create a backup. \u00a0The device needs to be unlocked to backup. \u00a0There is optional encryption available (enforced by the device) : PBKDF2-SHA1 with 10K iterations on iOS (which is done properly, according to Andrey).<\/p>\n
On Blackberry devices, a device password is needed to create a backup, and there is optional encryption available (but it's not enforced by the device). \u00a0 Encryption is done via PBKDF2-SHA1 with 20K iterations (even more than iOS), but again, it's not enforced, it's handled by the Desktop application instead.<\/p>\n
With respect to accessing the database file itself :<\/p>\n
On Apple iOS :<\/p>\n
- \n
- via the afc protocol (needs a passcode or iTunes pairing)<\/li>\n
- via ssh (jailbroken device).<\/li>\n
- via physical imaging (up to iPhone 4)<\/li>\n<\/ul>\n
On Blackberry<\/p>\n
- \n
- you need the device password (even for physical imaging)<\/li>\n<\/ul>\n
<\/p>\n
Blackberry Password Managers<\/h4>\n
Blackberry Password Keeper (included with OS 5)<\/span><\/p>\n
- \n
- Key is calculated using PBKDF2-SHA1 (3 iterations) \/ PKCS7 padding to fill the last block. The padding value contains the number of bytes of padding.<\/li>\n
- Password verification is pretty fast<\/li>\n
- 3 x PBKDF2-SHA1 + 1 x AES-256<\/li>\n
- 5 million passwords can be checked per second on a CPU, about 20 million passwords can be checked with a GPU<\/li>\n<\/ul>\n
Blackberry Wallet<\/span><\/p>\n
Version 1.0 (OS5)<\/p>\n
- \n
- Stores SHA-256 (SHA-256(password))<\/li>\n
- Password verification requires 2 x SHA-256<\/li>\n
- Very fast to crack : 6 million on a CPU, about 300 million on a GPU<\/li>\n
- No randomness, no salt\u2026 so you can use rainbow tables to crack<\/li>\n<\/ul>\n
Version 2.0 is better<\/p>\n
- \n
- Similar to Password Keeper<\/li>\n
- First, creates hash with SHA-512<\/li>\n
- PBKDF2-SHA1, nr of iterations is random (50 .. 100)<\/li>\n
- 200K passwords on CPU, 3.2 Million on a GPU<\/li>\n<\/ul>\n
<\/p>\n
iOS Password Managers<\/h4>\n
Dmitry explains how the iOS Password Managers work. \u00a0He explains that they used a simple AppStore search to find password keepers \/ password managers, found a LOT of applications and tested a couple of them.<\/p>\n
Free apps :<\/span><\/p>\n
They discovered applications that didn't use any encryption, stored passwords in sqlite databases and only have a 4 pin master password\/master passwords stored in clear text. \u00a0(iSecure Lite, Secret Folder Lite, Ultimate Password Manager Free).<\/p>\n
![\"20120316](\"https:\/\/www.corelan.be\/wp-content\/uploads\/2012\/03\/20120316_092804.jpg\" "\\"20120316_092804.jpg\\"")
<\/p>\nAnother application they tested, \"My Eyes Only\", stores data in NSKeyArchiver files, encrypted with RSA. \u00a0It saves the public & private key in the keychain with attribute kSecAttrAccessibleWhenUnlocked. \u00a0 The length of the key is only 512 bits, and Documents\/MEO.Archive, Dmitry explains, holds the RSA encrypted master password. \u00a0The private key is saved inside the protected data file.. (??)<\/p>\n
Keeper Password & Data vault claims to use military-grade encryption. \u00a0It stores data in a sqlite database. The md5 of the master password is stored inside the database as well. \u00a0The sha1 of the master password is used as AES key. \u00a0 Putting all of that together (and the fact that no salt is used for the MD5), this allows for cracking of about 60 million keys per second on a CPU, or 6000 million on a GPU. \u00a0(or use rainbow tables)<\/p>\n
Password Safe (iPassSafe) stores data in a sqlite database, and prevents the usage of \"weak\" passwords. \u00a0A random master key is used for encryption. \u00a0Passwords are not hashed, only null padded (PKCS7 padding allows to reject wrong keys). Cracking is very fast (only requires one AES-256 attempt), and there is the option to build & use rainbow tables.<\/p>\n
Strip Lite uses a sqlite database file encrypted using open-source components sqlcipher developed by Zetetic (the company that wrote the password manager). \u00a0Dmitry explains that this was by far the most resilient app for password storage. \u00a0Still possible to crack, but would be much slower compared to other applications.<\/p>\n
Paid apps :<\/span><\/p>\n
So, do paid applications offer better protection ? \u00a0Dmitry performed a Google search and looked for good reviews for password manager applications<\/p>\n
SafeWallet has versions for Windows, Mac, iOS, Android, Blackberry. \u00a0The database format is common for all platforms. \u00a0Master key is encrypted with the master password and data gets encrypted with AES-256, PKCS7. \u00a0Password verification is fast, testing speed is pretty fast too.<\/p>\n
DataVault : data encrypted by the master password and stored in the device keychain. \u00a0Master password is not hashed, only padded. \u00a0a SHA-256 of the master password is stored in the keychain. \u00a0\"Keychain is used, so it should be hard to get the hash to brute force the master password, right ?\" \u00a0Unfortunately, in IOS4, the keychain is a sqlite database. The data column is supposed to store passwords and is always encrypted\u2026 but DataVault stores the hash in the comment column (not encrypted). \u00a0 iOS5 encrypts all keychain items and stores a hash of the plaintext value to facilitate fast lookups \ud83d\ude42 \u00a0In other words, it's still trivial to do a brute force attack SHA-1(SHA-256(password)))<\/p>\n
mSecure encrypts data with Blowfish. \u00a0The master key is SHA-256 of the master password. \u00a0attack speed is relatively slow (because there is no Blowfish optimization on GPU's yet)<\/p>\n
LastPass : 'Cloud' service, stores your information somewhere in the internet. \u00a0Local storage gets created after first login. THe master key is SHA-256 of username+password. Attack speed is pretty fast because there is only one iteration.<\/p>\n
1Password Pro : Versions for MAC, Windows, iOS, Android. This seems to be a very popular application. \u00a0There are 2 protection levels : master PIN and master password (depending on the type of data). \u00a0 Data is encrypted with AES-128, the key is derived from the master PIN or master password. \u00a0 The database key encrypted on itself is stored for PIN or password verification. \u00a0It uses PKCS7 padding which allows to reject wrong keys. \u00a0You don't need the IV because you only need to decrypt the last block (IV = size of the last block). \u00a0Cracking is pretty fast (15M on CPU, 20M on GPU)<\/p>\n
SplashID Safe has version for various platforms and is a very popular application. \u00a0on iOS4, data is stored in sqlite. Sensitive data is encrypted with blowfish and the master password is used as a Blowfish key. Because of lack of GPU optimization, cracking of blowfish is slow. \u00a0 \u00a0 The master password is encrypted with\u2026 some key\u2026 \u00a0looks like a random key or so\u2026 well, after analyzing, they discovered it's in fact a fixed key. \u00a0This allows for instant decryption of the master password and decrypt all data almost immediately. \u00a0Ouch !<\/p>\n
Summary & Conclusions<\/h4>\n
On iOS4, the passcode is involved in encryption of sensitive data. \u00a0Passcode key derivation is slowed down by doing 50K iterations. \u00a0Each iteration needs to talk to hardware AES, so only 6 passwords can be checked per second on iOS4. \u00a0It can't be performed off-line and scaled. \u00a0 \u00a0It will take more than 40 hours to crack all 6-digit passwords.<\/p>\n
So, putting things together :<\/p>\n
- \n
- None of the tested password keepers offer something better than is already present in the OS.<\/li>\n
- Using them on improperly configured devices may expose sensitive data<\/li>\n
- Paid applications are not necessarily better than free ones. \u00a0During their tests, they discovered the best one was a free one.<\/li>\n<\/ul>\n
![\"20120316](\"https:\/\/www.corelan.be\/wp-content\/uploads\/2012\/03\/20120316_095245.jpg\" "\\"20120316_095245.jpg\\"")
<\/p>\nSome additional hints :<\/p>\n
Users :<\/p>\n
- \n
- always use passcode on iOS<\/li>\n
- set backup passwords (a complex one)<\/li>\n
- Do no connect your device to an untrusted device (not even a charger station !)<\/li>\n
- do NOT jailbreak the device, it will make it a lot less secure because some security checks are bypassed\/no longer used<\/li>\n<\/ul>\n
Developers :<\/p>\n
- \n
- Use built-in OS security services<\/li>\n
- Don't reinvent or misuse crypto\u2026 \u00a0Really, don't do it<\/li>\n<\/ul>\n
<\/p>\n
Apple vs Google Client Platforms<\/h3>\n
FX begins his presentation by crediting 2 more people he worked with to build the presentation. \u00a0He explains that they wanted to look at newer client platforms and different approaches used in those platforms, in terms of architecture, software sources, cloud, etc.<\/p>\n
![\"20120316](\"https:\/\/www.corelan.be\/wp-content\/uploads\/2012\/03\/20120316_101837.jpg\" "\\"20120316_101837.jpg\\"")
<\/p>\nTheir research focuses on iPad and Google Chromebook.<\/p>\n
First of all, he explains that the iPad generates a lot of money. Apple made the iPad to increase revenue and based on the statistics, it worked.<\/p>\n
With that in mind, from a design perspective, Apple wanted to provide<\/p>\n
- \n
- consistent, fluent and simple user interfaces<\/li>\n
- integrity protection of the OS & updates<\/li>\n
- restriction of third party software<\/li>\n
- protecting data is NOT a design goal (because it doesn't generate any money)<\/li>\n<\/ul>\n
FX mentions that you may want to sign up as a developer on AppStore and look at the signup process and read the contract\u2026 you'll notice some interesting statements such as<\/p>\n
- \n
- you may be denied access for pretty much any reason<\/li>\n
- all rights go to Apple<\/li>\n
- Apple has a limited liability (50$)<\/li>\n<\/ul>\n
Signing up costs $99<\/p>\n
![\"20120316](\"https:\/\/www.corelan.be\/wp-content\/uploads\/2012\/03\/20120316_104342.jpg\" "\\"20120316_104342.jpg\\"")
<\/p>\nGoogle, at the other side of the equation, built the Chromebook because they want to have a platform to display ads. \u00a0This is a totally different approach and motivation. \u00a0 It's built to run a single application, a web browser. \u00a0It's not designed to run third party apps or store data locally, but it still encrypts all traffic and any local data. \u00a0It has a fast startup and is built to appeal the heart of nerds, FX says, by providing an open and transparent development of the client platform.<\/p>\n
The Google Web Store has a simple sign-up process. It only costs $5 (one time). \u00a0It allows for direct submission of content, no delays.<\/p>\n
Apple details<\/h4>\n
From an iPad Security Architecture<\/span> point-of-view:<\/p>\n
- \n
- Standard XNU (Mach + BSD). \u00a0It has kernel & user processes, only one non-root user \"mobile\". \u00a0It's not designed to be shared.<\/li>\n
- Additional kernel extension \"Seatbelt\" which provides profile controlled security<\/li>\n
- Current versions have ASLR and DEP.<\/li>\n<\/ul>\n
Integrity protection : Protected Boot. \u00a0(of course, this does not protect issues in the initial bootloader). \u00a0FX explains that there is a buffer overflow in the ROM boot loader (needed for USB handling - required for recovery boot), which cannot be fixed.<\/p>\n
He continues by explaining that the Apple bootloader doesn't seem to check X509v3 basic constraints. \u00a0In theory, you would be possible to use the private key stored on the device (used for push notification) to sign arbitrary firmware\u2026 but because of some issues in the bootloader code, it didn't seem to be possible to actually abuse it.<\/p>\n
They also discovered that the userspace TLS libraries reveal that X509 basic constraints are not checked either. \u00a0 He explains that it was possible to abuse this to perform a mitm for ssl protected websites.<\/p>\n
Binaries are signed with a Mach-O signature. \u00a0 The kernel verifies the integrity of applications and libraries. \u00a0Signatures are embedded n the Mach-O binaries. \u00a0FX shows a few examples on how this can be exploited.<\/p>\n
Updating the iPad :<\/p>\n
- \n
- System Updates : covered by the integrity protection mechanisms.<\/li>\n
- Application Updates are supplied by the AppStore<\/li>\n
- PLMN Carrier updates : carrier bundles can be pushed OTA to your device. \u00a0It can set APN, proxies etc. \u00a0 It needs to be Signed SomeHow\u2026 \u00a0certainly an area interesting enough to perform further research<\/li>\n<\/ul>\n
Apple AppStore Architecture<\/span><\/p>\n
The AppStore \/ iTunes clients are based on WebKit and have a number of flaws (pop-up issues, MITM, CSRF Tokens are ignored, same origin policy bypass), some of which are pretty hard to fix. \u00a0One of the examples FX demonstrates is displaying the \"enter your apple-id\" window which looks like the real one, but is in fact javascript code, written to steal credentials. \u00a0Combine that with issues such as XSS (yes, the search field had XSS - WTFLOL)\u2026 \u00a0perfect scenario to download + install + run custom software. \u00a0 Apple \"fixed\" it, by fixing that particular XSS in the search field\u2026 \u00a0\ud83d\ude41<\/p>\n
![\"20120316](\"https:\/\/www.corelan.be\/wp-content\/uploads\/2012\/03\/20120316_104615.jpg\" "\\"20120316_104615.jpg\\"")
<\/p>\nApple pretty much controls your content and forces you to go to the AppStore and push arbitrary apps to your device.<\/p>\n
<\/p>\n
Google - the ChromeBook Security Architecture<\/h4>\n
Access to the device is based on Google Accounts or a Guest account. It's designed to be shared. \u00a0 It uses eCryptFS to encrypt user data (separately).<\/p>\n
It runs a Standard Linux OS, has iptables firewall, etc.<\/p>\n
The only thing you're supposed to be running in the Chrome browser (and uses process separation & sandboxing mechanisms) \u00a0 If you put the device in Developer mode, you'll get a big warning.<\/p>\n
It hides the file system from the user using a hard coded list of allowed file:\/\/ URI's, but apparently Adobe Flash seems to ignore that list.<\/p>\n
Pretty similar to what Apple does, Google implemented a chain of checks during boot to protect integrity of all components. \u00a0The file system integrity protection, FX continues, was implemented pretty well, and is based on hashes and eventually one hash of the bundled hashes. \u00a0\u00a0Unfortunately, the partition table is not integrity protected, and neither are the OEM and EFI partitions. \u00a0There's a theoretical breach of integrity protection chain through a kernel argument format string.<\/p>\n
Also, there's a HW Assisted Backdoor in the device. \u00a0Although the read only initial bootloader is\u2026 readonly, it can be made writeable by opening the device and reprogramming the (well documented) chip. You can replace the boot stub & run arbitrary firmware without getting any warnings.<\/p>\n
Chromebook checks for updates every 45 minutes. \u00a0Updates are incremental modifications to firmware and root partition (which is possible because of the block device model). \u00a0All traffic is TLS\/SSL protected, but there are some issues with the fact that the entire process is online and only gets verified at the end. If something goes wrong in the meantime, you may end up with a bricked device.<\/p>\n
The Google Web Store distributes Browser-Extensions and \"Downloadable WebApps\". \u00a0 The Chrome-Browser exposes additional API and capabilities to these local JavaScript extensions, depending on permissions (user granting permissions on install). \u00a0 The extensions are partially free, partially paid for, but always come with source. \u00a0Paid extension are sold via Google Checkout, so you'll get a link with an ID to download the extension at the end. \u00a0 Interestingly, FX says, the same links (with unique ID's) are also used for closed user group testing. If you know the App-ID, you can download & install the app.<\/p>\n
In theory, a mitm attack or an API can allow someone to install a custom malicious Extension to the device. Google Sync can sync all installed Extensions to a Google Account. \u00a0So - if the account is pwned, the browser can be pwned as well.<\/p>\n
A lot of the security model obviously relies on the Google Account. If your account is compromised, all is lost. \u00a0 If your session cookie is compromised, your account is compromised. \u00a0Remember, we are dealing with a model that relies on storing stuff in the cloud. \u00a0 \u00a0If Google doesn't like for whatever reason and closes your account, you're screwed too. \u00a0If you need Google to close your account because it was hacked\u2026 good luck, they might not care about it (even if you're HBGary Federal) \u00a0Other than that, feel free to use the cloud \ud83d\ude42<\/p>\n
Since Google relies on the browser and thus sessions, it's important to understand that the entire model stands or falls with the security if your session.<\/p>\n
On a sidenote, FX explains that macros in Google Docs get executed server-side. You can import macros written by someone else. \u00a0The user initially approves the script and it runs. \u00a0Sure, you can inspect the code if you want to\u2026 but if the author decides the change the code at any time and introduces some malicious code, you'll never know about it.<\/p>\n
There's another issue with allowing 3rd party services to access your data. \u00a0You basically authorize the exchange of data, but it's possible to use some token\/redirection trickery (Google \"I feel lucky\" anyone) to spoof a page that would for example ask you to allow www.google.com to get access to your data, but in the back end, it's using the auth token for another domain\/app (which gets used during the redirection)<\/p>\n
To sum things up, both Apple and Google want money. \u00a0Relying on a cloud client platform only is putting all eggs in the basket, and you have to realize it's not your own basket. \u00a0Based on the research and the fact that these are big companies, that know what they are doing, have Web-Security bugs. \u00a0The way certain things were designed (Apple vs encryption), it's clear that security is not their primary concern.<\/p>\n
<\/p>\n
GDI Font Fuzzing in Windows kernel for Fun<\/h3>\n
The presenters, Lee Ling Chuan and Chan Lee Yee, from the Malaysian CyberSecurity agency, part of Mosti (Ministry of Science, Technology and Innovation) explain that there are 2 groups of categories when it comes down to fonts :\u00a0GDI Fonts & Device Fonts.<\/p>\n
![\"20120316](\"https:\/\/www.corelan.be\/wp-content\/uploads\/2012\/03\/20120316_114722.jpg\" "\\"20120316_114722.jpg\\"")
<\/p>\nThere are 3 types of GDI Fonts in Windows : raster based, vector based and TrueType\/OpenType<\/p>\n
a raster font glyph is used to draw a single character (bitmap). Vector fonts are collection of lines. \u00a0TrueType\/Opentype is a collection of lines and curves.<\/p>\n
A truetype font (.TTF) file contains data (table) that comprises a font outline. \u00a0This TTF table contains other tables (EBDT, EBLC and EBSC). The rasterizer uses a combination of data from different tables to render the glyph data in the font.<\/p>\n
- \n
- EBDT - Embedded Bitmap Data Table : stores the glyph bitmap data. It begins with a header containing the table version number (0x2000). \u00a0The rest of the data is the bitmap data.<\/li>\n
- EBLC - Embedded Bitmap Location Table : identifies the size & glyph range of the sbits & keeps offsets to glyph bitmap data in indexSubTables. \u00a0The table begins with a header (eblcHeader) and contains the table version and the number of strikes. \u00a0The eblcHeader is followed by the bitmapSizeTable array(s). \u00a0Each strike is defined by one bitmapSizeTable.<\/li>\n
- EBSC - Embedded Bitmap Scaling Table : allows a font to define a bitmap strike as a scaled version of another strike. It starts with a header (ebscHeader) containing the table version and number of strikes. \u00a0The header is followed by the bitmapScaleTable array.<\/li>\n<\/ul>\n
A TTF font has a set of instructions and defines how something must be rendered. The itrp_InnerExecute function is the disassembler engine that will process glyph data and map the correct TrueType instructions.<\/p>\n
TTF Font file fuzzing<\/h4>\n
The researchers developed a TTF Font fuzzer to fuzz different sizes. \u00a0 The fuzzer creates a font, installs it automatically in the C:\\windows\\fonts. \u00a0Next, it will register a windows class & creates a window to automate the display of the font text in a range of sizes (using Windows API's). \u00a0Finally, it will remove the font.<\/p>\n
Next, they explained the technical details behind the MS11-087 bug, highlighting that the font size must be set to 4 to trigger the vulnerability, and then demonstrated the vulnerability (Windows 7, with DEP, ASLR and UAC enabled, and logged in as a guest account) , using a kernel debugger switched to the csrss.exe context, and by using ring0 to ring3 shell code (using an empty loop where you can place any ring3 payload).<\/p>\n
![\"20120316](\"https:\/\/www.corelan.be\/wp-content\/uploads\/2012\/03\/20120316_121533.jpg\" "\\"20120316_121533.jpg\\"")
<\/p>\nWith the correct breakpoint set (to win32k!sfac_GetSbitBitmap, they used their fuzzer to prove that size 4 is indeed the one triggering the overflow.<\/p>\n
.fon fonts<\/h4>\n
With regards to Microsoft Windows Bitmapped Font (.fon), they explain that these come in 2 types :<\/p>\n
- \n
- New Executable (NE), which is the old format used in Windows 3<\/li>\n
- Portable Executable (PE), used in Windows 95 and above<\/li>\n<\/ul>\n
They continue with sharing some details on a .fon fuzzer, consisting of 2 scripts :<\/p>\n
- \n
- mkwinfont.py \u00a0(Simon Tatham), which creates NE .fon files<\/li>\n
- fuzzer.py (Byoungyoung Lee), will fuzz the .fon in different width & heights.<\/li>\n<\/ul>\n
They made 2 modifications to the scripts and reproduced the .fon file bug in MS11-077 (discovered by Byoungyoung Lee), triggering a BSOD (BAD_POOL_HEADER(19) \u00a0or \u00a0DRIVER_OVERRAN_STACK_BUFFER(f7)).<\/p>\n
Based on their analysis, they state that it's very difficult to bypass the safe unlinking protection in windows kernel pool. \u00a0They went thru the various steps that lead to the overflow of 3 bytes of the next pool header and show that this particular bug has some important limitations in terms of what you can control, which makes it hard to exploit.<\/p>\n
The additional bug they found (DRIVER_OVERRAN_STACK_BUFFER) gave them more control, but they didn't research further options for bypassing the kernel canary because the issue was already being patched by Windows. \u00a0 The interesting thing about this bug is that you don't need to open the font file - just a mouse hover is enough to trigger the issue.<\/p>\n
This was a truly great, very technical & quite fast paced talk. \u00a0If you plan on taking a malware reversing class somewhere, you may want to check out their training at Hack In Paris - these 2 definitely know their fu !!<\/p>\n
<\/p>\n
Canape - Bytes Your Bits<\/h3>\n
In the first talk after lunch (and probably also the last talk I'm going to cover this year - got a train to catch and stuff), James Forshaw and Michael Jordon (from Context) will introduce and release CANAPE, a tool they developed that aims at taking the existing paradigm of Web Application testing tools such as Burp, CAT or Fiddler and applies that to any network protocol.<\/p>\n
Michael explains that the tool is a very generic tool to mitm traffic between two hosts and fuzz traffic. \u00a0Using the tool, they will demonstrate finding and exploiting a bug in the Citrix ICA traffic. \u00a0In other words,\u00a0is a binary network application testing tool.<\/p>\n
The core layer of the tool is a mitm engine.<\/p>\n
![\"20120316](\"https:\/\/www.corelan.be\/wp-content\/uploads\/2012\/03\/20120316_141905.jpg\" "\\"20120316_141905.jpg\\"")
<\/p>\nThe MITM functionality supports :<\/p>\n
- \n
- Socks<\/li>\n
- Port forwarding<\/li>\n
- TCP\/UDP\/HTTP\/Broadcast<\/li>\n
- SSL<\/li>\n<\/ul>\n
It also uses pipelines that allows you to use some built-in logic<\/p>\n
They continue by briefly discussing the ICA protocol. In essence, ICA is a protocol used for Citrix XenApp and XenDesktop products. \u00a0It's used for remote desktop purposes and to run applications. The ICA protocol uses an ICA configuration file (which allows you to tell ICA to use socks, which is convenient for Canape \ud83d\ude42<\/p>\n
Next, the tool is demonstrated. \u00a0 They load a basic socks template, and start \u00a0the proxy engine.<\/p>\n
![\"20120316](\"https:\/\/www.corelan.be\/wp-content\/uploads\/2012\/03\/20120316_142224.jpg\" "\\"20120316_142224.jpg\\"")
<\/p>\nAfter configuring ICA to use Canape as socks proxy, the tool captures the traffic and displays it.<\/p>\n
The ICA protocol is a stream bases protocol. \u00a0It uses a single TCP stream and has 3 phases :<\/p>\n
- \n
- Hello<\/li>\n
- Negotiation<\/li>\n
- Main stream (encryption, compression, multiplexing)<\/li>\n<\/ul>\n
Using the previously capture data, a net graph can be used to represent states in the network traffic. \u00a0By adding a decision node to the graph (which really is some kind of IF statement), and setting a filter to it (looking for the hello magic bytes)<\/p>\n
![\"20120316](\"https:\/\/www.corelan.be\/wp-content\/uploads\/2012\/03\/20120316_142826.jpg\" "\\"20120316_142826.jpg\\"")
<\/p>\nBy adding flows and setting a library, you can start breaking the initially captured flow down into the various phases or states. As a side note, from what I have seen, I hope the tool will come with an extensive manual because it looks quite overwhelming in terms of features and configurations steps & requirements.<\/p>\n
James explains that the tool allows you to further document the entire protocol (including packets from the main stream) into the application. Using a parser, defining the various components in a single packet, they can further break down the stream\/packets into fields (length, flags, data)<\/p>\n
After breaking the stream further down, they explain that, since it's encrypted traffic, they (ideally) would like to strip out the encryption as well. \u00a0Based on the java implementation of ICA, they found the code that takes care of the encryption.<\/p>\n
Canape allows you to run something outside of the tool (python, C#, ruby, visual basic, etc). \u00a0James demonstrates a C# script, using XPath expressions to access the actual data and capture the key & decrypt it on the fly via a Dynamic node. \u00a0Of course, they can add an encrypted as well (so they can decrypt, change, encrypt in a later phase)<\/p>\n
After decrypting the traffic, they realized that the decrypted data is compressed. \u00a0Looking at the java code, they noticed the compression code is quite complex, so instead of implementing the compression routine, they decided to use a certain flag in the session to downplay (and basically disable) compression, the equivalent of setting a registry key. \u00a0Of course, setting the key is not what we want to do, because we don't necessarily control the other side of the connection, so using the flag (replacing some bytes with other bytes) inside the connection would be more generic.<\/p>\n
After decompressing, the traffic starts to look at lot better and shows username & passwords in cleartext - the best proof that the changes worked.<\/p>\n
Next, they started looking at some of the other traffic, such as key presses. mouse movements, etc. \u00a0So, after further documenting some of the sessions, you can use the fuzzer functionality in Canape to start changing traffic. \u00a0From that point forward, all you need is some tool\/script to run debugger + the ICA client and connect to the proxy which will fuzz traffic.<\/p>\n
Time to demonstrate an older (now patched) bug in ICA. \u00a0By controlling a value, used to get an offset in a list, which is then used to get another offset in another list, and then the resulting address is used as a function pointer, code execution would be possible.<\/p>\n
In order to make it easier to find data you control, they distilled the required list of packets down to a small number and use the replay service in the tool to have more control over what traffic is sent exactly (instead of randomizing it all the time). \u00a0After finding the bytes that seem to be important and telling an integer fuzzer to those bytes, they can further brute force the value to land somewhere in the heap (and perhaps use some kind of heap spray to control that location).<\/p>\n
Citrix uses a static buffer for packets. If you send a small packet with a long length value (which doesn't get checked), it's possible to perform some kind of heap spray. \u00a0There are a couple of other issues<\/p>\n
- \n
- Block with 0's : Since we control EAX (and contains a valid address), the instruction ADD BYTE [EAX],AL will work fine.<\/li>\n
- Header bytes shouldn't break the execution when it gets run as opcode.<\/li>\n<\/ul>\n
Putting things together, all ingredients are available to build an exploit.<\/p>\n
From an attack vector point of view, Michael explains, you can set up a website, get a client to download the ICA file which contains the target IP\/port of your malicious exploit ICA server and exploit the client.<\/p>\n
James continues with configuring the tool to set up an HTTP server, and create the necessary packets (flood) to perform the heap spray & deliver the payload.<\/p>\n
FInally, they demonstrated a 0day BSOD in a modern version of Citrix Server. \u00a0(demo only)<\/p>\n
Great tool with lots of potential, might have a bit of a learning curve, but looks promising.<\/p>\n
I found this\u00a0Whitepaper that has a lot more info about Canape than what I could capture during the talk.<\/p>\n
Check out http:\/\/canape.contextis.com - the tool is free, only runs on Windows and uses .Net Framework 4.<\/p>\n
<\/p>\n
That's it \u00a0!<\/h3>\n
Just a few more words of gratitude before I go : Thanks to<\/p>\n
- \n
- BlackHat for organizing and hosting a great conference again;<\/li>\n
- old friends & new friends, for hanging out, having great and entertaining conversations;<\/li>\n
- the weather gods, for giving us some fine days;<\/li>\n
- you, for dropping by at www.corelan.be and reading this post.<\/li>\n<\/ul>\n
At the same time, as a dad, I also would like to finally take the time to express my deepest condolences to the people who lost their kids or friends in the horrible bus accident earlier this week in Switzerland<\/a>. \u00a0 Although my mind has been set to BlackHat mode for the last few days and I had the impression the news didn't really fully hit the masses at Blackhat, it has certainly marked me and made me feel sad.<\/p>\n
Bye for now, see y'all later !<\/p>\n
<\/p>\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
- you need the device password (even for physical imaging)<\/li>\n<\/ul>\n