2

When checking the logfiles of some of my customers I found this as username for authenticated users. We have a .htusers file used for basic web auth, all other users in the serverlog I found in the .htusers, but not the @^Y@.@{phqsp~{2'/2|pq{jvk@-1('@lvo)&1--1.(/1)'@./* user.

Server version is 2.2.22 on 64b Opensuse 12

First question: was this user able to receive the content protected by the .htusers file?

Next one: anyone having more information about this break-in attempt? I found nothing on Google except lots of access-logs from all over the world.

Edit: Just to add the logentries:

x.y.z.x - @^Y@.@{phqsp~{2'/2|pq{jvk@-1('@lvo)&1--1.(/1)'@./* [06/Jan/2013:16:53:16 +0000] "GET xxxxxxxxxxxxxxx HTTP/1.1" 200 676 "xxxxxxxxxxxxxxx" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11"

x.y.z.x - @^Y@.@{phqsp~{2'/2|pq{jvk@-1('@lvo)&1--1.(/1)'@./* [06/Jan/2013:16:53:16 +0000] "GET xxxxxxxxxxxxxxx HTTP/1.1" 200 523 "xxxxxxxxxxxxxxx" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11"

x.y.z.x - @^Y@&@{phqsp~{2'/2|pq{jvk@-1('@lvo)&1--1.(/1)'@./* [06/Jan/2013:16:57:47 +0000] "GET xxxxxxxxxxxxxxx HTTP/1.1" 200 11 "xxxxxxxxxxxxxxx" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11"

P.S.
  • 33
  • 5

1 Answers1

0

I think there's some bad news if the xxxxxx'ed-out ressources are located in the protected area. The http status code 200 in your logs tells that your server has happily sent out the ressource to the client x.y.z.x. If basic-auth had failed in any way, a 401 (forbidden) would have been returned instead.

The number next to the 200 tells you how many bytes have been sent in the answer. Check if the ressources behind the xxxxxx'es are actually 676, 523 and 11 bytes in size for another hint if the data was successfully accessed.

Update / Solution:

As it turned out in the comments, the mentioned accesses were to ressources in unprotected areas, thus resulting in http status code 200 (OK). The confusing fact that a unknown user name is shown in the logs is due to the possibilty to set the "Authorization" header in a http request regardless of whether authorization was requested by the server at all or whether the username is known on the server. So apparently this is the work of some webcrawler or bot having set the auth header by default. Maybe innocent, maybe not, but obviously not as harmful as it seems at a first glance to the logfile.

Karma Fusebox
  • 1,114
  • 9
  • 18
  • The funny thing is: the resources behind the xxx are not protected by the basic auth, much more they are public accessible. There was no single request on protected resources at that time. – P.S. Jan 24 '13 at 08:40
  • Well, you could have saved us some time if you had mentioned that in first place. See [this link](http://en.wikipedia.org/wiki/Basic_access_authentication#Protocol). If the _Authorization_-Header is set in the http request, its supplied credentials are displayed in your logfile even if there was no authorization requested at all. – Karma Fusebox Jan 24 '13 at 20:45
  • Sorry, you are right - I found that is important, when I added the logfile entries to the question! Does this mean I don't have to worry, since there was probably no break-in attempt? – P.S. Jan 25 '13 at 11:50
  • Yes. As long as your logfile shows no unknown access to a _protected_ ressource resulting in a http status code 200 you don't need to worry much. In fact, you can try it out yourself with the example from wikipedia: `wget -O - --header="Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==" yourdomain.net/somefile` will result in log entries mentioning the "Aladdin" user even though you have no such name in your user lists. So in conclusion, that garbage user name from your question is most probably some crawler or bot that comes along with the auth header set by default. For whatever reason. – Karma Fusebox Jan 25 '13 at 14:06
  • Absolutely great, thanks for your help. **Appreciated!** – P.S. Jan 25 '13 at 17:30