Sign in to follow this  
Followers 0
asmith

Erasing Logs from a Https Site

7 posts in this topic

Say hypothetically that you had a list of 30 (my random number) possible combinations of username/password to log onto a https site that never times you out no matter what you do and you know 100% that for sure one of the ten were certain to work … but when the system admin checked back later that day obviously seeing thirty attempts with one success would be a red flag – how would you go about wiping the logs. I would never even want/feel/be dumb enough to do this and I know that if spotted would make the attack 100x’s more suspect … hypothetically how would you do this for this scenario.

0

Share this post


Link to post
Share on other sites

Say hypothetically that you had a list of 30 (my random number) possible combinations of username/password to log onto a https site that never times you out no matter what you do and you know 100% that for sure one of the ten were certain to work … but when the system admin checked back later that day obviously seeing thirty attempts with one success would be a red flag – how would you go about wiping the logs. I would never even want/feel/be dumb enough to do this and I know that if spotted would make the attack 100x’s more suspect … hypothetically how would you do this for this scenario.

Apache's logs are usually kept in /var/log/apache or /var/log/http, the webserver part that serves you the pages will have absolutely NO access to these directories. The only way to erase the evidence in the logs is to be root on the server... and if your root on the server, you don't need to bruteforce.

Now, how about a more 'subtle' approach? Try timing the request/logins rather far apart, at random intervals. Try using different proxies or Tor to do it.

0

Share this post


Link to post
Share on other sites

use tor or something and do an attempt like every 10 minutes, that way it is not suspicious and it is from a different IP.

Hacking is about patience.

0

Share this post


Link to post
Share on other sites

You could always take the other route and overflow the logs with millions of other entries. Of course, at 2 gig per log file that might take just a little while.

0

Share this post


Link to post
Share on other sites
Apache's logs are usually kept in /var/log/apache or /var/log/http, the webserver part that serves you the pages will have absolutely NO access to these directories. The only way to erase the evidence in the logs is to be root on the server... and if your root on the server, you don't need to bruteforce...

Correct, but does Apache (or IIS, for argument's sake) keep track of login errors associated with a web form? I'm pretty sure those will show htaccess errors, but not necessarily errors associated with a custom web application that has a login form. Of course, in all likelyhood, the sysadmins could just look at the hits for the "Access Denied" page in the typical /var/log/apache, which blows my own counter-point out of the water. :D

My point is, WHAT are you brute forcing? A web form? Or a generic login box (it will pop-up as a login box for specific to your brower, here's what Firefox's looks like:

fox7.gif

In the case of a web form, login errors go wherever the developer decides the program should put them (unless the dev is a slack-ass like a few I know, and can't spell the word "log"). In the case of the password prompt above, which is usually a login associated directly with the web server, they go into the systems logs.

Edited by Dirk Chestnut
0

Share this post


Link to post
Share on other sites

No one here has hear of grep before. makes looking at log and other misc text files alot easier.

0

Share this post


Link to post
Share on other sites

No one here has hear of grep before. makes looking at log and other misc text files alot easier.

classic :D

Assuming the information is logged:

Supersaturating logs with entries won't do anything. It'll just make the intrusion that much more obvious.

They'll still be able to quickly find out which accounts were accessed and whatnot.

So really, the trick is to not leave any evidence to begin with.

Using multiple IPs (through TOR or proxies) to try accounts would be one way for the traffic to blend in with the normal stuff,

and in a circumstance like this would likely be the best approach.

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0