Polkadot JAM Slides - Token2049 - By Dr. Gavin Wood
Crypto Hot Cases – One Year Backward
1. Crypto Hot Cases
One Year Backward
The control of Technology in the Light of
Snowden’s Leaks
Eric Filiol efiliol@netc.fr
&
Baptiste David
Operational cryptology and Virology Lab (C + V)O
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?
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. 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. 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, Mail.ru,
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. CASE I – SPYING CONNECTED PEOPLE
Issues like Bullrun, RSA Dual_EC_DRBG, Heartblead, Windows oddities, Google vs
ANSSI…
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. 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 http://blog.cryptographyengineering.com/2013/09/the-
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. 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. 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. 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. • According to Bloomberg, NSA has exploited CVE-2014-0160 at
least for 2 years
• Exploitation of 0-day confirmed by the USA
(http://www.whitehouse.gov/blog/2014/04/28/heartbleed-
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. 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. 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. 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
sb.google.com/safebrowsing/update?version=goog-black-url:1:1) ?
• 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?
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. 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. 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. 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.
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. 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. 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. 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. 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. 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)
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. 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. Perverting Windows Cryptography
Funny story about CryptProtectMemory
• Story from http://blog.gentilkiwi.com/tag/cryptprotectmemory
• 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. 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. 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
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
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. 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. 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. 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. CASE II – SPYING NON-CONNECTED
PEOPLE/NON-CLASSIC ENVIRONMENTS
Issues like TAO project and hardware bugs, sophisticated malware…
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. • 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
http://korben.info/computrace-lojack-absolute.html
Recent Case: Computrace/Lojack
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)
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. 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. Credits
• Thanks to Kevin, Jan-Agust and Sébastien for
their support while preparing this talk
50. THANKS FOR YOUR ATTENTION!
СПАСИБО ЗА ВНИМАНИЕ!
QUESTIONS & ANSWERS - ВОПРОСЫ И ОТВЕТЫ
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] http://emergingtruth.wordpress.com/2013/06/16/is-this-the-early-signs-of-
fascism-nsa-cia-fbi-have-secret-agreements-with-private-companies-such-as-
microsoft-and-mcafee/
[4] http://resources.infosecinstitute.com/nsa-bios-backdoor-aka-god-mode-malware-
part-2-bulldozer/
[5] Jakob Appelbaum. “To Protect and Infect – The Militarization of the Internet”, 30C3,
Dec. 2014
[6] About Shim.
http://blogs.technet.com/b/askperf/archive/2011/06/17/demystifying-shims-or-
using-the-app-compat-toolkit-to-make-your-old-stuff-work-with-your-new-stuff.aspx
Notas del editor
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 : http://blogs.technet.com/b/askperf/archive/2011/06/17/demystifying-shims-or-using-the-app-compat-toolkit-to-make-your-old-stuff-work-with-your-new-stuff.aspx
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 : http://msdn.microsoft.com/en-us/library/windows/hardware/hh967734(v=vs.85).aspx – (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.