At the KPN Security research team we are running over 50 honeypots emulating different protocols. The traffic generated by our honeypots might show trends or a change in tactic by attackers. This blog aims to show how quick some vulnerabilities are adapted and employed in order to hack systems at scale. We chose to select some of the vulnerabilities discovered in 2019. Like every year in 2019 many different web application vulnerabilities have become known. We picked some vulnerabilities at random to see when the vulnerability was published and when we first saw exploitation attempts. The bugs we selected:
About our honeypot
One of the honeypot types we are running is a HTTP based honeypot, it’s a very simple honeypot just responding HTTP 200 to every hit it gets. This way we gain some insight into what kind of scan-based HTTP-traffic is occurring. The honeypot works as follows: any request is logged (headers, URI, parameters) and enriched with a geoip. The system accepts requests on multiple ports related to popular systems suchs as JBoss, Weblogic, SAP and Tomcat. Every request is logged in json format and sent to a central Elastic stack. Using Logstash the URI and parameters are put into separate fields for easier searching. The data we are searching across is all retrieved requests in 2019 for our HTTP honeypot. In this year we’ve seen 1,9 milion+ results.
Weblogic
On 26-04-2019 the Weblogic deserialization vulnerability CVE-2019-2725 and the subsequent bypass for the 2725 patch CVE-2019-2729 where discovered. An incorrect public exploit was released four days later on 30-04-2019 (https://www.exploit-db.com/exploits/46780). At the time there was lots of confusion regarding the exploit as it looks like the cve-2017-10271 exploit. CVE-2019-2725 is a bypass for CVE-2017-10271 and uses different, non blacklisted classes. The interesting thing CVE-2019-2729 fixes a bypass for 2725. In short: lots of confused researchers (me included ¯\_(ツ)_/¯).
Looking for “UnitOfWorkChangeSet” or “FileSystemXmlApplicationContext” in the body allows us to find actual exploitation attempts. This shows us the first real hit on our honeypots was at 19-08-2019. Which is interesting as a public exploit was available since June. A possible explanation can be found in the confusion. Most people assumed the old payload on the new URL was CVE-2019-2725 while in fact it was cve-2017-10271. There’s a real possibility criminal thought the same.
Comparing the oldschool exploitation against the new exploitation shows only 10% of attempts employ the new vulnerability while the rest is all the 2017 vulnerability.
vBulletin
On Monday 23-09-2019 a vBulletin 5.0.0 to 5.5.4 exploit was posted on the FullDisclosure mailing list (https://seclists.org/fulldisclosure/2019/Sep/31). Interestingly enough Zerodiums CEO Chaouki Bekrar commented on the release stating the bug had been sold on their platform for three years before the full disclosure release.
Looking at exploitation attempts we can see the first attempt at 25-09-2019 since then we see a steady stream of attempts. Two days after the mailing list entry was published.
An exploitation attempt URI will contain “widget_php” referencing the vulnerable widget. The request body containing “widgetConfig[code]” followed by the injected PHP code. As an example:
URI:
Body:
The above exploitation attempt password protects the vulnerability. The “eval($code)” is put inside an if-statement. Making the machine vulnerable only to someone including the password in a request. Analyzing the traffic shows that attackers tried to exploit the vulnerability in two days.
After the two days of infections attackers used the password to scan for backdoored systems by injecting “die(@md5(HellovBulletin))”.
Drupal
On 20-02-2019 Drupal fixed an unauthenticated remote code execution vulnerability. The vulnerability existed in any Drupal install lower than 8.6.9. Due to a serialization bug it was possible to inject arbitrary php. We expected to see active scanning for this as soon as the exploit was published (24-02-2019). However, we haven’t seen any exploitation attempts for this vulnerability which is weird. It might be that the attackers are fingerprinting and only trying the exploit on systems they are sure that are vulnerable. Looking at previous Drupageddon exploit attempts yields slightly more results. But seeing as we are looking at 1 year of data only seeing 20 odd attempts is very limited. Below is an example of one of the exploitation attempts we've seen:
Pulse VPN and Fortinet
The pulse and Fortinet vulnerabilities where released at the same time during the “Infiltrating Corporate Intranet Like NSA ̶Pre-auth RCE on Leading SSL VPNs” DefCon talk. Both are classic local file inclusion vulnerabilities allowing an attacker to read arbitrary files from the system. Just recently ZDNet released an article describing how REvil ransomware groups are using the Pulse vulnerability to find an entry into networks. The vulnerabilities are both path traversal vulnerabilities used to leak sensitive information. Exploitation attempts look like the following:
Pulse SSL VPN CVE-2019-11510:
Fortinet SSL VPN CVE-2018-13379:
No direct exploitation attempts for the pulse vulnerability where found. However, searching for the string “dana-na” shows attempts to fingerprint the version of an installed Pulse VPN server “/dana-na/nc/nc_gina_ver.txt”. The first attempts to fingerprint our systems was received on the 20-08-2019, 6 days after public release. There is a real possibility that once the correct version is being sent further exploitation would occur. Or that the information is stored for later exploitation.
We do see exploitation attempts for the Fortinet vulnerability, direct exploitation attempts started on 28-08-2019. The initial increase in scanning dies down towards the end of august then only occurring sporadically. After this we do observe steady requests form the “/remote/login?lang=en” URL, possibly indicating external fingerprinting for specific versions.
Conclusion
Our simple HTTP honeypot could be greatly improved by adding the ability to add certain proper responses. Often criminals first probe and check the content of a response in order to see if something is vulnerable. Adding the ability to do this could help in further gaining information on how these attackers are operating. However, this simple approach already gives us the ability to identify new activity, specific dropsites and even malware samples.
It’s interesting to see how quick criminals adjust and employ the latest exploits in order to infect systems. Once a public exploit has been released it takes days instead of weeks for them to weaponize them. Take for example the vBulletin vulnerability after two days attackers were actively trying to password-protect the vulnerability leaving the system open only for them. Any software that is used in the enterprise could be an interesting target for attackers. An attacker with an index of vulnerable systems could try to attack them or resell the information to groups specialized in monetizing corporate breaches. For example some of the REvil affiliates.