4

I'm also putting up the contents of the .aspx file that was uploaded. When I try to access it, I get prompted for a password, looking at the code, there's a harcoded password but it looks like some MD5 encryption is going on and I can't get in to look at what is behind the password protection on this hackers page. Can someone help with getting past the password protection?

Their file was called wjose.aspx and the I've pasted the code into jsbin for easy viewing: http://jsbin.com/uhoye3/edit#html

I've already got a server/host based version of the question on serverfault.com asking for steps to prevent this in the future: https://serverfault.com/questions/206396/attempted-hack-on-vps-how-to-protect-in-future-what-were-they-trying-to-do

Community
  • 1
  • 1
Moin Zaman
  • 25,281
  • 6
  • 70
  • 74
  • As you are updating your site via a CMS, Web Masters might be a better place for some parts of this question. – ChrisF Nov 26 '10 at 20:30
  • 3
    Do you not think it would have been good to limit the uploads before this happened? Never ever trust user input. – Elliott Nov 26 '10 at 20:35
  • Maybe related to http://weblogs.asp.net/scottgu/archive/2010/09/18/important-asp-net-security-vulnerability.aspx ... just a recent one I know about. – Richard Anthony Hein Nov 26 '10 at 20:35
  • 1
    Richard - this is unrelated to the ASP.NET attack of a few months ago. That attack was a fundamental flaw in ASP.NET's cryptographic algorithms. This particular question is about an incorrectly configured CMS. Whitelisting valid file extensions and having a Web.config entry that prevents executing scripts would solve this problem. – Levi Nov 26 '10 at 20:39
  • 5
    I'm not sure I understand the programming question part of this. The security issue here is that files uploaded by users should not go to a location where they can be executed by the web server. – mlibby Nov 26 '10 at 20:40
  • I think it's pretty obvious that the programming question is how to use code and configuration to prevent the issue from happening again. – Joseph Yaduvanshi Nov 26 '10 at 20:42
  • If you look at the code, you should do a whois against the .com and contact the authorities. – Joseph Yaduvanshi Nov 26 '10 at 20:45
  • just curious, are u using dnn prior to 4.9.0? coz it has similar security hole – Arief Nov 26 '10 at 20:50
  • If you're looking for how to solve this problem programmatically, then your question is too vague for an answer. – John Saunders Nov 26 '10 at 20:55
  • Guys, 1 part of it atleast is a secific programming question, i.e. how do I get past the password protection on that .aspx page to see whats in there? – Moin Zaman Nov 26 '10 at 21:01
  • I'm also reaching out to folks to help and trap these wankers as they still seem to be trying to do stuff. Not sure how or where I can get that sort of help? – Moin Zaman Nov 26 '10 at 21:03
  • Edit the question to be just that part and I'll vote to reopen if it still gets closed. – ChrisF Nov 26 '10 at 21:04
  • The most important thing is to ensure that if you have any upload areas, those areas are prevented from having any executable files within them. If the area is web accessible and the uploads can be anything - all they need do is upload an aspx/php/etc script to that location and navigate to it to activate. Prevent this by: renaming files on upload; checking the file type by **content** before you move it to the location; setup your webserver not to allow scripts to execute within that location; if the upload location does not need to be web accessible, move it outside. – Orbling Nov 26 '10 at 21:14
  • Did you try the password at the top of the script? What happened? Did you try it while running the page in a debugger? What did you find? This is not a programming question at this point. – mlibby Nov 26 '10 at 21:23
  • I mean, as far as I can tell, if comment out `if (!pdo()) { return; }` it simply won't check whether you're authenticated. You can also modify xVm to send out a cookie with an unmodified password in it. – mlibby Nov 26 '10 at 21:28
  • Just google for ASPXSPY and there are plenty of discussions and it looks fixes as well. – H H Nov 26 '10 at 22:03
  • [for your reference](http://stackoverflow.com/questions/72394/what-should-a-developer-know-before-building-a-public-web-site) – default Nov 29 '10 at 17:01
  • 3
    md5('jose2859') = 'e01a7e40f6ee1461d2737c4f627a095a' – sisve Nov 29 '10 at 17:34

2 Answers2

8

If you running asp.net and only as you tagged, then you only need to add this web.config on the root directory that your users upload files. With that web.config you do not allow anyone to run aspx pages on this directory tree.

The web.config on the protected must only contains:

<configuration>
    <system.web>
      <authorization>
        <deny users="*" />
      </authorization>
    </system.web>
</configuration>

With this web.config your program can still read and write images and other files on this directory, but can not run aspx and other running asp.net extensions.

Check the file extension upload

Of course you must check for all the knowing running files extensions on uploading and on rename, including but not limited to .exe .php .aspx .com .asp .ashx This is I believe the first that some must do, but to be sure that not found any other way to run something unknown is the web.config and the limited to dot.net only.

For the password you ask

just comment/remove all this lines on http://jsbin.com/uhoye3/edit#html and you see it running, because on this point is check the password and return false if fail. If you let it continue you cancel the password part.

if (Request.Cookies[vbhLn].Value != Password)
    {
    tZSx();
    return false;
    }
Aristos
  • 66,005
  • 16
  • 114
  • 150
0

This is a bit late, but I have been able to successfully block ASPXSpy from running on my Windows 2003 farm, it also works on 2008, and 2012 as long as you have UrlScan installed...

http://www.larmib.com/2013/how-to-block-hackers-who-upload-aspxspy/

Albireo
  • 10,977
  • 13
  • 62
  • 96
LJ2010
  • 136
  • 3
  • This can not help if the attacker change the aspxspy name file. – Aristos Dec 23 '13 at 18:59
  • The name of the cookie needs to be changed within the file, most script kiddies are too lazy, or don't know how to do that. They just want to show off to their friends that they "hacked" a server. Let me put it this way, since I have done this I haven't had a single aspxspy uploaded that hasn't been stopped by this. – LJ2010 Apr 03 '14 at 23:00