Category Archives: Security

Web Application Fortification with ModSecurity over IIS : OWASP ZAP Zed Attack Proxy

DING DING DING!

Whom will prevail! Two of my favorite tools at hand, one is for offence and one is for defence however we can argue that both are for defence if you analyse it from another point of vue.

With what looks like one of the coolest logos:

The ZAP Attack Proxy is a free tool from OWASP that can act as a proxy intercepting traffic for analysis and also performs scans. Not to mention it can integrate with a large number of other tools.

From their site:

The OWASP Zed Attack Proxy (ZAP) is one of the world’s most popular free security tools and is actively maintained by hundreds of international volunteers*. It can help you automatically find security vulnerabilities in your web applications while you are developing and testing your applications. Its also a great tool for experienced pentesters to use for manual security testing.

Let’s get into the action. I have two sites on IIS , one is being secured by ModSecurity and the other isn’t. Let’s see the variances.

Port 80 is secured and 2016 has just seen a run.

When firing the execution on hte port 80 rendition we get a 403 which is what we want. Not long ago a consultant came in and advised us to use this tool , which I also advise! However I said what do you do if we have an IDS that knows this signature and stops the traffic instantly? She had not seen such a thing before usually seeing the tooling continue on with the scan. Now using this tool as  aproxy to intercept is a different ball game.

Take away, how many different scanners have you tested against your site? Do you stop them instantly? Do you have forensics telling you someone at x IP address is constantly scanning?

Food for thought!

Happy Defending!

Web Application Fortification with ModSecurity over IIS : HTTrack Website Copier

Excessive recursion is the number one problem plaguing modern web applications and API’s. I always use the analogy of the bank where the client continues to go to the teller and try credentials in order to have his card authenticated. One of the elements I like to utilise is the module that Mads did in 2007!

 http://madskristensen.net/post/Block-DoS-attacks-easily-in-ASPNET

What 2007!, yes 2007! works wonders for customers who refuse to add Modsecurity or SNORT IDS or to have any appliances. Then whether on classic webforms / mvc / API’s we integrate this module and I can tweak it to allow only enough traffic that can mimic a human user.

ModSecurity over IIS is excellent when dealing with excessive recursion. I have seen it stop the OWASP ZAP Zed Attack Proxy in its tracks, stop Brutus from cycling its usual credential attacks, SQLMap from trying to pull databases from vulnerable SQLi sites. One element where it allowed the traffic to go through was with the HTTrack Website Copier.

What is the HTTrack Website Copier. From their site:

HTTrack is a free (GPL, libre/free software) and easy-to-use offline browser utility.

It allows you to download a World Wide Web site from the Internet to a local directory, building recursively all directories, getting HTML, images, and other files from the server to your computer. HTTrack arranges the original site’s relative link-structure. Simply open a page of the “mirrored” website in your browser, and you can browse the site from link to link, as if you were viewing it online. HTTrack can also update an existing mirrored site, and resume interrupted downloads. HTTrack is fully configurable, and has an integrated help system.

I first utilised this when our product Manager was going to a remote part of Africa where the internet was to be scarce. I downloaded the utility and presto I had a nice offline rendition of the site.

Then it dawned on my, isn’t this a nice reconnaissance tool for sites that perhaps do not have alot of forensics and could allow us to download alot of elements and then we can do some analysis offline.

Evidently not all can be pulled and observing something live is better but we dont register hits on things that are local.

Notice that ModSecurity and IIS allow me to fire excessive recursions against the site. I had to add custom rules in order to halt the attack. 

Most likely no one is testing against it!

Happy defending!

 

ASP.Net Web API and ModSecurity over IIS

ModSecurity is a great tool and a great compliment to IIS. The best thing is that it can secure all site , some sites, and regardless of what you want to secure as long as you can run the HTTPModule you can secure the inbound and outbound payloads.

From their site:

What Can ModSecurity Do?

ModSecurity is a toolkit for real-time web application monitoring, logging, and access control. I like to think about it as an enabler: there are no hard rules telling you what to do; instead, it is up to you to choose your own path through the available features. That’s why the title of this section asks what ModSecurity can do, not what it does.

In order to install Modsecurity, head over to to get the latest installer. :

ModSecurity: Open Source Web Application Firewall

https://www.modsecurity.org
 
 
Here are the install steps and the discovery and startup of your first site on premise and in the cloud.
 
First and foremost – use the double click! It’s what us Devs do best!
 
Away we go…
 

There are 64 and 32 bit renditions and a repository for the OWASP CRS which stands for Core Rule Set. Which you want.

