Hello, World! ❤️
Today, I have an exciting story about how I exposed admin passwords and gained access to thousands of 3G/4G/5G Industrial Cellular Routers with the help of some old-school vulnerabilities (or rather, misconfigurations).
Before proceeding please note that the following vulnerabilities have been immediately identified and fixed. The manufacturer proactively communicated the vulnerability situation and promptly updated the software to address the vulnerability risks. I confirm that this issue has been resolved by August 2023 without any negative impact. Therefore, the following vulnerability content is for discussion and research purposes only.
CHAPTER 1
Accidental Discovery
A few months back, I shared a search trick on GitHub that allowed you to find thousands of leaked keys and secrets from public repositories. You can check out that search syntax right here. As I was experimenting with it, I realized it could be turned into a Google Dork.
Google Dork is basically a clever search query that you can use on Google to discover hidden, sensitive information on the internet. Here’s the special Google Dork I came up with:
site:*.*:8080 (ext:json OR ext:properties OR ext:sql OR ext:txt OR ext:log OR ext:tmp OR ext:backup OR ext:bak OR ext:enc OR ext:yml OR ext:yaml OR ext:toml OR ext:ini OR ext:config OR ext:conf OR ext:cfg OR ext:env OR ext:envrc OR ext:prod OR ext:secret OR ext:private OR ext:key)
Pretty simple, right? This small piece of code will help me find sensitive files like SQL, config, backups, logs, etc., on a web server running on port 8080, exposed to the world.
As a result, I came across the website http://[REDACTED]:8080/lang/log/system.log. Upon visiting this website, I discovered that it was publicly disclosing system logs, which included internal information.
By deleting system.log from the URL and navigating back to one directory, I noticed a server misconfiguration that allowed me to view the contents or list of files within that particular directory. In this directory, I found an interesting log file named httpd.log.
Upon reviewing its contents, I identified that usernames and encrypted passwords were being logged. 😲
Further, I observed that the application’s login page is accessible via http://[REDACTED]:8080/.
From a quick Google search, I found out that Ursalink is a manufacturer of IoT products in the industrial sector. It was a vendor of remote monitoring, data collection, and automation devices for use in various industrial applications.
I guessed it might be a router login. Upon closer examination of the login page, I came to know that it utilized a JavaScript file called login.js.
What’s the big deal with login.js, you ask? Well, this JavaScript file revealed that the application was encrypting passwords client-side using the CryptoJS library and then sending them to the server.
Upon analyzing the JavaScript code, I determined that the application was using the AES algorithm in CBC Cipher mode, with a hardcoded secret key and initialization vector (IV). Here is a formatted version of the same JavaScript code snippet:
$("#login").click(function() {
var e = $("#username").val(),
n = $("#password").val();
if (0 == e.length) return void $(".error").html(language_class.login.error.username);
if (0 == n.length) return void $(".error").html(language_class.login.error.password);
var o = CryptoJS.enc.Utf8.parse("1111111111111111"),
t = CryptoJS.enc.Utf8.parse("2222222222222222"),
l = CryptoJS.enc.Utf8.parse(n),
i = CryptoJS.AES.encrypt(l, o, {
iv: t,
mode: CryptoJS.mode.CBC,
padding: CryptoJS.pad.Pkcs7
});
n = CryptoJS.enc.Base64.stringify(CryptoJS.enc.Hex.parse(i.ciphertext.toString()
.toUpperCase()));
To further investigate, I quickly created a decryption code and successfully decrypted the previously copied password. Here is the decryption code I used:
console.log(CryptoJS.AES.decrypt("vUZ6I78zsJ/3X8a/60GTvg==",
CryptoJS.enc.Utf8.parse("1111111111111111"), {
iv: CryptoJS.enc.Utf8.parse("2222222222222222"),
mode: CryptoJS.mode.CBC,
padding: CryptoJS.pad.Pkcs7
}).toString(CryptoJS.enc.Utf8));
The decrypted password that I obtained was: electrasystems1
But would this password actually get me inside the application? To validate the severity of this vulnerability, I attempted to log into the application using the username and cleartext password.
Surprise! I successfully gained unauthorized access to the router.
My guess was right, I concluded from the model number that it is an Industrial Cellular Router.
Along with this, I also did port scanning using nmap and found 4 open ports including TCP port 22.
With the help of the same credentials, I managed to log in to the router console using SSH.
To find the owner of the router or the linked organization, I used bgp.he.net to get the information associated with the IP address. Through this process, I determined that the IP address is linked with Telus Communications Inc., a Canadian telecom company.
After a little analysis and gathering information from the internet, I concluded that the IP address is assigned by Telus to the SIM card inside the cellular router. Therefore, it is quite difficult to get SIM-owner/router-owner information to inform/notify about this issue.
