Showing posts with label ASP Classic. Show all posts
Showing posts with label ASP Classic. Show all posts

Friday, 22 January 2016

Quick HTACCESS Rules and VBS / ASP Functions for Banning Hackers

Quick HTACCESS Rules and VBS / ASP Functions for Banning Hackers

By Strictly-Software

Having to work on some old sites sometimes means that the security is often pretty lax and even if the system is locked down to prevent SQL Injection by having proper permissions, e.g not allowing CUD (Create, Update, Delete) statements to run from the front end, there is still the possibility of XSS hacks on an old ASP Classic site.

Running an exploit scanning tool like the OWASP ZAP tool is a good idea to find possible holes but even then I have found that it doesn't find all possible exploits. There are hackers looking to harm you and then there are the "ethical hackers" who will still try and probe your site to "warn you", and the "unethical" sort who try to blackmail customers by putting your URLS up on special websites that claim the site is a security minefield.

Even if your browser protects you from most cases, e.g trying to find a recent hack in Chrome was a nightmare due to it automatically protecting me by changing the HTML source, these reputation attacks will hurt your company and customers. Therefore even if you are not given the time or cannot fix every hole that could exist in your system, you should do as much as possible to prevent them from being found in the first place.

Having a proper WAF (Web Application Firewall), is always recommended but even if you don't you can make use of your .htaccess file to block a lot of probing plus you can always use code to validate requests, such as form submissions on contact forms or other pages that accept user content.

Having a CAPTCHA is always a good idea, and if not use a BOT TRAP if at all possible, however this won't stop a human with the spare time to examine your source code and work out what is going on to get around it either manually or by writing a custom BOT.

HTACCESS Rules

There are many .HTACCESS rules you can use to block attacks but I have found that some are overly obtrusive and will block legitimate requests.

For example if you want a good list of possible .htaccess rules to prevent probes from PHP, JavaScript, MySQL and WordPress then downloading the free plugin WP Security is a good way to see the sort of rules that can be applied to an .htaccess file.

Just turn on all the firewall, image hot linking and file protection rules you want and then go and view the .htaccess file in your root folder.

These rules are quite comprehensive and most are generic enough to be copied and used on Microsoft platforms that support .htaccess files if you want. Obviously a PHP hack isn't going to work on an IIS server but if you want to still catch people trying these hacks then having a page that logs and bans them if possible is an idea.

I won't show you all the rules you can take from other plugins but I will show you some core rules that can cut down your "Bad Traffic" by a huge percentage.

I have found on my own sites that banning any Internet Explorer version under 7 is always a good idea as many of these hacker tools that script kiddies use, still have a default user-agent of IE 5-6, and for some reason these people don't bother changing the user-agent.

Therefore just examining your IIS log files for any user with IE 5, 5.5 or 6 user-agent is a good indication that they are up to no good. You can read about this and another way to reduce bandwidth on another article of mine here.


RewriteRule %{HTTP_USER_AGENT} (MSIE\s6\.0|MSIE\s5\.0|MSIE\s5\.5) [NC]
RewriteRule .* http://127.0.0.1 [L,R=302]


This rule sends any user-agent with IE 5, 5.5 or 6 back to the localhost on the users machine with a 302 rewrite rule. 

You could just use a [F] Forbidden (403) rule if you want but at least this way you are going to piss the offenders off a bit more by sending them in circles.

Here are some more rules I use regularly which sends the user to a special hack.asp page where I can log their details and bounce them to a honeypot or a circular link maze of my choice.

As you can see the rules cover some common SQL Injection attacks that utilize the system tables, anything trying to be executed (EXEC), plus <Script> tags using standard and URL encoded brackets.

This is because a lot of "ethical hackers" or probers will try simple <script>alert("Hacked")<script> tests on any search form they can find on your site.

If the page you get posted to pops up an alert box then you are vulnerable to Cross Site Scripting attacks.

Other methods they commonly use are HTML tags that allow for onload functions to be run as well as "break out" code that tries to close an HTML element, then output it's own HTML or JavaScript code.

