CVE-2020-5770: Cross-site Request Forgery
The forms at the following locations were found to have no CSRF protection. By tricking a victim user into clicking a link, a remote, unauthenticated attacker can exploit this to completely take over the device.
Proof of Concept
Please see attached csrf_poc_CVE-2020-5770.html for a sample dummy html page, when the form is clicked a POST request will be made to an authenticated users session on a Teltonika TRB245 and upload a backup archive.
To test this you will need to change the IP address in the HTML page to that of a Teltonika TRB245 that you have authenticated to.
CVE-2020-5771: Inadequate Validation of Backup Archive
The device has a backup feature that allows a user to download or upload a backup archive. The backup archive contains the /usr/ and /etc/ directories. According to Teltonika’s documentation, a backup archive can only be uploaded if it was generated from an identical device with identical or older firmware.
However, the checks to verify the above are insufficient from a security point of view. The only check to verify that the archive is from a Teltonika device is to check the output of 'cat /etc/version', as proven in the below proof of concept.
Proof of concept - Uploading a backdoored archive
For this proof of concept we will upload a backup archive which has been modified to include a backdoor user who has root privileges (see tampered_backup.tar.gz). Below are the steps the tester took to achieve this.
Download a backup archive and extract the contents.
Modify etc/passwd to add a new user.
Modify etc/shadow to add a password for this backdoor user.
Compress the two folders.
Upload the tampered archive.
At this point the device will reboot, when the device comes back up we will be able to ssh in with our backdoor user.
CVE-2020-5772: Inadequate Validation of Packages Uploaded
The verification that a given package is the package it is meant to be is insufficient, as can be seen by the following proof of concept. An attacker could tamper with any of Teltonika’s custom packages and add in backdoor access as root. They could then either give themselves root privileges (if they already have a low privilege account) or trick an existing user into installing their malicious package. Below seems to be the only verification of the integrity of the package (a check to /etc/version).
Proof of concept - Installing a backdoored package
As an example the tester downloaded one of Teltonika’s packages from their Wiki (https://wiki.teltonika-networks.com/wikibase/images/3/3b/Networking_trb2...).
Looking at the downloaded package we can see that it is gzip compressed.
We decompress this and find a tar compressed archive.
Inside this archive we find three more files; the data.tar.gz contains two directories /etc/ and /usr/.
What we can do at this point is add passwd and shadow files to the /etc/ directory with the credentials of a new user (for this example the user is called ‘hacker’ ).
Now we repack the package and give it the same filename. When we upload the new tampered package it will overwrite /etc/passwd and /etc/shadow with our own version. It is also worth noting that by default, users in the ‘user’ group have permission to do this.
We can now SSH in as our new ‘hacker’ user who has root privileges.
If you wish to test this yourself please see the attached tlt_custom_pkg_coStreamApp_2020-03-05_mips_24kc_CVE-2020-5772.ipk which contains the tampered package.
CVE-2020-5773: Insufficient Access Control: Users in the 'user' group are able to make changes to device by default
There are three levels of privilege possible to configure on the TRB245 web interface.
The user group is supposed to have no write access whatsoever on the device. However, during testing it was noted that by default members or the user group can make various changes, some of which can fully compromise the system.
Proof of concept
For proof of concept please refer to the above findings, by default both of those exploits can be carried out by members of the 'user' group.
All information within TRA advisories is provided “as is”, without warranty of any kind, including the implied warranties of merchantability and fitness for a particular purpose, and with no guarantee of completeness, accuracy, or timeliness. Individuals and organizations are responsible for assessing the impact of any actual or potential security vulnerability.
Tenable takes product security very seriously. If you believe you have found a vulnerability in one of our products, we ask that you please work with us to quickly resolve it in order to protect customers. Tenable believes in responding quickly to such reports, maintaining communication with researchers, and providing a solution in short order.
For more details on submitting vulnerability information, please see our Vulnerability Reporting Guidelines page.
If you have questions or corrections about this advisory, please email [email protected]