January 2012 Archives

2012-01-09 15:15:00

Collected 1st & 2nd Level Domains

Every now and then, I go through the domain names like most of us. In late 2009-2011 the following top level domains allowed domain transfers:


After having the files on my disk without beeing used too much lately, I decided to put second-level-subdomain-transfers.txt.tgz up on our website ready for download.

You should be warned, second-level-subdomain-transfers.txt.tgz is about 55 Megabytes of compressed text and contains all the gathered 1st and 2nd level domain names. A lot of the domains are not updated since late 2009 but the information is still useful for statistics or 3rd level gathering etc.

Feel free to send me updates and/or third level domain scan results etc.

Posted by remote-exploit.org | Permanent link | File under: misc

Mon Jan 9 01:38:27 CET 2012

New Hosting, Simpler Layout

As we move from one hoste to another, we also took the chance to further slim down the website and simplify the layout. If you miss a certain content, you might have to be patient drop us an E-Mail or be patient until we moved it to the new location.

Posted by remote-exploit.org | Permanent link

Mon Jan 9 00:16:33 CET 2012

The Apple Idioten Vektor (IV)

We all agree that crypto is important and therefore should be left to the experts. Well, kind of. This "expert" thing is probably the most extensively construed thing in the world of IT security. We all know, that we have a vast amount of "experts" out there.

Apple still ignores the fact that Objective-C and Cocoa is the new PHP. Most iOS programmers ain't reflect anything that has been told to them - functionality matters, what else. You'll become a super-hero in your company if you have proven to be able adding security to your Apps! Fortunately, Apple provides a crypto library that isn't that complicated, so even your 17 years old iOS expert student is able to generate new buzzwords for your portfolio & keynote slides, hence more $$$.

So... let's call this thing that Apple must take care of:


Responsibility regarding how secure and safe their software is, how unambiguous their application programming interfaces should look like, and how it is published and documented.
Apple provides documentation to their APIs in their online iOS and OSX Developer Library. They also have some crypto stuff available here, let's have a look at the CryptoExercise - sounds promising to get a brief understanding about their high level crypto API:

This sample demonstrates the use of the two main Cryptographic API sets on the iPhone OS SDK. Asymmetric Key Encryption and random nonce generation is handled through the Security framework API set, whereas, Symmetric Key Encryption and Digest generation is handled by the CommonCrypto API set. The CryptoExercise sample brings both of these APIs together through a network service, discoverable via Bonjour, that performs a "dummy" cryptographic protocol between devices found on the same subnet. Link: Apple Crypto Exercise

The CryptoExercise is the official "Related Sample Code" when it comes to "Secure Coding" and e.g. to the "Certificate, Key, and Trust Services Reference".

They also provide a man-page for their "Common Crypto Interface" CCCryptor(3cc):

  CCCryptorCreate, CCryptorCreateFromData, CCCryptorRelease,
  CCCryptorUpdate, CCCryptorFinal, CCCryptorGetOutputLength,
  CCCryptorReset, CCCrypt -- Common Cryptographic Algorithm Interfaces

Using the CCCryptor, one can use common sounding functions such as CCCryptorCreate, CCCryptorUpdate, CCCryptorFinal (or simply CCCrypt() one-shot function) to perform symmetric encryption using different algorithms like AES, 3DES and hardcore security ciphers like RC4, DES, etc.

Apple supports ECB and CBC mode for their ciphers, and fortunately a developer really needs to explicitly prove stupidity by using ECB since APIs default to CBC, the Cipher Block Chaining mode. What could possibly go wrong? Right, there is some minor thing that is called the "IV". Apple supposedly translated the acronym IV to "Ignorance Vector" when writing their Common Crypto API man-pages, but we should read "Initialization Vector" - used to initialize the very first block of cipher text.

You can easily learn (even on Wikipedia), that IVs must be unique for any message encrypted with a given key. And also, that an IV must be unpredictable to avoid several types of cryptographic attacks. That's pretty well known, and there is exactly no single use case for an IV initialized entirely with zeros.

And this is how they describe their API and especially the usage of the IV:

Another option for block ciphers is Cipher Block Chaining, known as CBC mode. When using CBC mode, an Initialization Vector (IV) is provided along with the key when starting an encrypt or decrypt operation. If CBC mode is selected and no IV is provided, an IV of all zeroes will be used.

Instead of simply returning ENOBRAIN, they initialize the IV with zeros without any warning. This is so damn unique and unpredictable, you can't make this up.

In their header files they call the Initialization Vector "optional":

@param  iv      Initialization vector, optional. Used by 
                block ciphers when Cipher Block Chaining (CBC) 
                mode is enabled. If present, must be the same
                length as the selected algorithm's block size. 
                If CBC mode is selected (by the absence of the 
                kCCOptionECBMode bit in the options flags) and no 
                IV is present, a NULL (all zeroes) IV will be used. 
                This parameter is ignored if ECB mode is used or
                if a stream cipher algorithm is selected.
CCCryptorStatus CCCryptorCreate(
        CCOperation op,             /* kCCEncrypt, etc. */
        CCAlgorithm alg,            /* kCCAlgorithmDES, etc. */
        CCOptions options,          /* kCCOptionPKCS7Padding, etc. */
        const void *key,            /* raw key material */
        size_t keyLength,       
        const void *iv,             /* optional initialization vector */
        CCCryptorRef *cryptorRef);  /* RETURNED */

and the sample code looks like that:

uint8_t iv[kChosenCipherBlockSize];
memset((void *) iv, 0x0, (size_t) sizeof(iv));
// Create and Initialize the crypto reference.
ccStatus = CCCryptorCreate( encryptOrDecrypt, 
                            (const void *)[symmetricKey bytes], 
                            (const void *)iv, 

At least they fail consistently.

Well done, Apple. Now imagine those guys that i have mentioned above, super special experts on iOS and OSX application security and crypto. They will use your documentation, your notes & hints and they will also use your official sample code. And nobody will ever question, what you have told them. Now, go ahead and watch github projects forking like hell, using your broken code! This simple mistake might increase for a decent period of time due to code copy & paste mentality in iOS/OSX open source projects. Maybe even your recently featured, closed source OSX AppStore application that safely stores passwords, follow your guidelines :-)

Wait! There is more!

There are people out there, who are abusing dead trees to spread the word. Using Google Books, i found two books, covering OSX/iOS application security and also crypto. 50 % of those books simply made it wrong as you did, Apple, fifty per cent. "Professional Cocoa Application Security By Graham J. Lee" did it right, this book is on "Amazon Best Sellers Rank: #527,874". The following book did it wrong: "Pro Core Data for IOS: Data Access and Persistence Engine for iPhone, iPad, and iPod touch" [sic!] By Michael Privat, Robert Warner - Chapter "Using Core Data in Advanced Applications - Creating an Application for Note and Password Storage and Encryption" - and guess what: "Amazon Best Sellers Rank: #289,601"

It's a mess.

Posted by remote-exploit.org | Permanent link | File under: crypto