The latest build of Acunetix Web Vulnerability Scanner includes a lot of changes and new security tests. Here is a short summary of the most interesting tests we’ve just added.
1. Vulnerable JavaScript libraries
Acunetix Web Vulnerability Scanner can now identify vulnerable versions of various JavaScript libraries. An alert similar to the following will be shown when a vulnerable library is identified:
Our testing identified various open source web applications using old/vulnerable JavaScript libraries, and this seems to be a very common problem. Many people check their source code for vulnerabilities but forget to update the third-party libraries they are using.
2. Ruby on Rails weak secret token
Each Ruby on Rails web application contains a secret token (usually stored in the file /config/initializers/secret_token.rb). This token secret_token is used to sign application cookies. If an attacker knows the value of this secret token he can impersonate any user in the application and achieve Remote Code Execution by deserialization of a crafted Ruby Object. You can find out more about this problem here.
Developers often copy and paste code, and this can cause the secret_token being copied inadvertently. The latest build of Acunetix WVS is able to identify situations when this happens. When a Ruby on Rails application is detected, Acunetix WVS will try to identify these tokens and issue an alerts accordingly.
3. XML external entity injection via file uploads vector
We have added a new test that checks for XML external entity injection via file uploads. This vulnerability can be identified using AcuMonitor, which allows Acunetix WVS to perform complex tests such as the detection of this vulnerability.
When the Acunetix WVS identifies a file upload form, the scanner prepares an XML file that contains an XXE payload. This payload will make a request to the AcuMonitor server if the application is processing the XML file using a vulnerable XML parsing library. XXE injections are pretty common in web applications but it’s next to impossible to detect without a a service like AcuMonitor.
4. The name of the uploaded file is user input
When Acunetix WVS is testing file uploads it will also fuzz/test the name of the file that is uploaded. Sometimes, developers are very attentive when performing sanitization on the common inputs (like GET/POST variables) but don’t think that the name of the uploaded file is also user input and should be sanitized as well. We found some real-life web applications that are vulnerable to this issue and decided to automate it.
5. nginx memory disclosure vulnerability
This is an interesting vulnerability. I found out about this problem when looking at bug reports. Basically, there is an use-after-free vulnerability in nginx before 1.0.14 and 1.1.x before 1.1.17 allows remote HTTP servers to obtain sensitive information from process memory via a crafted back-end response. This can be exploited in some particular situations (as demonstrated in the mentioned bugs reports) where the user input is reflected in the response header (e.g. Location header) and the attacker will receive random chunks from the process memory.
6. Java Authentication and Authorization Service (JAAS) bypass
Sometimes, JAAS is not configured correctly and an attacker can bypass the authentication. As an example, take a look at the code below:
<security-constraint>
<web-resource-collection>
<web-resource-name>Adminarea</web-resource-name>
<url-pattern>/admin/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>administrator</role-name>
</auth-constraint>
</security-constraint>
In this case the security constraint is defined only for HTTP methods GET and POST.
If an attacker is using the HEAD HTTP method he can bypass the authentication.
Get the latest content on web security
in your inbox each week.
THE AUTHOR
