Paxton Access is a UK-based company specialising in access control solutions. Their products cater to a wide range of security needs in various sectors, including commercial, educational, and healthcare facilities.
One of the key products from Paxton Access is the Net2 software. This is a centralised access control system. The Net2 software allows for the control of access points in a building or across multiple sites.
During some downtime, I decided to take a look at the Net2 software after seeing it in use on a client’s site.
With the application installed I started to look around the installation directory and found what looked like a private key. Curious to understand what it was used for; I search for files that referenced it and found the below:
@echo off
REM *********************************************
REM Create a certificate
REM *********************************************
pushd %~dp0
if "%1" equ "" echo Invalid command line & goto :eof
if "%2" equ "" echo Invalid command line & goto :eof
REM Default configuration (host supplied)
set DEVICENAME=%1
set subjectAltName=@alternate_names
set password=%2
echo %password% > c:\pass.txt
echo %DEVICENAME%: %subjectAltName%
REM Create the certificate key
openssl genrsa -out %DEVICENAME%.key 2048
REM Create the signing request
openssl req -new -key %DEVICENAME%.key -out %DEVICENAME%.csr -passin
pass:%password% ^
-subj "/O=Paxton Access Ltd/L=Brighton/ST=East
Sussex/C=GB/OU=Net2/CN=%DEVICENAME%" -config openssl-v3.cfg
REM Generate the certificate using the csr and key along with the CA Root
key
openssl x509 -req -in %DEVICENAME%.csr -CA Paxton-CA.crt -CAkey Paxton
CA.key -CAcreateserial ^
-out %DEVICENAME%.crt -days 7300 -sha256 -extensions v3_ca -extfile
openssl-v3.cfg -passin pass:%password%
echo.
if exist ..\nginx\certificate (
REM Copy certificate and clean-up
reg add "HKLM\SOFTWARE\Paxton Access\Dms\Certificate" /v Created /d
"%date% %time%" /f /reg:64
copy %DEVICENAME%.crt ..\nginx\certificate
copy %DEVICENAME%.key ..\nginx\certificate
del %DEVICENAME%.*
)
del *.srl
del *.csr
REM Remove old certificate
if exist ..\nginx\html\%DEVICENAME%.crt del ..\nginx\html\%DEVICENAME%.crt
It appears that they are using the key to sign a certificate for the machine where you are installing Net2 – interesting I thought, but I wouldn’t trust that certificate so why not just self-sign? Well, that’s because the Net2 installer automatically adds the Paxton CA to your trusted root certificates!
Not only that, when accessing the local Net2 web API, they provide an executable to install the Paxton CA on other machines “in order to access the local API Securely…”:
Keen to prove this was as serious as I thought, I attempted to use the key to generate my own arbitrary certificates, that the host would trust by default after a Net2 installation. The problem though was that the key was encrypted and the password was not in any files that I could easily identify. No matter, it was clear that the batch file used to generate the certificate had access to the key, so I added an extra line to spit the password out to a file:
…
set subjectAltName=@alternate_names
set password=%2
echo %password% > c:\pass.txt
echo %DEVICENAME%: %subjectAltName%
REM Create the certificate key
openssl genrsa -out %DEVICENAME%.key 2048
REM Create the signing request
openssl req -new -key %DEVICENAME%.key -out %DEVICENAME%.csr -passin
pass:%password% ^
-subj "/O=Paxton Access Ltd/L=Brighton/ST=East
Sussex/C=GB/OU=Net2/CN=%DEVICENAME%" -config openssl-v3.cfg
…I hit the repair button on the Net2 installer and watched until a new file “pass.txt” appeared, inside waiting for me was the password! (I’ll leave retrieving this password as an exercise for the reader)
Using this password, I was able to decrypt the CA key:
I imported all the certificates into Burp proxy and configured my test VM to use the proxy, opening a browser and navigating to Google worked as expected without any errors or warnings!
With access to the private key for the Paxton CA, I am able to man-in-the-middle the traffic for any host running a vulnerable installation of Net2 or that has installed the CA as instructed by the Web API. Looking on Shodan, I can see at least 99 servers with certificates signed by this key and likely to have the CA installed:
This finding is particularly serious due to the machines that Net2 is often installed on. Due to the nature of the functionality, it’s installed on machines used by security, IT or front desk usually and with the ability to intercept any HTTPS traffic from those machines, you are sure to find something interesting!
I reported this finding to Paxton, but was advised that it had already been reported a few months prior by the researcher Jeroen Hermans, he has since advised me that he reported the issue in April 2023.
They have since released a patch and no longer install the CA by default. Instead, the software now uses a self-signed certificate by default but recommends that you configure your own.
This finding has been assigned CVE-2023-43870.
I would like to thank Paxton for their support in reporting this issue and to Jeroen Hermans for also finding and reporting this issue. You can find further information from Jeroen @ https://cloudaware.eu.
Timeline
~04/2023 - Initial report from Jeroen Hermans 24/08/2023 – Email sent advising that I had found a significant security issue.
01/09/2023 – Chaser email sent as had not heard anything, received response asking for details, full details provided.
11/09/2023 – Sent email requesting update, advised Paxton dev team are aware of the issue and had been working on it with an expected beta release that week.
18/09/2023 - Receive email with further details on how the Paxton dev team plan to resolve the issue and their projected timeline. Advised that another researcher (Jeroen Hermans) has reported the issue (This was originally reported in April 2023). I requested further details, including the CVE so that I could advise Mitre of the duplication.
19/09/2023 – Receive email advising that Paxton will inquire about CVE and that they have committed to 03/10/2023 for the next update, the day after release of the patch. Advised test case information will be provided no later than 22/09/2023.
03/10/2023 – Receive email advising that Net2 update was released 02/10/2023 and advised that the CVE attributed to this issue was CVE-2023-43870. Email sent asking around public acknowledgment of the issue and a link to the Net2 update.
09/10/2023 – Receive email advising Paxton do not acknowledge the discovery of issues and that a link to the update will be sent. Link to Net2 update received and verified as resolving certificate issue.
It is estimated that the issue took 6 months to resolve.
References
The Lenovo Incident https://en.wikipedia.org/wiki/Superfish#:~:text=com.%5B19%5D-,Lenovo%20security%20incident,-%5Bedit%5D
Mitre CVE-2023-43870https://cve.mitre.org/cgi-bin/cvename.cgi?name=2023-43870
Paxton Net2https://www.paxton-access.com/systems/net2/
Comments