Differences

This shows you the differences between two versions of the page.

--- exploit [2011/08/19 12:18] – [Receive VCard, remote exploits] nitram
+++ exploit [2011/08/19 13:38] (current) – [The Keys] nitram
@@ Line 73: / Line 73: @@
 also discovered some attack vectors. Even if we didn't extracted the 128bit holy grail,
 these vectors should be closed to prevent others from p0wning your device ;-)
+Finally we want to say **Thank You** too all the people who inspired us (CCCP, deadbyte, red becon, TkkrLab, and others).
 ====== charBuf overflow ======
@@ Line 92: / Line 94: @@
 Thus it's possible to send l0dables (*.c0d).
 This could be an option for remote exploits, when combining with other vectors.
+**Countermeasure:** Extra check the incoming meta data and create only valid VCARD files.
 ====== Two-staged l0dable exploit (unfinished) ======
-Bla
+We didn't were scared about the [[http://en.wikipedia.org/wiki/XXTEA|XXTEA]] crypto algorithm which
+protected the l0dables, but also tried to circumvent the checks.
+In the end we came up with a two staged approach, which may work, if some one fixes the "firmware bug" ;-)
+**Stage 1:**\\
+Prepare some l0dable with your shell code by
+   a) do not encrypt it
+   b) add 16 bytes of padding in front of your code (using NOPs and/or hex editor)
+   c) make sure the file size is not a multiple by 16 (simply add some 0x00s)
+Put this l0dable on your original protected device and execute it.
+This should result in error code ''size!''. But our shell code is now loaded right in place.
+**Stage 2:**\\
+Now we want to execute our code. Therefore we spotted out two possible options,
+where no special checks/validations are existing.
+   a) Zero-size l0dable: Create a file with size=0 and execute it right after stage 1.
+      This will keep our stage 1 code in place and bypass the size check.
+      Unluckily this will end up in a integer overflow within the ''xxtea_cbcmac()'' see ''len-4''.
+   b) 16-byte l0dable: Create a file with size=16, containing 0x00 and execute it right after stage 1.
+      This will also keep our stage 1 code in place, bypass the size check
+      and bypass the MAC check.
+      Unluckily this will end up in a division by zero exception within ''xxtea_decode_words()''.
+      At this point, only a programming bug prevents us from successfully running our code!
+      Because every static code analyzer will spot this as a devision by 0 programming error,
+      there is some hope, that someday this could be fixed and exploited.
+      Remember the OpenSSL issue CVE-2008-0166? ;-)
+**Countermeasure:** (1) Clean the memory before loading new l0dables. (2) Do more checks before executing loaded code.