Crypto Hot Cases – One Year Backward


Published on

Published in: Technology, Education
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • I am going to present a few examples of each of these cases using Snowden’s leaks but not only
  • Because of modifying directly the source code of Windows is not an reliable solution, using the Shim Infrastructure allow you to target a specific application (and typically, for particular versions of that application), with these fixes housed outside the core Windows functions and maintained separately.

    Specifically, you can modify the address of the Windows function resolved in the import table, and then replace it with a pointer to a function in the alternate shim code, as shown in Figure at the bottom.

    Technically, there are two possibilities to do that : statically or dynamically. This indirection happens for statically linked .dll files when the application is loaded. You can also shim dynamically linked .dll files by hooking the GetProcAddress API.

    How Shims work.
    The Shim Infrastructure implements a form of Application Programming Interface (API) hooking. The Windows API is implemented using a collection of DLLs. Each application built for Windows imports these DLLs, and maintains a table of the address of each of these functions in memory. Because the address of the Windows functionality is sitting in a table, it is straightforward for the shim engine to replace this address with the address of the shim DLL instead. The application is generally unaware that the request is going to a shim DLL instead of to Windows itself, and Windows is unaware that the request is coming from a source other than the application (because the shim DLL is just another DLL inside the application’s process).
  • SOURCE :

    When using shim?

    For example, a very commonly used shim is a version-lie shim. To implement this shim, we intercept several APIs that are used to determine which version of Windows the application is running on. Normally, this information is passed on to Windows itself, and it answers truthfully. With the shim applied, however, these APIs are intercepted. Instead of passing on the request to Windows, a different version of Windows is returned (for example, Windows XP instead of Windows 7). If the application is programmed to run only on Windows XP, this is a way to trick the application into believing it’s running on the correct OS. (Frequently this is all that is necessary to resolve an application compatibility problem!)

    -> Other cases :
    - ForceAdminAccess : When an application requires to be running by a member of administrator group, this one checks with IsUserAnAdmin from shell32.dll API. The shim return TRUE whatever the user is. In most of the case, old API which required to be admin doesn’t need it anymore or to access to a specific directory…
    - The CorrectFilePaths shim can redirect files from one location to another. So, if you have an application that is trying to write to c:myprogramdir (which isn’t automatically fixed using UAC File and Registry Virtualization), you can redirect the files that are modified at runtime to a per-user location. This allows you to run as a standard user without having to loosen access control lists (ACLs), because you know your security folks hate it when you loosen ACLs.

    Different scenarios :

    You acquired the application from a vendor that is no longer in business. Several applications are from vendors that have since gone out of business; so clearly, support is no longer a concern. However, because the source code is not available, shimming is the only option for compatibility mitigation.
    You developed the application internally. While most customers would prefer to fix all their applications to be natively compatible, there are some scenarios in which the timing does not allow for this. The team may not be able to fix all of them prior to the planned deployment of new version of Windows, so they may choose to shim the applications that can be shimmed and modify the code on the ones where shims are insufficient to resolve the compatibility issue.
  • The shim can be linked to an executable according to several criteria. From hash which are the most reliable one, it could also be based on name, size, product name, copyright, version… It is not really accurate.
  • -> Even if M$ says there is no security whole, applications which break them and still continue to run “as if nothing had happened” are not magic ! In fact, restriction are done or old API deprecated is still continue to be used.

  • -> Here is an example of a software using different API for cryptography purposes. Part of this API is from the software and another part uses the Windows API.
  • -> The goal is to be called instead of the initial API supposed to be called. No matter if the library containing the crypto features is on windows API side or on software side.

    -> Because of the Dlls export functions, they must declare the name of their function in their export table (called EAT). Reading this table allow you to know which functions must be hijacked.
    -> If the Windows API used by the software or its internal one is undocumented, use reverse engineering to implement correctly your hooks.

    -> Because of the Shym, you can use this “tool” to perform attacks in a smooth manner. Other tools like executable which perform Dll injection can although be considered. This is the old school manner to do that.
    Note that, many other technics must be considers. Because of the application uses user32.dll, consider the HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWindowsAppInit_Dll to inject automatically Dll inside a process as trigger.
  • -> The case where the software is splitted in multiple Dlls (k-ary malware or codes) is pretty simple to implement. In the case where the software stores every functions in it, it’s a bit more complicated to attack, but not impossible.
    -> Illustration of the technic follows this slide.
  • -> Of course, this requires us to know where is located the cipher routine in the software. It hardly survives to software updates. Nevertheless, it is possible to implement heuristic procedures supposed to search inside the targeted process where the cipher routine is located. These procedures are implemented in our Dll.

    -> Of course, these technics are detectable with the proper tools. But who cares about to know which Dll are running on processes. In addition, when it is a « shim » Dll with a names which sounds « windows compatiblity », there are no more investigations.

    -> In such a case, there is more than one way to do it. For example : we can directly write in the targeted process executable (if it is not currently running or if its executable file is not signing).
  • -> When we read the msdn, we can sometime find very interesting function. Here is one supposed to “protect” the content of a specific memory … without any password or entropy sources…
  • -> Of course, Dll injections do not succeed anymore … . Dll injection, shims, etc…
    -> Cross process means that data in memory is accessible in different processes. An application running in a different process will be able to decrypt the data.
    -> To sum-up : NO SECURITY….
    -> Same logon means that it uses the same logon credentials to encrypt and decrypt memory in different processes. An application running in a different process will be able to decrypt the data. However, the process must run as the same user that encrypted the data and in the same logon session.
    -> To sum-up : malware should run in another user to have protection… It’s ridiculous !
  • -> It seems that it was better before!
  • -> Note than on RtlRandomEx msdn page, it is written :

    The RtlRandomEx function is an improved version of the RtlRandom function. Compared with the RtlRandom function, RtlRandomEx is twice as fast and produces better random numbers since the period of the random numbers generated is comparatively higher.
  • -> Two identical tests performed. Always with the same seed. In this case, first with RtlRandom and then with RtlRandomEx…

    -> RtlRandom routine (the former one) always returns the same value/seed with the same fixed seed between the test. This is a true pseudo random generator since the same key produces the same output.
    -> RtlRandomEx routine (the new one) returns different values between two test. An additional variable (or anything else which adds entropy) must be added to the random algorithm used by Microsoft. Nevertheless, the seed still remains the same !!!

  • -> If you observe carefully the output of the first generator (Gf_1(i)) and the second (Gf_2(i)), you should remark that :
    -> Gf_1(i) = Seed(Gf_2(2*i)).
    -> Seed(Gf_1(i)) = Gf_2(2*i)
    L’evolution de la seed de la fonction RtlRandEx est determinee par Rtlrandom
  • -> There are correlations between seed and return value for the RtlRandomEx generator. Some values are sometime the same, there is offset between seed and value, etc…

    -> Because of the same seed evolution, correlation between output and seed, correlation between the two generators (one which is not really random, even for M$), we may suspect hidden states or means to recalculate the hazard with (or without) the cryptovariable (seed). It seems to be especially true for RtlRandomEx routine even if this is not a true pseudo random generator since its output is not the same between two executions. Note that its seed evolution remains the same…

    -> The call of the two generators are independent (it doesn’t matter if RtlRandom is called before or after RtlRandomEx generator).

  • ->
  • -> RtlRandomEx routine is top left of the picture. “Extern variables are at the top right of the picture (there are 3 variables) and there is and Initialization routine of the seed that awfully looks like to the first generator!
    -> Constants used by this generator are the same to the previous one…
    -> In fact, the initialization routine can be seen as a few empty tours (about 0x200 = 0n512) of the generator.
    -> On x64 architecture, the implementation is similar.
  • Source : – (Signing a Driver for Public Release)

    Signing a driver package with two signatures

    In some cases, you might want to sign a driver package with two different signatures. For example, suppose you want your driver to run on Windows 7 and Windows 8. Windows 8 supports signatures created with the SHA256 hashing algorithm, but Windows 7 does not. For Windows 7, you need a signature created with the SHA1 hashing algorithm.

    Suppose you want to build and sign a driver package that will run on Windows 7 and Windows 8 on x64 hardware platforms. You can sign your driver package with a primary signature that uses SHA1. Then you can append a secondary signature that uses SHA256. You can use the same certificate for both signatures, or you can use separate certificates. Here are the steps to create the two signatures using Visual Studio.
  • Crypto Hot Cases – One Year Backward

    1. 1. Crypto Hot Cases One Year Backward The control of Technology in the Light of Snowden’s Leaks Eric Filiol & Baptiste David Operational cryptology and Virology Lab (C + V)O
    2. 2. Agenda • Introduction: The Past and Present Context – 70 years of Crypto control – Is Snowden really the first whistleblower? – The context • Case I – Connected People – Issues like RSA Dual_EC_DRBG, Bullrun, Heartblead, Google vs ANSSI… • Windows Oddities – Beyond vulnerabilities • Case II – Non Connected People/Non-classical Environments – Issues like TAO project and hardware bugs, sophisticated malware… • Conclusion – What will be the future? – How could we resist?
    3. 3. INTRODUCTION 70 years of Crypto Control – Snowden and Predecessors – The Context.
    4. 4. Introduction • A few weeks before Snowden’s first leaks, I wrote a long study about the control of technology including cryptology (presented later at HIP 2013) [1]. • In my past experience, I have exploited partly this control (mathematical backdoors) over cryptology for cryptanalysis purposes (in the context of Hans Buehler’s case). • This control is enforced since late 1940’s! So Snowden’s leaks are not really new ! – Vladimir Vetrov (aka Farewell) (1980) – Peter Wright’s “Spycatcher” (1985). Former MI5’s deputy director – Cryptome website – Many others…
    5. 5. 70 Years of Control • Since the end of WWII, cryptology is under control. This control has never weakened • UKUSA (5 eyes)/9 eyes/14 eyes – SIGINT Seniors Europe… • International Traffic in Arms regulations (ITAR, part 121) and subsequent regulations (Wassenaar…) – If cryptology is allowed/free of use, then it is under control. – 1997 is a key year (withdrawn from ITAR) and early 2000s in Europe: the rise of connected world. The control will be far easier (computer, OS, network…) • Cryptology is the most critical part in security: who is controlling cryptology, is controlling everything
    6. 6. The Context • The control techniques depend on the target context/environment Type Data NSA Programs Techniques Examples Connected Plaintext PRISM, Xkeyscore… Data collection, wiretapping, eavesdropping, agreements with industry/providers…. Google, Facebook, Apple, Microsoft (including Skype)… Ciphertext Bullrun/Edgehill… Malware, 0-day exploitation, random generator control, security standards control, controlling CAs, bugging software, applied cryptanalysis… Heartbleed, RSA, Google/ANSSI,, Alibaba… Connected by private network Ciphertext Cottonmouth, Godsurge, TOR attack, Quantum, Foxacid, Firework, Bulldozer… Malware, 0-day exploitation, random generator control, controlling CAs, security standards control, bugging software, hardware bugs, mathematical trapdoors… TOR network, Gasprom, Petrobras, French MFA, Aeroflot, Total. Airbus, SWIFT… Non-connected (offline) Ciphertext TAO, still unknown projects??? Tempest techniques, mathematical backdoors, hardware bugging, Humint Hans Buehler Case (1995). Gov, MIL, Sensitive companies
    7. 7. CASE I – SPYING CONNECTED PEOPLE Issues like Bullrun, RSA Dual_EC_DRBG, Heartblead, Windows oddities, Google vs ANSSI…
    8. 8. Bullrun Program • Goal: bypass operationnaly any cryptology protection • Applied cryptanalysis more that cryptanalysis – Tampering with national standards (NIST is specifically mentioned) to promote weak, or otherwise vulnerable cryptography (e.g Dual_EC_DRBG, AES ?) – Influencing standards committees to weaken protocols (or influencing to bar strong algorithms [Gost]) – Working with hardware and software vendors to weaken encryption and random number generators (Microsoft) – Attacking the encryption used by GSM phones. – Identifying and cracking vulnerable keys – Establishing a Human Intelligence division to infiltrate the global telecommunications industry – Bypassing SSL connections • Annual budget: 250 millions $ per year.
    9. 9. Dual_EC_RDBG – RSA B-Safe • Dual Elliptic Curve Deterministic Random Bit Generator (Dual_EC_DRBG). Used to generate random keys. ISO and ANSI standards • Used in many environments (Blackberry, SSL/TLS…) • Fixed choice of constants P and Q makes most of the backdoor (see many-flaws-of-dualecdrbg.html) • Shumow-Ferguson Crypto 2007 • Nobody knows where Dual_EC_RDBG parameters came from • In SSL/TLS, NSA can recover the pre-master secret (RSA handshake) easily
    10. 10. Dual_EC_RDBG Timeline • 2004 - RSA makes Dual_EC_DRBG the default CSPRNG in BSAFE • 2005 - ISO/IEC 18031:2005 is published, and includes Dual_EC_DRBG. The first draft of NIST SP 800-90A is released to the public, includes Dual_EC_DRBG • 2006 – 2007 – Works suggesting the existence of a NSA backdoor (K. Gjosteen, Berry Schoenmakers and Andrey Sidorenko, Shumow/Fergusson…) • June 2006 - NIST SP 800-90A is published, includes Dual_EC_DRBG with the defects pointed out by Kristian Gjøsteen and Berry Schoenmakers and Andrey Sidorenko not having been fixed. • June/Sep. 2013 – Snowden leak about Bullrun and Dual_EC_DRBG • 19 Sep. 2013 - RSA Security advises its customers to stop using Dual_EC_DRBG in RSA Security's BSAFE toolkit • Dec. 2013 - Reuters reports this is a result of a secret $10 million deal with NSA • April 21st, 2014, Following a public comment period and review, NIST removed Dual_EC_DRBG as a cryptographic algorithm from its draft guidance on random number generators, recommending "that current users of Dual_EC_DRBG transition to one of the three remaining approved algorithms as quickly as possible
    11. 11. Hot Issue • Specific subtle formulation in the NIST standard meant that you could only get the crucial FIPS 140-2 validation (Cryptographic Module Validation Program) of your implementation if you used the original compromised P and Q values • This includes the FIPS 140-2 statistical test suite (now NIST STS) which are THE de facto world standard for cryptography statistical evaluation/validation – Passing successfully the tests does mean your generator is secure • Up to me, FIPS 140-2 tests are “backdoored” (they are purposely non significant enough by not including a few additional testing techniques) • Issue of statistical test simulability (Filiol, 2006): “if I know your tests, I can simulate and bypass them” • Cryptography statistical validation should use a secret national process/set of tests (as it is the case in France)
    12. 12. Heartbleed • Buffer over-read vulnerability introduced by mistake in OpenSSL 1.0.1 (validated Dec. 31st, 2011, issued March 14th, 2012) • April 2014, vulnerability disclosed independently by Google and Codenomicon (CVE-2014-0160). Corrected by April 7th, 2014 • Enable to recover sensitive information through server memory leak (password, SSL keys…) • Many victims (Amazon, Github, hotmail, LibreOffice, McAfee, Password managers, Android 4.1.1, CISCO firmware, Juniper firmware, WD firmware…) • 30 000 X.509 certificates compromised while only a few revoked (source Netcraft)
    13. 13. • According to Bloomberg, NSA has exploited CVE-2014-0160 at least for 2 years • Exploitation of 0-day confirmed by the USA ( understanding-when-we-disclose-cyber-vulnerabilities) • Backdoor could be disguised as intended vulnerabilities/bugs (invoke the incompetence of programmers) • Most of the IT US firms communicate 0-day to NSA days before disclosure • They do not need to put backdoors, 0-days do the job (dynamic management of security holes) Heartbleed Issues
    14. 14. The GOOGLE vs ANSSI Case • On Dec. 2013. Google accused ANSSI (French Agency for ICS Security) to perform a MitM attack against Google services (e.g. Google, Gmail…) by using a rogue X509 Certificate signed by the French CA O=IGC/A • In fact, MINEFI (French Dept. of Treasure) was performing SSL Proxy forwarding to prevent leaks, malware attacks and to control traffic towards risky services (Gmail, Yahoo, Hotmail…) on its private network only! – MINEFI users were aware (internal security policy)
    15. 15. The GOOGLE vs ANSSI Case • The error lies in the fact that MINEFI used IGC/A certificates to sign external domains – It was not a MitM attack – ANSSI’s missions is devoted to Cyberdefense only
    16. 16. The GOOGLE vs ANSSI Case • The problem was not ANSSI/MINEFI but Google: – How Google detected the internal use of ANSSI certificates? – The only web browser used is Firefox • not Chrome (strictly forbidden). So no PK pinning was possible – The only explanation is the existence of some hidden mechanism inside Firefox that transparently sends information about certificates to Google! • Covert channel-like mechanism causing a security breach (maybe through the safe browsing mechanism to ? • Remind that Google has given millions of $ fund to the Mozilla foundation! – We have to take the greatest care of browsers in the future • This issue sheds also a new light on CA authorities. Who is controlling them?
    17. 17. WINDOWS ODDITIES Beyond vulnerabilities…
    18. 18. Are Vulnerabilities Really Necessary? • The design of systems can enable the use of dynamic resources that can – transparently, – without any evidence/traces let into the system, – for a limited period of time be added to the system with preemptive rights • Let us have a short journey into Windows for having an idea of what could be done • Used in Cryptographic Dynamic Backdoors (my talk at CanSecWest 2011) among many other possibilities • Everything occurs in memory only using legitimate Windows mechanisms
    19. 19. Shim Mechanism • What a shim is? o A shim is used in a context of backward compatibility o Windows operating system evolves from version to version: new technology added (ASLR, DEP…), bug fixes, modification in strategy… o It could lead to compatibility issues for a few software  In case of ASLR, if a software imported one function from Windows API by a fixed address (e.g. LoadLibraryA located at 0x7c801d77 in Kernel32.dll in Windows XP)  Some features of software were based on bugs (“it works by mistake” software)… If these ones are fixed, these applications will not remain the same o Shims simulate the behavior of older versions of Windows for legacy applications that rely on incorrect or deprecated functionality, or correct the way in which poorly written applications call unchanged APIs.
    20. 20. Shim Mechanism From a technical point of view: • One solution to keep backward compatibility is placing branches directly in the source code for Windows but it will not be a good solution (challenge for the serviceability and reliability of Windows source code) -> Shims were born ! • Technically, shim infrastructure implements a form of API hooking. It redirects API calls from Windows itself to alternative code—the shim itself. • This redirection is automatically performed from IAT section in the MZ-PE file format
    21. 21. Shim Mechanism Why using shim? • You can fix applications without access to the source code, or without changing them at all • Most people typically consider shims for applications where the vendor is out of business nor they don’t want to spent to much money in an update • Use it temporally will provide to users a shimmed and functional version which can bridge a gap until a compatible version is available • To make a transition between two major versions of Windows (XP to Seven) Shim is not always a solution: • The downside is that most vendors do not support shimmed applications. You cannot fix every application using shims.
    22. 22. Shim Mechanism How linking a shim to an application [6]?
    23. 23. Shim Mechanism What Microsoft tells you about: • It does not change security since: o Application redirected to the shim prior to calling Windows, the code that runs inside a shim still sits outside Windows. Consequently, Windows holds shim code to the same security restrictions as the application code itself o For example, no shim is available to bypass the Windows 7 UAC prompt while still running the application with elevated permissions. (…) The same is true for code that you write yourself o Therefore, when evaluating the security implications of using shims in your enterprise, you are not opening any additional security vulnerability. o Shims run as user-mode code inside a user-mode application process, you cannot use a shim to fix kernel-mode code • Shim Infrastructure, in essence, injects additional code into the application before it calls into Windows API, (…) [it] could be done by modifying the application code itself in fact
    24. 24. Shim Mechanism What must be understood (what Microsoft does not tell you): • Suppose an application ran using (willingly or not) a vulnerability in the Windows API (buffer overflow, execution from data or stack, ASLR…), if this one is fixed but the shim still allows the application to work with … what must be concluded? o Exploits on a specific software can be “maintained”… o It fixes vulnerabilities in Windows but it could add some in software  • This detour of API can be redirected to deprecated or undocumented API with less control checks than the regular one, even if Microsoft says no. • For encryption software, you can use redirection of specific API for bad purposes. If Windows encryption is used, it is possible at that point to add a bias in keys used (or send them to you). In fact, shim is just another legal hook • Even if this mechanism is not used for drivers, drivers are still MZ-PE executables and can/could be targeted by similar mechanisms in the future.
    25. 25. Perverting Windows Cryptography Context: Dynamic Cryptographic Backdoors (CanSecWest 2011) • The goal is to: o Trap cipher features in a software. o Change normal behavior of random generators o Force “outsourcing” of sensitive data  o Ask the “good” questions…  Once we have got access to cipher routines, we can read plaintext, modify cryptographic keys, modify cipher algorithm used on-the-fly (use a temporally weakest one), make sensitive data eavesdrop (plaintext, secret keys…) • Applied to and tested successfully with the AES in different environments
    26. 26. Perverting Windows Cryptography Attack of a software which externalizes its cipher routines • Either it can use its own library of cipher routines (.dll) • Or it can use Windows crypto API.
    27. 27. Perverting Windows Cryptography Attack of a software which externalize its cipher routines. Several methods to attack: • Hook/detour on the internal library of the software containing the cipher features of the software • Hook/detour the API of Windows used by the software (think about shims which can be used in such a case)
    28. 28. Perverting Windows Cryptography Attack of a software which uses its internal cipher routines • Since the cipher procedure is stored inside the software, it should not be possible to intercept every call as we did previously • But it is still possible to 1. reverse in order to locate cipher routines in the software 2. Create a Dll which is able to patch first op-codes of these routines to perform a jump operation inside routines in your Dll. This Dll will be injected in the targeted software and is supposed to “detour” the internal function to that inside it 3. Do whatever you want in your Dll and return the flow of execution to the process in the original routine • You can use a shim as a legitimate dll store/provider (everything occurs in memory only)
    29. 29. Perversion on Windows Cryptography Normal flow of execution Hijacked execution flow
    30. 30. Perverting Windows Cryptography Inside Windows crypto API • CryptProtectMemory function: protect some sensitive data in memory (e.g passwords) but strangely no password is required to manage this protection! • CryptUnprotectMemory function is used to retrieve information. Same prototype used to call the function • There is no key/entropy source field! False sense of security!
    31. 31. Perverting Windows Cryptography Where the password/keys is ??? • In fact, it is a source of entropy generated from kernel with some information available only in kernel mode (cookies, salt, creation time...) • Different possibility to use it: o CRYPTPROTECTMEMORY_SAME_PROCESS o CRYPTPROTECTMEMORY_CROSS_PROCESS o CRYPTPROTECTMEMORY_SAME_LOGON • The best protection is the one which deals with one process. In such a case, information is only valid fort the current process which calls this API. Any read access from other processes in its memory will see encrypted data • But, if you succeed at injecting code inside the process, you can read it normally • From kernel land, it is a piece of cake to read protected data.
    32. 32. Perverting Windows Cryptography Funny story about CryptProtectMemory • Story from • This API is very old (it has been introduced with XP/2003) • Lsass.exe stores all the password for windows when you log in • It seems that Microsoft tries hard to improve sensitive and historic routines.... but does not always use it! Under Windows 8 : Passwords are encrypted Under Windows 8.1 : Passwords are not!
    33. 33. Random Generation API in Ring 0 In many cases, it can be useful to access to random generator • In ring 0, at least two routines are available (are there more?): RtlRandom and RtlRandomEx. • From the Msdn documentation : o RtlRandom returns values that are uniformly distributed over the range from zero to the maximum possible LONG value minus 1 if it is called repeatedly with the same Seed. o The RtlRandomEx function is an improved version of the RtlRandom function that is twice as fast and produces “better” random numbers. • These routine could be used for : • Random event trigger : security software want to test something “sometime”… • A very bad random source for cryptography however…
    34. 34. Random API in Ring 0 Let us do “black box” tests with these generators to evaluate their real randomness quality • Let’s test generators with a fixed seed • We test on both generators evolution of seed and return value • Tests are launched twice with several seconds between them
    35. 35. Random API in Ring 0
    36. 36. Random API in Ring 0 • The seed of RtlRandEx is an accumulation of values and seeds of RtlRandom… • The values of RtlRandomEx are sometimes repeated • The two generators are not so different 
    37. 37. Random API in Ring 0
    38. 38. Random API in Ring 0 How does these generators really work? • The most simple one is the RtlRandom routine (x86 architecture) • Taken from ReactOs project (it works in a similar manner):
    39. 39. Random API in Ring 0 • RtlRandom routine is a weak linear congruential random number generator… v1 = seed; v2 = (2147483629*v1 + 2147483587) % 0x7FFFFFFFL; v3 = (2147483629*v2 + 2147483587) % 0x7FFFFFFFL; v1 = v3; return(v2); • This type of generator has been (publicly!!) broken many years ago (mid 90s)! • The RtlRandomEx routine is a bit less simplistic (but the two constants are the same) • From our study in black box, this is more or less the same generator. o It uses “variables” initialized and updated by the Windows kernel o The constants are contained in ntoskrnl.exe o It is although a weak linear congruential random number generator… o Since we know how extern values evolve, it can easily be broken/predicted • Conjecture: RtlRandom might be used to produce randomness for processes (salt, Process Color Seed...) or even used CryptProtectMemory function. • Code source available by contacted me • Analysis under progress… to be continued
    40. 40. Signing Driver Under Windows 7 Signing driver is a key-security point of windows • If you try to sign a driver under Windows 8 you need a SHA256 certificate • If you try to sign a driver under Windows 7 you need a SHA1 certificate From the msdn documentation : “In some cases, you might want to sign a driver package with two different signatures. For example, suppose you want your driver to run on Windows 7 and Windows 8. Windows 8 supports signatures created with the SHA256 hashing algorithm, but Windows 7 does not. For Windows 7, you need a signature created with the SHA1 hashing algorithm”. Question: Why Windows 7 (the most prevalent flavour of windows for the next 10 years) which uses same security mechanism from the kernel) needs to use deprecated technology to sign its drivers ?... Hypothesis: SHA-1 is fully under control while SHA-256 is not…yet!
    41. 41. Conclusion for this Part • You do not really need vulnerability when weak architecture design choice exist • It is obvious that there is a strong will not to provide a high-level security with respect to cryptography mechanism • Work under progress…to be continued…
    42. 42. CASE II – SPYING NON-CONNECTED PEOPLE/NON-CLASSIC ENVIRONMENTS Issues like TAO project and hardware bugs, sophisticated malware…
    43. 43. The Issue • How to target environments which are never connected to networks or non-classical environments (telex, fax, highly secure LAN, embedded crypto [ASICS]…)? – Either You need either a physical access (Peter Wright, 1987) – Or you need to have mathematical and/or hardware backdoors in those systems (especially for offline encryption) – Or use exotic approaches (Tempest, tempest-like techniques with malware, electronic warfare techniques…) • Tailored Access Operations (TAO), NSA Ant catalog • Refer to Appelbaum’s 30C3 talk [5]
    44. 44. • Revealed by Kaspersky (early 2014) but strangely no buzz at all • Sold to computer/smartphones/tablet manufacturers by the US Company Absolute as a legitimate tracking and remote control software • Spy software hidden in the Bios. Loaded at boot up • Every « infected » machine is potentially a botnet and allows many actions (remote code execution, data eavesdropping…) • Microsoft after reported it as malicious then decided to whitelist it in MSE (as well as for most AV vendors) • Technical details and list of brands/machines « infected » on Recent Case: Computrace/Lojack
    45. 45. What is possible ? • What Snowden did not reveal about (yet)? – Tempest like techniques. Former Soviet Union was the leading country for years and very likely still is – Use of very dynamic sophisticated malware • My talk at Black USA 2008 (using covert channels) • My talk at CanSecWest 2011(dynamic cryptographic backdoors) – Low-level hardware trapdoors (e.g. processors, dynamic microcode malicious updates…) – Mathematical trapdoors (encryption algorithms may be put into question after the dual_EC_RDBG case with respect to standardization entities)
    46. 46. CONCLUSION What will be the future ? How to resist?
    47. 47. Conclusion • Techniques presented here are classical approaches and are known for a very long time – Snowden did not reveal anything really new (at least regarding technical aspects) – The issue is: “what about now and tomorrow?” • The strength of the USA is their monopoly over technology (Intel, Microsoft…), services (Facebook, Google, FedEx…) business (in IT, the US market is nearly 45 % of the world market). The real power comes from the commercial power and the political will • The weight of standards (ISO, ANSI, IEEE) is prevalent. Non US countries must operate at the standardization level or even must create non US-driven standardization organizations AND give birth to a world economic competitor (Europe + Russian Federation) – A political issue more than a technical issue
    48. 48. Conclusion • Cryptography must no longer be the unique solution – When you encrypt you send noise! Then you are visible! • The solution is to generalize the use of steganography especially for network communications. – Unsuspected contents cannot be targeted! • Web browsers become more and more critical software (CAs management) – Most countries should develop their own trusted browser • Hardware must also be taken into account • Other actors than USA and their allies must also be considered (e.g. China)
    49. 49. Credits • Thanks to Kevin, Jan-Agust and Sébastien for their support while preparing this talk
    51. 51. References [1] Eric Filiol "La face cachée de la sécurité informatique ou les dessous d'Internet". Club des Vigilants, 14 février 2013 (in French). Presented at HIP 2013 and published in Journal in Information Warfare, Vol. 12, Issue 3, October 2013 [2] Peter Wright “Spycatcher: The Candid Autobiography of a Senior Intelligence Officer”, Penguin Viking, 1987. [3] fascism-nsa-cia-fbi-have-secret-agreements-with-private-companies-such-as- microsoft-and-mcafee/ [4] part-2-bulldozer/ [5] Jakob Appelbaum. “To Protect and Infect – The Militarization of the Internet”, 30C3, Dec. 2014 [6] About Shim. using-the-app-compat-toolkit-to-make-your-old-stuff-work-with-your-new-stuff.aspx