Authentication Bypass in GINA (Graphical Identification and Authentication DLL) replacements

MSGINA.DLL is a dynamic link library called by the Winlogon process that is responsible for presenting the user with the familiar Windows login prompt. There are MANY third party systems on the market today that either replace MSGINA or insert themselves into the login process using “gina chaining”. Examples, of such products include most password self service systems, biometric and other two factor authentication systems, and VPN clients that establish your network connection before the normal login process occurs.
Recent experience has led me to believe that many of these systems may be vulnerable to authentication bypass attacks. You walk up to the machine and without entering any username or password you have a full access to the computer. In this image (IMAGE1) you see a print screen taken from a system that suffers from just such a problem.

View larger image
IMAGE1
Although the Windows login prompt generated by the vendor GINA is still on the screen we are able to get a full interactive desktop and, as the name on the Start Menu illustrates, we are running under the all powerful system account. How could this happen? Easy, when a software developer either replaces or chains Microsoft’s MSGINA.DLL they have be be very careful to restrict what the user can do within their new GINA. A permissive GINA gives an unauthenticated user full access to the machine. For example, last month Tyler Spivey found a bypass in “JAWS”. JAWS is a screen reader application for the visually impaired. You can read about what Tyler found here.
Similarly, if you have a password self service system that replaced your GINA with a new gina that included a “Forgot Password” button, you may have a problem. Imagine that the Forgot Password button launches a web browser that takes you to a website where the user can reset their password. Imagine further, that the GINA developers simply used a visual studio browser object that was based on Internet Explorer when developing their GINA. If they do not prevent the user from viewing the source on the website (Right-Click-> View Source) an attacker is given access to NOTEPAD.EXE. From there an attacker simply has to select “FILE->OPEN”, browse to “C:WINDOWSSYSTEM32CMD.EXE”, Right-Click on it and select “OPEN” to get a command prompt WITHOUT logging in to the system. Whats more, if the attacker wants a full interactive desktop they could simply type “START USERINIT” from the command prompt to launch the normal windows process that gives them their desktop. The developer may have thought to disable the “RIGHT CLICK” functionality to allow you to view source, but overlooked keyboard combination to do the same such as SHIFT-F10, CONTROL-SHIFT-F10, ALT-SHIFT-F10, etc. The end result is, doing a secure GINA replacement properly isn’t easy. There are a lot of opportunities for error. After mentioning these types of attacks in a SANS 401 class I taught in Charleston, one of the students checked and discovered a similar bypass in a GINA replacement they use a work. Do you have a GINA replacement? Take a few minutes to check it out, you may be surprised by what you find.
Here are some tips when considering a GINA replacement product
1)Don’t. Avoid it if you can.
2)If you must, use GINA chaining instead of replacements. A full GINA replacement must replace all the informative screens in MSGINA.DLL including the “Now Applying Group Policy Settings” and “Installing 1 of 400 software patches and shutting down, DO NOT POWER OFF”. A GINA that fails to implement these important screens will likely result in impatient users powering off machines during software updates and corrupting their OS installations.
3)Thoroughly test the GINA going through EVERY screen, paying special attention to keyboard shortcuts, to see if you can get a standard windows File dialog box. If you can, you’ve got trouble.
4)For Vista and better, consider using systems that use Microsoft’s hybrid credentials provider API’s rather than a GINA replacement. Does this solve the problem? Probably not, I think developers can still develop unsecured login processes, but I liken it to using Parameterized SQL Statements as opposed to building SQL statements and executing them. The rigor enforced by the API calls gives you a better chance of success.
As always, practice responsible disclosure (Image2)

View image
(Image2)
-Mark Baggett