Pages:
Author

Topic: Hack my site, receive bitcoins - page 2. (Read 2695 times)

sr. member
Activity: 350
Merit: 250
June 19, 2013, 05:00:38 PM
#20
I'll take a look into this, but it wouldn't explain why the hacker didn't cleanly deface the main page and left some odd escaped tags - this is what leads me to believe it was done ONLY using the form.


if he was using the form then he used sql injection which i  provided the fix above for.
no new data in the database asking with permanently modifying the page says otherwise.

 Is apache the only other potential beach?
sr. member
Activity: 252
Merit: 250
June 19, 2013, 02:51:32 PM
#19
I'll take a look into this, but it wouldn't explain why the hacker didn't cleanly deface the main page and left some odd escaped tags - this is what leads me to believe it was done ONLY using the form.


if he was using the form then he used sql injection which i  provided the fix above for.
legendary
Activity: 1274
Merit: 1004
June 19, 2013, 02:47:34 PM
#18
I'll take a look into this, but it wouldn't explain why the hacker didn't cleanly deface the main page and left some odd escaped tags - this is what leads me to believe it was done ONLY using the form.
You can check server logs to know what he did.
sr. member
Activity: 350
Merit: 250
June 19, 2013, 02:40:09 PM
#17
sr. member
Activity: 252
Merit: 250
June 19, 2013, 02:31:35 PM
#16
sr. member
Activity: 350
Merit: 250
June 19, 2013, 02:28:26 PM
#15
sr. member
Activity: 252
Merit: 250
June 19, 2013, 02:20:28 PM
#14
I will give it a try later today.. Sure it was done through the form and not through FTP?
Nearly positive. I was told by the hacker it was done through the login form. First he modified the login page, then probably grabbed my SQL login through a similar manner.
Or... that's just a red herring. I highly doubt a SQL exploit can modify web pages.
I never said it was an SQLi. I just know it used the login form that uses an SQL database, and he just managed to grab my SQL info for other purposes after breaking my form.
do you have brute force protection as well? because someone can just run bruteforce until it pops a correct user and pass.
That isn't the issue here.


derp sorry. to me it sounds like sql injection just put this at the header of every page and that will reject those requests and log their ip and the string they tried to use. Also are you running this website from home using apache?

Code:
$ip $_SERVER['REMOTE_ADDR'];
$time date("l dS of F Y h:i:s A");
$script $_SERVER[PATH_TRANSLATED];
$fp fopen ("[WEB]SQL_Injection.txt""a+");
$sql_inject_1 = array(";","'","%",'"'); #Whoth need replace
$sql_inject_2 = array("""","","""); #To wont replace
$GET_KEY array_keys($_GET); #array keys from $_GET
$POST_KEY array_keys($_POST); #array keys from $_POST
$COOKIE_KEY array_keys($_COOKIE); #array keys from $_COOKIE
/*begin clear $_GET */
for($i=0;$i<count($GET_KEY);$i++)
{
$real_get[$i] = $_GET[$GET_KEY[$i]];
$_GET[$GET_KEY[$i]] = str_replace($sql_inject_1$sql_inject_2HtmlSpecialChars($_GET[$GET_KEY[$i]]));
if(
$real_get[$i] != $_GET[$GET_KEY[$i]])
{
fwrite ($fp"IP: $ip\r\n");
fwrite ($fp"Method: GET\r\n");
fwrite ($fp"Value: $real_get[$i]\r\n");
fwrite ($fp"Script: $script\r\n");
fwrite ($fp"Time: $time\r\n");
fwrite ($fp"==================================\r\n");
}
}
/*end clear $_GET */
/*begin clear $_POST */
for($i=0;$i<count($POST_KEY);$i++)
{
$real_post[$i] = $_POST[$POST_KEY[$i]];
$_POST[$POST_KEY[$i]] = str_replace($sql_inject_1$sql_inject_2HtmlSpecialChars($_POST[$POST_KEY[$i]]));
if(
$real_post[$i] != $_POST[$POST_KEY[$i]])
{
fwrite ($fp"IP: $ip\r\n");
fwrite ($fp"Method: POST\r\n");
fwrite ($fp"Value: $real_post[$i]\r\n");
fwrite ($fp"Script: $script\r\n");
fwrite ($fp"Time: $time\r\n");
fwrite ($fp"==================================\r\n");
}
}
/*end clear $_POST */
/*begin clear $_COOKIE */
for($i=0;$i<count($COOKIE_KEY);$i++)
{
$real_cookie[$i] = $_COOKIE[$COOKIE_KEY[$i]];
$_COOKIE[$COOKIE_KEY[$i]] = str_replace($sql_inject_1$sql_inject_2HtmlSpecialChars($_COOKIE[$COOKIE_KEY[$i]]));
if(
$real_cookie[$i] != $_COOKIE[$COOKIE_KEY[$i]])
{
fwrite ($fp"IP: $ip\r\n");
fwrite ($fp"Method: COOKIE\r\n");
fwrite ($fp"Value: $real_cookie[$i]\r\n");
fwrite ($fp"Script: $script\r\n");
fwrite ($fp"Time: $time\r\n");
fwrite ($fp"==================================\r\n");
}
}

