Common IIS misconfigurations: HTTP Basic Authentication
In my last post I talked about a common mistake of IIS administrators consisting in modifications of default directory permissions.
Today I’m going to talk about another common mistake. Allow HTTP Basic authentication.
The Standard IIS supports 4 kinds of HTTP Authentication:
- Basic authentication
- Digest authentication for Windows domain servers
- Integrated Windows authentication
- .Net Passport authentication
When HTTP authentication is set up on a resource, by default only Windows authentication is checked in. But some administrators also activate Basic authentication because of compatibility reasons or because of ignorance.
Basic authentication is flawed by itself. It doesn’t encrypt the user credentials so they can be intercepted.
If we use a SSL protected HTTP connection we reduce the risk of using Basic Authentication, but on IIS we have another risk.
The IIS implementation of HTTP allows burst requests for speed reason. We can establish a HTTP/1.1 connection with keep-alive and send thousands of requests without waiting for the response.
Windows or Digest authentications are challenge-response based. So we can’t send burst requests. We have to wait for the challenge to come and then send the response.
Instead, Basic authentication is a one-shot request. This way we can achieve a very fast method of brute-forcing user credentials.
In LAN environments we can get rates of hundreds of tried words per second. We can reach the maximum rate of authentications allowed by the LSASS service. The bottleneck is in the LSASS itself, not in the network.
The CPU usage in the server reaches 100% during the attack:
Stopping brute-force authentication attacks is easy by implementing account lockouts, but most administrators still don’t use this kind of (almost) mandatory security measure.
Ramon Pinuaga Cascales
Dept. Auditoria S21sec