Blue Vs Red: write-up 1

Andrea Dainese
September 22, 2022
Post cover

During the last “Blue Vs Red” events, together with Rocco Sicilia , we discussed how to attack and defend a simple, all-in-one, WordPress site. This post serves as a memorandum to remember all topics we discussed and how we reacted to specific attacks.

Attack surface analysis

Because the scenario has been built from scratch, we discussed this topic in theory. We realized that Shodan, Censys, ZoomEye offer a lot of information without the necessity of probing the target.

Those Internet probes could be filtered by a firewall, ingesting an updated IP feed. One of the tools which can grab, enrich and combine external feeds is MineMeld . the feeds provided by MineMeld could be ingested by firewalls.

Active analysis

In the active analysis we used some web discovery tools , Nmap , dirbuster , and WPScan . In less than two hours the Apache access log reported more than 26000 requests.

We could rate limit the connections using a firewall, but with iptables rate limit could lead to a DOS . Enterprise firewalls or WAFs can identify network scanners and rate limit users’ connections.

Regarding WPScan we realized that a simple directory containing a README file could be reported as a vulnerable plugin: following this approach we could add a lot of fake vulnerable plugins so attackers cannot figure out what is installed.

We also decided to reduce the Apache fingerprint:

ServerSignature Off
ServerTokens Prod

We also installed WP fail2ban to detect Wordpress login bruteforcing attacks, and ideally that logs could be ingested by a SIEM or by fail2ban .

We also discussed how Apache should serve default virtual hosts: we know that network probes (Shodan, Censys, ZoomEye…) scan IP addresses, not (yet) domains. If we configure the default virtual host to return HTTP 400 for all requests, we reduce the amount of information an attacker can easily retrieve.

Finally, from both performance and security perspectives, we should monitor HTTP errors (40x, 50x) and detect anomalies: a SIEM could do that, but so it does a performance dashboard. A SOAR could automatically add the malicious IP addresses into a feed ingested by the firewall.

Slowlorice attack

We discussed the slowlorice attack but we didn’t test it: basically, a slowlorice attack uses a lot of established TCP connections with an incomplete HTTP request. Even with a slow Internet connection, an attacker can take down a powerful web server. This attack can be reduced by WAF but it can also be mitigated tuning the Apache configuration (with the reqtimeout module):

RequestReadTimeout header=1,minrate=500
RequestReadTimeout body=1,minrate=500

The configuration can be validated with:

slowhttptest -c 400 -H -i 10 -r 200 -t GET -u http://Target_URL -x 24 -p 5

To Be Continued…

References

References