IronWASP v0.9.7.1 is now available for download. Users of older versions should get an update prompt when using IronWASP.
It has been a less than two months since the last release and a lot has been added during this time. I have added two of the most requested features - reporting and upstream proxy authentication support. I have also significantly mitigated two of the most reported complaints - false positives and crashes due to excessive memory consumption.
There are two new modules available in this version:
1) SSLSecurityChecker - SSL Layer Security Scanner by @msaindane
2) IronSAP - SAP Security Scanner by @prasannain
More details about these two modules is available here.
And here's what you get with the IronWASP core:
1) Reporting in both HTML and RTF formats. Sample Report
2) Memory usage cut by up to 50% during scanning compared to previous version
3) Massive reduction in False Positives by implementing Oscillating Time Delay technique
4) Awesome new Screenshot mode, see full details.
5) Support for NTLM and other authentication in upstream proxy
6) New start-up window
7) More intelligent error handling in Scripting shell and logging of shell commands and output
8) Important bug fix in the JSON parser
9) Important bug fix in Payload Effect Analyzer
10) Existing Active Plugins moved to the core with improvements and bug fixes
Here is a quick peek at some of the new items:
Reporting:
It's finally here, the most requested feature. You can create reports in two formats - HTML and RTF. The HTML report is better looking and ideal for passing around. The RTF format is useful when you want to add the issues found by IronWASP as part of your pentest report. You can open RTF files in word and directly copy the contents on to your report.
To get an idea about what the report looks like check this sample HTML report.
To create a report click on the 'Generate Report' item in the menu.
This should open up the report generation window. Here you can see the list of all issues identified by IronWASP. You have the option to uncheck the issues that you don't want to be included in the report. Once that is done, clicking on the report generation button create the report in both the formats.
Once the report are generated you have the option to save in both the HTML and RTF formats, clicking on the corresponding format name will open a file save prompt.
Reduced Memory Usage:
Crashes when scanning large sites due to out of memory exceptions been a recurring complaint and I have finally taken some strong measure to address this. I ran IronWASP through a memory profiler to find out what sections were consuming most of the memory and have made design changes to address a lot of them.
The result is up to 50% reduction in memory footprint compared to the previous version when doing fully automated scanning.
In addition as a fail-safe I have added a system that constantly monitors the memory consumed by IronWASP and if it increases beyond a point then the CLR Garbage Collector is explicitly called to free up space.
Reduced False Positives through Oscillating Time Delay technique:
Every email I have received appreciating a feature or asking for a new feature or reporting an exception has invariably contained a note about there being some False-positives in the scan. False-positives are unavoidable and that is why IronWASP has a False-positive detection support, which is quite well received by the way.
However on closer observation it became clear that most of the False positives were caused by the time-based checks. A time-based check is where IronWASP sends a payload that will cause a time-delay in the response if the application is vulnerable. Time-based checks are part of SQL Injection, Command Injection, Code Injection and RFI detection.
The old time delay technique was very simple. IronWASP checked how long it takes for a regular request to be served by the application. Based on that time it selects a time delay payload and if the response for this time delay payload takes significantly longer then the same payload is sent again. If the delay happens one more time then it was declared as an issue.
This problem here was that time delays caused by temporary network issues or server overload issues were triggering false positives.
To address this the new version uses an oscillating system of time delays. This system sends payloads with big delay time and small delay time alternatively. Apart from checking if there is a delay the system also confirms if the small delay times were significantly smaller than the big delay times. Delays due to network issues or server overload would not typically fall in this pattern so they are not detected as vulnerabilities.
New Start Window and Support for NLTM Proxy Authentication:
In the new version when IronWASP starts the user is shown a window with a bunch of options to easily configure IronWASP to suit their environment.
Two things of particular interest are easy access to documentation on importing IronWASP's (FiddlerCore's actually) certificate as a trusted CA and an option to use the system proxy as upstream proxy which will automatically handle any upstream proxy authentication as well, just like Fiddler does.
Scripting Shell Error-handling and Logging:
For a lot of advanced users the scripting shell is the favourite part of IronWASP. At the same time there are a lot of beginners trying to use this feature to learn scripting. The following updates have been made to make their life a little easier:
a) Multi-line shell automatically detects mixed use of tabs and space for indentation in Python script and fixes it
b) Interactive shell automatically strips space at the start of Python commands when indentation is not expected (this turns out to be very common newbie mistake)
c) Sometimes badly written script (like infinite recursion) might crash IronWASP and the user would lose all the code they typed. Now all commands and the results are automatically logged to a file named 'CommandLog.txt' inside the corresponding profile folder.
Active Plugin moved to the Core:
All the existing active plugins have been moved to the core of IronWASP, this was done to improve performance and memory efficiency. Though the old plugin files are still included with IronWASP they won't load by default since they use the same names as the internal active plugins.
If you want to use the Python/Ruby version of the Active Plugin instead of the core ones then just make sure the plugin name is different than the list of internal plugins and it should work as before.
Enjoy the new features and enhancements, work on the next version begins tomorrow :)
It has been a less than two months since the last release and a lot has been added during this time. I have added two of the most requested features - reporting and upstream proxy authentication support. I have also significantly mitigated two of the most reported complaints - false positives and crashes due to excessive memory consumption.
There are two new modules available in this version:
1) SSLSecurityChecker - SSL Layer Security Scanner by @msaindane
2) IronSAP - SAP Security Scanner by @prasannain
More details about these two modules is available here.
And here's what you get with the IronWASP core:
1) Reporting in both HTML and RTF formats. Sample Report
2) Memory usage cut by up to 50% during scanning compared to previous version
3) Massive reduction in False Positives by implementing Oscillating Time Delay technique
4) Awesome new Screenshot mode, see full details.
5) Support for NTLM and other authentication in upstream proxy
6) New start-up window
7) More intelligent error handling in Scripting shell and logging of shell commands and output
8) Important bug fix in the JSON parser
9) Important bug fix in Payload Effect Analyzer
10) Existing Active Plugins moved to the core with improvements and bug fixes
Here is a quick peek at some of the new items:
Reporting:
It's finally here, the most requested feature. You can create reports in two formats - HTML and RTF. The HTML report is better looking and ideal for passing around. The RTF format is useful when you want to add the issues found by IronWASP as part of your pentest report. You can open RTF files in word and directly copy the contents on to your report.
To get an idea about what the report looks like check this sample HTML report.
To create a report click on the 'Generate Report' item in the menu.
This should open up the report generation window. Here you can see the list of all issues identified by IronWASP. You have the option to uncheck the issues that you don't want to be included in the report. Once that is done, clicking on the report generation button create the report in both the formats.
Once the report are generated you have the option to save in both the HTML and RTF formats, clicking on the corresponding format name will open a file save prompt.
Reduced Memory Usage:
Crashes when scanning large sites due to out of memory exceptions been a recurring complaint and I have finally taken some strong measure to address this. I ran IronWASP through a memory profiler to find out what sections were consuming most of the memory and have made design changes to address a lot of them.
The result is up to 50% reduction in memory footprint compared to the previous version when doing fully automated scanning.
In addition as a fail-safe I have added a system that constantly monitors the memory consumed by IronWASP and if it increases beyond a point then the CLR Garbage Collector is explicitly called to free up space.
Reduced False Positives through Oscillating Time Delay technique:
Every email I have received appreciating a feature or asking for a new feature or reporting an exception has invariably contained a note about there being some False-positives in the scan. False-positives are unavoidable and that is why IronWASP has a False-positive detection support, which is quite well received by the way.
However on closer observation it became clear that most of the False positives were caused by the time-based checks. A time-based check is where IronWASP sends a payload that will cause a time-delay in the response if the application is vulnerable. Time-based checks are part of SQL Injection, Command Injection, Code Injection and RFI detection.
The old time delay technique was very simple. IronWASP checked how long it takes for a regular request to be served by the application. Based on that time it selects a time delay payload and if the response for this time delay payload takes significantly longer then the same payload is sent again. If the delay happens one more time then it was declared as an issue.
This problem here was that time delays caused by temporary network issues or server overload issues were triggering false positives.
To address this the new version uses an oscillating system of time delays. This system sends payloads with big delay time and small delay time alternatively. Apart from checking if there is a delay the system also confirms if the small delay times were significantly smaller than the big delay times. Delays due to network issues or server overload would not typically fall in this pattern so they are not detected as vulnerabilities.
New Start Window and Support for NLTM Proxy Authentication:
In the new version when IronWASP starts the user is shown a window with a bunch of options to easily configure IronWASP to suit their environment.
Two things of particular interest are easy access to documentation on importing IronWASP's (FiddlerCore's actually) certificate as a trusted CA and an option to use the system proxy as upstream proxy which will automatically handle any upstream proxy authentication as well, just like Fiddler does.
Scripting Shell Error-handling and Logging:
For a lot of advanced users the scripting shell is the favourite part of IronWASP. At the same time there are a lot of beginners trying to use this feature to learn scripting. The following updates have been made to make their life a little easier:
a) Multi-line shell automatically detects mixed use of tabs and space for indentation in Python script and fixes it
b) Interactive shell automatically strips space at the start of Python commands when indentation is not expected (this turns out to be very common newbie mistake)
c) Sometimes badly written script (like infinite recursion) might crash IronWASP and the user would lose all the code they typed. Now all commands and the results are automatically logged to a file named 'CommandLog.txt' inside the corresponding profile folder.
Active Plugin moved to the Core:
All the existing active plugins have been moved to the core of IronWASP, this was done to improve performance and memory efficiency. Though the old plugin files are still included with IronWASP they won't load by default since they use the same names as the internal active plugins.
If you want to use the Python/Ruby version of the Active Plugin instead of the core ones then just make sure the plugin name is different than the list of internal plugins and it should work as before.
Enjoy the new features and enhancements, work on the next version begins tomorrow :)
No comments:
Post a Comment