Some aspects of the positive and negative models of the Webmonitorex platform
Each new specialist in our Application Protection practice goes through something between initiation and internship. Typically, as part of a task, you need to deploy a vulnerable application, a WAF of one of our focal partners, and then find a specific vulnerability, exploit it, see what is visible on the WAF in monitoring mode, and then configure the WAF so that it begins to detect and block this vulnerability. Of course, the vulnerabilities chosen are not such that they can be immediately detected by the signature.
In this article, Junior Systems Engineer “K2 Cybersecurity” Daniil Zolotarev will share the task that fell to him.
In the course of his work, Daniil had to protect Juice Shop using the Webmonitorex platform and face some aspects of the negative and positive models of this WAF. Next, we'll look at examples of creating custom rules to block Improper Input Validation attacks. Thus, we will clearly demonstrate one of the key capabilities of WAF – closing application holes in the product before fixing it.
Juice Shop as a vulnerable application
A fairly popular development from the OWASP community, Juice Shop, was chosen as a vulnerable web application. It is a web application – an online store selling juices. But with one key feature – it hides known vulnerabilities from the OWASP list. Therefore, it is an ideal candidate to test some features.
We deployed the application and WAF on separate servers in our Cloud to simulate real cases of implementing information security. Juice Shop is written in Node.js, Express and Angular. It can be deployed in Docker, Vagrant, popular cloud providers and Node.js with the npm utility. So the last option was chosen. It’s simple – commands with comments are further down in the listing:
sudo apt update
# Установка Node.js
sudo apt install nodejs
sudo apt install npm
# Клонируем репозиторий
git clone https://github.com/juice-shop/juice-shop.git --depth 1
cd juice-shop
# Устанавливаем Juice Shop
npm install
# Запускаем Juice Shop
npm start
Other installation options can be found on the Juice Shop Github – https://github.com/juice-shop/juice-shop .
After launch, we check it in the browser. The application runs on port 3000. Register in the browser https://localhost:3000 to check functionality.
WAF Webmonitorex
This WAF is installed in several options; we chose the on-prem lite option, that is, the filter node is installed on a virtual or physical server, and WAF events are managed and collected through the API and Personal Account, which are located on separate servers with the protection of the vendor.
In our case, we will install a filter node on a server in our Cloud, so we get a server architecture like in Figure 2 below. The server running the WAF will act as a reverse proxy for the application. Therefore, we assign it an external IP address (Elastic IP), and both servers will be in the same local subnet of the vulnerable local web application. We also configured security groups for the server network interfaces to prevent access from the global network or third-party subnets.
The Webmonitorex platform can be deployed on servers running Linux OS (Debian, Ubuntu, CentOS, AmazonLinux, AlmaLinux, Rocky Linux, Oracle Linux, SuSe Linux) based on the NGINX Stable and Plus web server, as well as on the Kong API gateway platform. In addition, support for domestic operating systems is implemented: RED OS, Alt Server 10 based on the Angie web server and Angie PRO.
Deployment available on cloud platforms AWS, Google CP, Yandex.Cloud, Microsoft Azure, Alibaba Cloud and private clouds. The deployment tools include ready-made platform images for the first two options, as well as Docker NGINX images, Kubernetes images with an Ingress controller or Sidecar proxy NGINX, and DEB and RPM installation packages.
At our stand we are deploying a filter node on a server running Linux Ubuntu 22.04 LTC as an NGINX Stable 1.24 module. The installation of the SZI software is shown in the listing below.
# Установка Nginx stable и зависимостей
sudo apt install curl gnupg2 ca-certificates lsb-release
echo "deb http://nginx.org/packages/debian `lsb_release -cs` nginx"
sudo tee /etc/apt/sources.list.d/nginx.list
curl -fsSL https://nginx.org/keys/nginx_signing.key | sudo apt-key add -
sudo apt update
sudo apt install nginx
# Adding a repository and installing Webmonitorex platform packages
curl -fsSL https://repo.webmonitorx.ru/wmx.gpg | sudo apt-key add –
sh -c "echo 'deb https://repo.webmonitorx.ru/ubuntu/webmonitorx-node jammy/4.6/' | sudo tee /etc/apt/sources.list.d/wmx.list"
sudo apt update
sudo apt install --no-install-recommends wallarm-node nginx-module-wallarm
Next, edit the NGINX configuration as follows, adding the highlighted lines. Logs are installed in the configuration automatically when installing Webmonitorex platform packages. We also installed Let`s Encrypt TLS certificates using Certbot, you can read more here – https://certbot.eff.org/ . File /etc/nginx/nginx.conf presented below.
user www-data;
worker_processes auto;
worker_rlimit_nofile 2048;
load_module modules/ngx_http_wallarm_module.so;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;
events {
worker_connections 1024;
multi_accept on;
}
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
##
# SSL Settings
##
ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; # Dropping SSLv3, ref: POODLE
ssl_prefer_server_ciphers on;
##
# Logging Settings
##
log_format wallarm_combined '$remote_addr - $remote_user [$time_local] '
'"$request" $request_id $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" '
'$wallarm_request_cpu_time $wallarm_request_mono_time
$wallarm_serialized_size $wallarm_is_input_valid
$wallarm_attack_type $wallarm_attack_type_list';
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
include /etc/nginx/conf.d/*.conf;
}
Now we configure the reverse proxy server in /etc/nginx/conf.d/default.conf (presented in the listing below) with upstream to our vulnerable web application. And add the headers of the Webmonitorex platform:
The first two headers are responsible for the WAF operating mode. By default, we will have a monitoring mode, but the second heading says that it will be possible to change it to others in your personal account. The third header is responsible for the entity, which is defined in the settings in your personal account, for collecting and viewing statistics only for specific applications. You can read more about headers in documentation.
upstream vuln_app {
server 172.31.85.6:3000;
}
server{
wallarm_mode_allow_override on;
listen [::]:443 ssl ipv6only=on; # managed by Certbot
listen 443 ssl; # managed by Certbot
server_name juiceshop.k2.local;
ssl_certificate /etc/letsencrypt/live/juiceshop.k2.local/cert.pem;
ssl_certificate_key /etc/letsencrypt/live/ juiceshop.k2.local /privkey.pem;
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
location / {
wallarm_mode monitoring;
wallarm_application 1005;
set_real_ip_from 172.31.85.11;
real_ip_header X-Forwarded-For;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_pass http://vuln_app;
}
}
server {
if ($host = juiceshop.k2.local) {
return 301 https://$host$request_uri;
} # managed by Certbot
listen 80 ;
listen [::]:80 ;
server_name juiceshop.k2.local;
return 404; # managed by Certbot
}
A new node is created in the cloud personal account – DEMO NODE (Figure 3) and a token for the filtering module is generated. Team sudo /usr/share/wallarm-common/register-node -t
After setup, I will show the architecture of our deployed stand for general understanding in the figure below.
Custom rules based on regular expressions and testing
In this section, we will create custom rules to fix some vulnerabilities in the Juice Shop web application. WAF from Webmonitorex has expanded functionality for working with requests.
Improper input validation
One of the main capabilities of WAF is to prevent the exploitation of vulnerabilities during the operational stage of the application before release with a fix. A common mistake during web application development is incorrect input validation. The UI offers a choice of input options, and the developer does not think about the fact that the input data must be additionally parsed in the backend, because the request could be compromised. A striking example of this behavior is the Zero Stars task.
Zero Stars
Let's go to the “User Review” tab and fill out the form, selecting 3 stars. Then we intercept the generated request to the server and change the rating to 0. Send the request to the server. Note that the request was processed by the server and was successfully validated.
The solution to this problem using the Webmonitorex platform is to create a custom rule with attack detection based on a regular expression. Let’s create it in the “Rules” section, select “Create an attack indicator based on a regular expression”, select the attack type – “Virtual patch” and fill in the regular expression – ^[^1-5]$ . This rule will block all POST requests to the URL – /api/Feedbacks with any values in the json body using the rating key, except numbers from 1 to 5.
Let's check. We generate the same request with a rating of 0 and observe that the response returns a 403 error. An event is also generated in the WAF personal account. By expanding it, you can get details of the blocked request.
Admin Registration
This task also involves exploiting incorrect input validation. By adding an extra field to the body of the json POST request when registering an account, you can get administrator rights. Let's intercept the request and add the admin value with the role key. The server response indicates successful processing and registration of an account with the administrator role.
To solve this problem, it is enough to create a virtual patch that blocks POST requests from users to the URL /api/Users, the json body of which will contain the role key. After creating the virtual patch, we see that the request is blocked.
Upload Type
This task indicates that there is an active check for the type of downloaded file only at the front. But by intercepting the request, changing the Content-Type header in the multipart, and adding the binary file directly to the request, you can bypass the restrictions.
Let's change the Content-Type and copy the binary representation of juice.jpg by opening the image using Notepad. Let's insert it into the request.
An important advantage of WAF from Webmonitorex is that it uses Pire regular expressions from Yandex (more details here – https://github.com/yandex/pire). And in this development there is a key function – a regular expression inverter – the tilde icon “~”. In this way, both models of WAF operation – negative and positive – are fully revealed. In rare cases, as in the first problem we considered, you can do without it. So we created a positive rule using the construction [^ … ]Where … – a set of single characters that should not appear in the search word. That is, when creating a blocking rule, on the contrary, we only allow characters in place … . The problem is that within a construct you can only use single characters, not groups that can form a word. And the problem is solved with a tilde. It is also clear that the negative model was envisaged from the very beginning.
Let's again create a custom attack indicator rule based on a regular expression. This time it will not be the field in the json body that is checked, but the Content-Type header in the multipart. Let's write a regular expression ~(^application/(pdf|zip)$) . Tilde inverts the expression. Therefore, only those requests that contain in the Content-Type header either application/pdfor application/zip .
Let's check how WAF works. Let's send an illegitimate request again. The request is blocked.
Changing and adding headers to the server response
For users familiar with NGINX, you will know that in reverse proxy mode, the server can add additional headers to requests that it proxies further. Thus further protecting traffic. But you can go the other way…
In this section, let's look at another function of the user rules of the Webmonitorex platform – adding/replacing headers in the response to a request. This allows you to configure additional protection for the application from attacks.
To demonstrate this feature, we will deploy the Vulnbank application, which simulates a vulnerable online bank. This is done using Docker with one command.
docker run --name vulnbank -p 80:80 -d vulnbank/vulnbank
Now log into your account with the login – j.doe and password – password. And we create a transaction, in the comments of which we will write a malicious script. This is a so-called Stored XSS attack. The script we wrote will be stored in the database and executed every time we want to view the transaction history. The malicious script causes the opening of a new window with the official K2Tech website.
But before we send a request with a transaction, we will use an example to look at another WAF feature – ignoring certain types of attacks. In real cases, this serves to ignore False Positive requests that arrive at the protected entry point. But in our case, we do this so that WAF does not immediately block our XSS injection. We create a rule with an exception. The request data is received in /vulnbank/online/api.php in line urlencoded .
We send the transaction and go to the “History” section. We see that the script is working.
In this example, we'll look at how you can further protect your application from a stored XSS attack. This is done using the Content-Security-Policy header. Using the script-src value, you can limit the source of embedded scripts and also add a nonce. The example shows demonstration example. This is not done in real cases, since the nonce must be dynamic. Let's create a rule with a static nonce that restricts the execution of scripts with a different value or without it at all.
Let's check. The script is not executed, a new window does not open. We also see that no unnecessary requests are generated that would be caused by malicious code.