/*end clear $_COOKIE */
fclose ($fp);
?>


sr. member
Activity: 350
Merit: 250
June 19, 2013, 02:14:47 PM
#13
I will give it a try later today.. Sure it was done through the form and not through FTP?
Nearly positive. I was told by the hacker it was done through the login form. First he modified the login page, then probably grabbed my SQL login through a similar manner.
Or... that's just a red herring. I highly doubt a SQL exploit can modify web pages.
I never said it was an SQLi. I just know it used the login form that uses an SQL database, and he just managed to grab my SQL info for other purposes after breaking my form.
do you have brute force protection as well? because someone can just run bruteforce until it pops a correct user and pass.
That isn't the issue here.
sr. member
Activity: 252
Merit: 250
June 19, 2013, 02:05:22 PM
#12
do you have brute force protection as well? because someone can just run bruteforce until it pops a correct user and pass.
legendary
Activity: 2058
Merit: 1431
June 19, 2013, 02:02:58 PM
#11
I will give it a try later today.. Sure it was done through the form and not through FTP?
Nearly positive. I was told by the hacker it was done through the login form. First he modified the login page, then probably grabbed my SQL login through a similar manner.
Or... that's just a red herring. I highly doubt a SQL exploit can modify web pages.
sr. member
Activity: 308
Merit: 250
verified ✔
June 19, 2013, 01:43:40 PM
#10
Not sure if just Social Engineering
sr. member
Activity: 350
Merit: 250
June 19, 2013, 01:39:11 PM
#9
I will give it a try later today.. Sure it was done through the form and not through FTP?
Nearly positive. I was told by the hacker it was done through the login form. First he modified the login page, then probably grabbed my SQL login through a similar manner.
newbie
Activity: 31
Merit: 0
June 19, 2013, 01:20:27 PM
#8
I will give it a try later today.. Sure it was done through the form and not through FTP?
sr. member
Activity: 350
Merit: 250
June 19, 2013, 01:16:01 PM
#7
Perhaps it's something else.

http://httpd.apache.org/security/vulnerabilities_22.html

Here there seems to be some documented vulnerabilities for the version of the webserver you are running. Perhaps that's why and perhaps you should update to the latest version?
I'm fairly certain the exploit uses my login form and not an apache exploit.
sr. member
Activity: 406
Merit: 250
June 19, 2013, 01:12:25 PM
#6
Perhaps it's something else.

http://httpd.apache.org/security/vulnerabilities_22.html

Here there seems to be some documented vulnerabilities for the version of the webserver you are running. Perhaps that's why and perhaps you should update to the latest version?
sr. member
Activity: 350
Merit: 250
June 19, 2013, 12:38:31 PM
#5
Were the credentials for the database the same as credentials for ssh or any other file server running?
No.
sr. member
Activity: 406
Merit: 250
June 19, 2013, 12:34:11 PM
#4
Were the credentials for the database the same as credentials for ssh or any other file server running?
sr. member
Activity: 350
Merit: 250
June 19, 2013, 12:29:50 PM
#3
Have you got input sanitation in place? I think the method they used was simply SQL Injection. I can't test, though, since the database is either offline or the form php file isn't configured correctly. But you just have to prevent SQL injection by sanitizing the input.

Php.net has a huge article all about it.

http://php.net/manual/en/security.database.sql-injection.php

Shows common attacks, and the solution.

"Never connect to the database as a superuser or as the database owner. Use always customized users with very limited privileges."

Sanitize anything coming from the client that you're going to insert into a database using mysqli_real_escape_string.

PHP.Net documentation for that here
http://www.php.net/manual/en/mysqli.real-escape-string.php

The was the first thing I took a look at. No changes in the database, and even if they were, I don't see how it would cause the page itself to be modified on load pre-login.
sr. member
Activity: 406
Merit: 250
June 19, 2013, 12:27:04 PM
#2
Have you got input sanitation in place? I think the method they used was simply SQL Injection. I can't test, though, since the database is either offline or the form php file isn't configured correctly. But you just have to prevent SQL injection by sanitizing the input.

Php.net has a huge article all about it.

http://php.net/manual/en/security.database.sql-injection.php

Shows common attacks, and the solution.

"Never connect to the database as a superuser or as the database owner. Use always customized users with very limited privileges."

Sanitize anything coming from the client that you're going to insert into a database using mysqli_real_escape_string.

PHP.Net documentation for that here
http://www.php.net/manual/en/mysqli.real-escape-string.php
sr. member
Activity: 350
Merit: 250
June 19, 2013, 12:03:19 PM
#1
http://198.12.67.18/test

A few days ago someone got into my server, got my SQL credentials (located @ config.php), and modified some files and other shenanigans using the login form above.

I'm unsure how it was done and I'd like to know if someone could hack it again. I'm not offering much - 0.05BTC - but the coins are yours for repeating what he did and letting me know how it was done.

It only took them a couple minutes, and the form there should be enough.

The exploit uses login.php.
Pages:
Jump to: