Tue Feb 21 19:35:56 CET 2012
Content Transfer Done
We transfered the following content:
Posted by remote-exploit.org | Permanent link
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:
AC,AG,AL,AN,AO,ARPA,AW,BA,BD,BI,BJ,BM,BN,BS,BV CI,CU,CV,DE,ER,GD,GE,GN,GOV,GQ,GT,GY,IN,INT,IO JM,JO,KE,KG,KH,KI,KZ,LB,LC,LK,LR,MA,MD,MG,MH,MP MR,MT,MW,NE,NF,NG,NI,NP,PE,PF,PG,PW,PY,SH,SJ,SK SL,SN,SO,SR,SV,SZ,TC,TJ,TM,TN,TRTZ,UG,UK,UY,VG VI,YE,YU,ZW
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.
Mon Jan 9 01:38:27 CET 2012
New Hosting, Simpler Layout
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
CCCryptorFinal (or simply
one-shot function) to perform symmetric encryption using different
algorithms like AES, 3DES and hardcore security ciphers like RC4,
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, kCCAlgorithmAES128, *pkcs7, (const void *)[symmetricKey bytes], kChosenCipherKeySize, (const void *)iv, &thisEncipher ); ...
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.