Category Archives: ASP.Net WebApi

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!

Swashbuckle and the Swagger UI : Curious Case of the Invalid Data Types

Swashbuckle is a nice Nuget Package that allows for easy integration with Swagger and is qualified as  one of the defacto REST API discovery tools. This along side ASP.Net’s Web Api HELP page which can showcase a service quite nicely.

One of the falicies that I have come to observe in the swashbuckle rendition is that when you generate a sample from the REST API in what is call the Swagger UI at times you have a mismatch on the data types. Now Swagger can generate a document which is JSON with the /document/v1 payload and this is not affected as you will see in the example. However, to bypass the data type issue I had to add my own rendition of the index.html for the Swagger.UI and augment some Javascript. 

Here is the issue at hand with a tutorial on how to replicate and a nice discovery on how differnt data types are rendered.

First and foremost , we set the stage.

From Visual Studio create a new Web Application.

Select Web Api and follow the screenshot for other indicators.

The following is generated.

 

Add a class with various data types. Types that are not common through all platforms should be utilised. Nullables of double and decimal come to mind.

Add the NuGet Package for Swashbuckle

Oversee the changes

Notice the addition of this file. We can add a maptype<> in here to tell swashbuckle what to do with a double and how to convert it but it has no effect on the Swagger.UI part. Only the JSON from /documents/v1 as an example.

Fire up the service and oversee what you get with the default tooling.

Select the API which returns your class

Notice the json the douvles have a (.) DOT and so do the decimal types.

{
  "datetimeVal": "2017-05-10T15:08:06.1547306-04:00",
  "stringVal": "sample string 2",
  "integerVal": 3,
  "nullIntVal": 1,
  "doubleVal": 4.1,
  "nullDoubleVal": 1.1,
  "decimalVal": 5.0,
  "nullDecimalVal": 1.0
}

Now fire up swagger with /swagger

 

 

 Observe what is generated, notice no (.) DOT

Copy and Paste that into a classic client generator.

Also do a Java implementation as well, same issue

The docs/v1 is ok however!

The data types are format double and type number which is what we want. 

 

This said careful when generating client classes as this will have casting repercussions. 

Happy Coding!

 

 

 

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!

Azure Lunch and Learn: Azure Api Management Showcase

I have great news to share with the community. I was able to secure a room for 12 engagments in order to go forth with an Azure MOnthly Series.

As an ASP.Net and ASP.Net WebAPi specialist I will be doing the demos around these constructs. 

The first is on Azure API Management where we will also see renditions of MuleSoft and APIGEE for API Managment. For the first lunch and learn we will concentrate on Modeling ASP.Net WebAPI’s and creating ASP.Net Web API’s. Once this base is completed we will continue and aggregate the API with Api Management. I would say the session will be 80% Web API and 20% Azure API Management.

See you there:

Azure Lunch and Learn: Azure Api Management Showcase

Tuesday, Feb 28, 2017, 12:00 PM

Microsoft Canada Co. (Ottawa)
100 Queen Street, Suite 500 Ottawa, ON

41 IT Community Members Went

How:This first segment in the Azure Lunch and Learn Series will focus on API Management and this in a nutshell. The goal is to oversee a product and its intrinsics but just enough over a lunch hour for you to take away key concepts and to start guiding your research. We are going to offer this series once a month for you to come in and learn Azure…

Check out this Meetup →

 

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 WebAPI and CorrelationID/RefCorrelatonID

Somethings can be foreshadowed and some things are always expected. As is the case of looking in log files and not seeing a Correlation ID nor any RefCorrelation ID’s. Thing is when your logs do not have alot of throughput you can find your customers/clients/elements/daemons log entry with ease with just a log stamp (datetime). However , even with low latency Correlation ID’s should always be utilised.

What is a Correlation Identifier?  Simple Guid that is Unique and identifies a transaction. See the link for a more enterprise integration perspective, but in the end a guid is all this is.

A curious thing that I always see is that in all the logging examples:

1) No provisioning for Correlation ID’s
2) No provisioning for Ref Correlation ID’s

I then ponder on …

how is it that you correlate?

(Pun intended)

Inbound Web.API calls should have a header containing a Correlation ID. Which is a GUID that can clearly and uniquely identity the transaction.

This in turn then becomes the RefCorrelation ID in your log, as you spawn a Correlation ID of you own based on the Request.CorrelationID which is a unique identifier to the transaction. The client should see his/her payload coming back with an echo of the ID they sent in. At times the RefCorrelationID is also sent as an echo. All depending on requirements and standards.

I very much like this implementation: https://mderriey.github.io/2016/11/18/correlation-id-with-asp-net-web-api/

The only variant that I advise is to accept a correlation ID from the client and to use the correlation ID from the request [request.GetCorrelationId()] as the Unique ID in the logs.

Example:

 

First example of standard flow a request comes in and is processed internally via multiple logging points. The RefCorrelation ID is what the client passed in, the Correlation ID is what we generated or decided was going to be the unique idenitfier.

In the second example another service is call. Say to process a payment.

Which ID is passed?

Your correlation ID is passed and the new service uses yours as a REF and generated a new unique ID for its transaction. So on and so forthat as many times as we have subsequent calls.

Having worked in integration for over 12 years, I know the value of being able to correlate all data especially when execitions can go from Java to ASP.Net Web.API to IBM MQ to Biztalk to Appliances.

Food for thought!

 

 

 

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.

 

IIS HttpFingerPrinting Pragmatics

For order of business in any appsec reconnaissance usually involves Maltego, Sploitego, and for me  HTTPFingerprinting.

Trying to identify the landscape is important as you will want to know how hackers go on the offense and determine your o/s and web server pragmatics. 

 

From moving response date formats ; to changing the Server header, to altering ordering…are all valid ways you can confuse the http reconnasance tools. However one thing remains.

When someone is scanning you? Are you aware?

Let’s take a look at ModSecurity and how it handles the various payloads from a few classic tools.

 

I always recommend to scan yourself as part of the SDLC in order to see if you have leaky response headers, if your IIS implementation still has the x-powered-by etc.

The more someone knows about your landscape the more they can act on.

Happy Defence!

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?

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!