# SQL INJECTION and XSS FINGERPRINTING
RewriteRule ^/.*?\.asp\?(.*?DECLARE[^a-z]+\@\w+[^a-z]+N?VARCHAR\((?:\d{1,4}|max)\).*)$ /jobboard/error-pages/hack\.asp\?$1 [NC,L,U]
RewriteRule ^/.*?\.asp\?(.*?sys.?(?:objects|columns|tables).*)$ /jobboard/error-pages/hack\.asp\?$1 [NC,L,U]
RewriteRule ^/.*?\.asp\?(.*?;EXEC\(\@\w+\);?.*)$ /jobboard/error-pages/hack\.asp\?$1 [NC,L,U]
RewriteRule ^/.*?\.asp\?(.*?(%3C|<)/?script(%3E|>).*)$ /jobboard/error-pages/hack\.asp\?$1    [NC,L,U]
RewriteRule ^/.*?\.asp\?(.*?((%2[27])%3E(%20)*%3C|['"]>\s*<).*)$ /jobboard/error-pages/hack\.asp\?$1    [NC,L,U]
RewriteRule ^/.*?\.asp\?(.*?(<svg|alert\(|eval\(|onload).*)$ /jobboard/error-pages/hack\.asp\?$1    [NC,L,U]

# Block blank or very short user-agents. If they cannot be bothered to tell me who they are or provide jibberish then they are not welcome!                                                       
RewriteCond %{HTTP_USER_AGENT} ^(?:-?|[a-z1-9\-\_]{1,10})$ [NC]
RewriteRule .* - [F,L]


ASP / VBScript Function

As well as having a good set of .htaccess rules to prevent hacks by QueryString you can always use a function to parse any content through to look for hacks. Of course it is possible to use .htaccess rules to filter out HTTP POST and GET Requests but you may want to prevent too many regular expressions running on every POST with your .HTACCESS file by just passing publicly accessible forms with your function.

A very basic example is below.

Function TestXSS(strVal)
 
 Dim bRet : bRet = False

 '* remove encoded < > etc, use your own URL Decode function, I use a SERVER SIDE JavaScript with their decodeURIComponent function to do this in ASP Classic
 strVal = URLDecode(Trim(strVal))

 '* URL Encoded stuff like %3Cscript%3Ealert(1)%3C%2fscript%3E will get trapped by ISAPI
 '* RegTest is just a generic function I have which does a regular expression test against a value and pattern to see if it matches like C# RegEx.IsMatch
 If RegTest(strVal, "(?:<\/?script(\s|>|)|\W+eval\(|\W+(?:src|onload)=|document\.)") Then
  bRet = True
 Else    
  If RegTest(strVal, "(';|"";|'>|"">|alert\(|document\.cookie|\.frame|\.top\.location|(?:document|location)\.src|on\w+\()") Then
   bRet = True
  Else
   bRet = False 
  End If
 End If

 TestXSS = bRet
End Function


Obviously you can extend this function as much as you want to check for other words or pieces of code that shouldn't be passed around in forms or querystrings. It is just a base for you to start with.

Conclusion

Remember security is best approached in a multi layered way without your system relying on one form of defence alone.

WAFS, HTACCESS rules, code, CAPTCHAS, BOT Traps, special "not to be visited" links in your Robots.txt file that then send visitors to that page off to honeypots for breaking the rules, rude word lists, proper file permissions and HTTP parameter checks are all various ways to protect your site.

However many of these are sticking plasters which are used to protect your code in case it has not been 100% written to sanitise ALL user input, escape content outputted to the page, or has incorrect database security permissions.

Having a properly written and secured system is always the best solution however new exploits are always coming out so having as much protection as possible is not only good for security but it can save on bandwidth costs as well!

© 2016 By Strictly-Software.com

Friday, 10 January 2014

An ASP Classic Security Tool

An ASP Classic Security Tool

By Strictly-Software

The following script is one I wrote a long time ago but one I found quite useful the other day when I was working on an ASP Classic site.

If you download the script from my main website testsecurity.txt and then re-name it to .asp and copy it to your websites folder. You can then run it as an ASP page from your website.

The form is pretty simple and just asks for your ADO connection string so it can connect to your database using your websites login or another if you so wish.

It runs a number of tests and flags any "potential" problems up in red.

These may or may not be issues but could be areas of concern. For example you may need your website to have access to system objects from the website or run certain extended stored procedures but in many cases you shouldn't or wouldn't.

The security holes the tool looks at are:

  • The roles that the user is a member of such as data_reader, data_writer or ddl_admin etc.
  • It runs some select statements to see if it can access system tables using old and new versions e.g INFORMATION_SCHEMA.TABLES or SYS.OBJECTS.
  • Tests whether the user has direct write permission to your database. Obviously I use EXECUTE permission on all my CUD (Create,Update,Delete) statements which are held inside stored procedures but on older ASP systems you are likely to find people doing direct CUD operations (just like many PHP developers still do) from the client code to the database.
  • I test whether I can directly UPDATE a table inside your DB. I try and find a table using the system objects, which in itself could be a security hole, and then update a column in a table to its existing value so I don't overwrite anything. However this tells me whether you potentially have a hole by allowing the website direct UPDATE permission. Imagine if your own sanitisation functions failed or an SQL Injection attack succeeded. This could potentially bring your whole system down!
  • I test for the ability to run certain potentially dangerous extended stored procedures such as xp_cmdshell (can run anything a command prompt could), xp_fileexist which tells a user whether or not a file exists on the server and also xp_regwrite which allows you to write to the registry with SQL. Obviously the first and last functions could cause drastic problems if a hacker could use them against you!
  • I also test whether this ASP page can itself write and delete files (a simple text file with nothing in it) inside the folder that the ASP file is located. Obviously this could be a security hole as most websites only allow certain folders to be able to be written to. Being able to write files wherever the code is located could be dangerous as a hacker could write a file to delete other files or run code. I also check to see if I can write files to other places on the network - again another security hole. Sites should only allow the writing of files in certain places that can be virus checked and are known to be safe due to the permissions on the folder.
You might find this security test file that I quickly knocked up one day useful if you are ever having to work with ASP Classic sites and want to quickly check a variety of potential security holes in the database, website and file system with one form submission.

You can download the file from my main site testsecurity.txt.

Just remember to change the file extension to .ASP before running it!