Next is the ability to configure the instance you will want to say yes unless you are doing more of a silent install or want to powershell these permissions/additions …otherwise select the box and move along.

We are now complete , finish and go explore.

This said, first thing to oversee is IIS itself.

Notice the addition of 2 new HTTPModules:

Excellent, now off to the root! Which should reside at:

 C:\Program Files\ModSecurity IIS

Peruse the files and concentrate on .conf.

Then for the site you want enabled use this in your web.config:

<system.webServer>
<ModSecurity enabled=”true”
configFile=”C:\Program Files\ModSecurity IIS\modsecurity_iis.conf” />

<modules>
<!–<remove name=”ModSecurity IIS” />–>

<add name=”ModSecurity IIS (64bits)” preCondition=”bitness64″ />

</modules>

</system.webServer>

Away you, go…in my next post I will be attacking a localhost site with various tools to see how ModSecurity and IIS react.

Happy Defence!

Web Application Fortification with ModSecurity over IIS : The classic three thwarted!

XSS, SQLi and the path traversal attack are the golden three payloads we see over and over again. In this segment we will oversee how ModSecurity securing IIS reacts to these payloads.

First and foremost , we will fire the payloads in ModSecurity’s demo site and see that the information is reflective in that it is sent back to the user for input. Evidently this is due to the fact that we are using a demo site and that a dashboard or log viewer is not available to oversee the errors. In the real world we would be exposing ourselves as we would let the attacker know that we are using brand x or IDS/IPS or in this case a WAF that is augmented with the OWAPS CRS to become and IDS.

Classic payloads and the online model.

Classic payloads and the on-premise solution housed in IIS.


Happy defending!

ASP.Net Web API and Project HoneyPot : BFF’s

https://www.projecthoneypot.org/
Sometime ago, I presented an ASP.Net Security Skeleteton session at Microsoft TechDays. The concept was simple, build a base layer that can aid in the defence and forensics gathering of an ASP.Net WebSite whether it was WebForms or MVC.

An interesting element that was in the security skeletons layer as a HoneyPot Module. This element would utilise a module to verify IP Addresses against malicious behavior.

Think of a HoneyPot as a boobytrap.

You create a fake login page that is not acceccible by normal means except a scan and presto you know someone is up to something. Same goes for ports, fake robot file entries.

These ip addresses are sent to a centralized repository and you can analyse your inbound requests for the IP and compare against their list.

Now in order to do so one has to be efficient, you would want to either send a payload or verify against a cache. Either or is possible with different vendors/free implementations but in the end you want to check if an IP has been flagged as malicious.

Here are just a few of the IP Direcories available.

  1. Directory of Harvester IPs

  2. Directory of Spam Server IPs

  3. Directory of Dictionary Attacker IPs

  4. Directory of Comment Spammer IPs

In ASP.Net I like to use handlers whether message handlers or htphandlers to 

  1. Verify for excessive request
  2. Verify my blacklist
  3. Verify a honeypot
  4. ….so on and so forth

However throughout the years I have come to realise that tooling such as ModSecurity has HoneyPot integration built in. When no IDS is available I use a security related base layer but when I can utilise an IDS I rather go that route as it can secure an entire stack.

The service that Project HoneyPot offers is this:

HTTP Blacklist

The HTTP Blacklist, or “http:BL”, is a system that allows website administrators to take advantage of the data generated by Project Honey Pot in order to keep suspicious and malicious web robots off their sites. Project Honey Pot tracks harvesters, comment spammers, and other suspicious visitors to websites. Http:BL makes this data available to any member of Project Honey Pot in an easy and efficient way.

Http:BL provides data back about the IP addresses of visitors to your website. Data is exchanged over the DNS system. You may query your local DNS server and receive a response back that indicates the type of visitor to your site, how threatening that visitor is, and how long it has been since the visitor has last been seen within the Project Honey Pot trap network.

Several software authors have written implementations for a variety of web platforms. If you would like to integrate with http:BL, check out the http:BL API document.

 

Visual Studio Talk Show – Joel Hebert and ModSecurity Over IIS

I had the pleasure to be on the VS Talk show with Guy Barette and Mario Cardinal. 

Nous discustons avec Joel Hébert de son expérience avec ModSecurity et IIS. ModSecurity est un pare-feu applicatif web qui ajoute des fonctions de sécurité pour le serveur HTTP Apache, IIS et Nginx. C’est un logiciel libre distribué sous la licence Apache 2.0.

http://visualstudiotalkshow.libsyn.com/0198-joel-hbert-modsecurity-et-iis

Joel Hebert est un architecte logiciel qui réside à Ottawa. Il se passionne pour la sécurité et l’architecture. Il est un MVP ASP.Net et est un des leaders du groupe d’utilisateurs à Ottawa. Il aime partager ses connaissances du piratage, des tests de pénétration et d’audit en continu sur les vecteurs d’attaque modernes de sécurité.

Liens

ModSecurity
Livre: Web Application Defender’s Cookbook: Battling Hackers and Protecting Users
Site Web de Troy Hunt: Have I Been Pwned?

Web Application Fortification with ModSecurity over IIS : Brutus

Et tu, Brute?”==> “and you, Brutus?”

ASP.Net whether WebForms of time past or MVC and even Core are all plaforms that can utilise BasicAuthentication and with this comes the daunting task of securing the username and password.

In comes Brutus: from main site (google flagged as dangerous – omitted)

Brutus is one of the fastest, most flexible remote password crackers you can get your hands on – it’s also free. It is available for Windows 9x, NT and 2000, there is no UN*X version available although it is a possibility at some point in the future. Brutus was first made publicly available in October 1998 and since that time there have been at least 70,000 downloads and over 175,000 visitors to this page. Development continues so new releases will be available in the near future. Brutus was written originally to help me check routers etc. for default and common passwords

We know password re-use is predominant. We know that common user names are utilised. Many techniques exist to oversee if the accounts that are part of your domain are compromised. There are password lists , haveibeenpwned, and password dumps online (legality of pulling these is in question}. 

The best way to defend yourself against dictionnary attacks is to perform them. In comes our friend Brutus with Basic Autentication based attacks on our ASP.Net platform on IIS.

In this video we perform such an attack and ModSecurity over IIS is able to stop the cycle and also add forensics for us to identify the attack along with data for the security offices if need be.

Another consideration is Brutus not only can read from a text file but can also based on AutoGeneration. This is why I do not like exposing the password strength requirements. The brute force engines can iterate the site using the conditions imposed and well…..exposed by the site and this with pleasure.

Bf-partialknowledge.jpg

The consideration we have here is that ModSecurity was not only able to stop Brutus as it excessively iterates the website or web.api but the forensics to report on this are also present. Alerting is also possible .

In a previous demo I used an HTTPModule to stop excessive iterations and report back a 500 internal server error to thwart certain attacks. Issue with this is it is not automaticly logging and providing forensics. 

Here is an example event viewer entry: 

Note the idnetification that that a security scanner has iterated the site. The scanner is brutus/aet and it was identified by OWASP CRS/2.2.9.

The CRS stands for CoreRule Set https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project

ASP.Net / Web.API’s can report whom is excessively iterating them when under the umbrella of ModSecurity.

Happy coding!

ASP.Net Web Api Security : Remove Generated Http Response Headers

IIS and some of the constructs in ASP.Net love to let the populace know that you are utilizing IIS and what flavor of ASP.Net or MVC you are using. 

This can be great when debugging payloads and you know what the partner has as infrastructure but for an attacker it is an excellent way to reflect your landscape.

Let’s see what a standard payload looks like.

Start with creating a stand web app.

Select Web API and follow the same indices as illustrated.

Run the application to ensure it compiles and renders.

Start up a proxy of your choice , here we are using Telerik Fiddler.

 

Note, 

  1. Server
  2. X-AspNetMvc-Version
  3. X-AspNet-Version
  4. X-Powered-By

To remove these headers (from http://stackoverflow.com/questions/12803972/removing-hiding-disabling-excessive-http-response-headers-in-azure-iis7-without):

 You can use the PreSendRequestHeaders and PreSendRequestContext events with native IIS modules, but do not use them with managed modules that implement IHttpModule. Setting these properties can cause issues with asynchronous requests. The correct version is to use BeginRequest event.

    protected void Application_BeginRequest(object sender, EventArgs e)
    {
        var application = sender as HttpApplication;
        if (application != null && application.Context != null)
        {
            application.Context.Response.Headers.Remove("Server");
        }
    }

To remove X-AspNet-Version, in the web.config find/create <system.web> and add:

  <system.web>
    <httpRuntime enableVersionHeader="false" />

    ...

To remove X-AspNetMvc-Version, go to Global.asax, find/create the Application_Start event and add a line as follows:

  protected void Application_Start()
  {
      MvcHandler.DisableMvcResponseHeader = true;
  }

To remove X-Powered-By, in the web.config find/create <system.webServer> and add:

  <system.webServer>
    <httpProtocol>
      <customHeaders>
        <remove name="X-Powered-By" />
      </customHeaders>
    </httpProtocol>

    ...

Happy defending!