Skip to main content

When authentication is not really an authentication

When authentication is not really an authentication- just identity. We'll talk about a design flaw.
Identity is just identification of entities such as a person, object etc- who they are. But when it comes to prove that who they are, the entities must supply some sort of credentials, such as passwords, certificates etc to prove their identity claim.
Let's consider a hypothetical app which is thick client and 2-tier (which is never a good idea), but let's think about it. It has got following design:

1.The UI is protected by a login screen which requires AD (Windows) authentication of logged in user. The login screen is a separate exe.
2. Once the user is authenticated, a separate UI exe is launched with the logged in user's privilege.
3. The same login screen also provides details of the DB to be connected by this app once the authentication is successful.

What risks we see here apart from the traditional 2-tier risks such as decompiling, business logic at client side, sensitive info in memory etc etc.

From the architectural point of view, we can list down the below risks:

The login exe first accepts logged in user's supplied password and 'authenticates' him/ her with AD. Once successfully authenticated, the login UI launches the the main UI withe logged in user's privilege. Now since they are two different UIs and first one launches the 2nd one, the first one really authenticates the user and the second one just check the id of the logged in user to fetch the relevant privileges to launch the UI.

The noticeable thing here is the second UI is just launched with the privilege of logged in user's id. It really does not perform any authentication on its own, only the the first UI does and once it decides it's valid user, it launches the second UI with the logged in user's id. If we somehow try to invoke the second UI directly, there's no use of authentication, we can still fetch the UI and privilege using logged in user's id. So if we go to second UI's properties to fetch the command and directly executes it to launch the 2nd UI, we are bypassing the authentication screen and using the identification of logged in user.

If an app is designed like that we can easily bypass the authentication, which gives false sense of security that the user has to supply passwords in order to access the second UI.

Another issue with this architecture is, windows auth to the db. It's quote possible to directly connect the db using any other sql client and bypassing the business layer.

Comments

Popular posts from this blog

SQL Injection in search field

Earlier I had written about performing SQL injection in search field and how to do a DoS attack and privilege escalation using 'Like' operators. Now another SQLi exploitation I came across recently. That too in the search field. This becomes important as lots of people don't pay much attention on the search forms/ fields in the application. My aim is to show that a search form can also be exploited with SQL Injection. The following queries are based on a real world exploitation. The steps and data are for just illustration purpose only. Suppose, the search form provides the details of users who have accessed the application some time and their login time details etc, we just need to provide their name in the search box provided. All the data were being going as Post request. So, to just fingerprint the database, I provide, 'nil'+'esh' in the search field and it successfully gives me the results. That means the database behind the application is concatenat…

File Upload through Null Byte Injection

Sometimes, during file upload we come across situation wherein there would be check on the file extension at the client side as well as server side too. If the application does allow only .jpeg extension to be uploaded, the client side java script checks for the extension of the file before passing the request. We all know that how easily this can be defeated.
Some applications, checks for the extension at the server side also. That's not easy to bypass. However there are some ways with which it still can be bypassed. Most of server side scripts are written in high level languages such as Php, Java etc who still use some C/C++ libraries to read the file name and contents. That leads to the problem. In C/C++ a line ends with /00 or which is called Null Byte. So whenever the interpreter sees a null byte at the end of the a string, it stops reading thinking it has reached at the end of the string.
This can be used for the bypass. It works for many servers, specially php servers. Th…

Insecure protocols

Some basic insecure protocols and risk associated with them: