Steve Gibson (128:43)
Okay, for this week's podcast topic, I wanted to focus upon an interesting vulnerability that will not make any headlines. As I dug into the story, I started to get a sinking feeling. Not about it specifically, but about something we often touch on here, which is the state of today's cybersecurity environment. I titled today's podcast the Sad Case of Scriptcase. Not because what I discovered about Scriptcase was special. What was sad about Scriptcase was that it was not special. So let's first back up to take a look at the flaw which somewhere around 2800 of Scriptcases users have remained vulnerable to months after it was discovered and patched by its publisher. Then we'll look at what all this means. The score the the story here begins with a vulnerability disclosure posting by the well known cybersecurity company Synactive. We've mentioned them often. They're posting on the 4th of July was titled Scriptcase Pre Authenticated Remote Command Execution. Now everyone who follows this podcast will be well aware of the severity of the inherent problem of any pre authenticated remote command execution. Pre authenticated means that anyone, anywhere can remotely execute commands on the targeted system without any need to be authenticated because this remote command execution is able to somehow be induced before any authentication is required of them. That being the case, we would not be surprised to see the severity of this was set to critical because indeed it is. Synactive wrote Scriptcase is a low code platform that generates PHP web applications. Developers use a graphical user interface to design and generate their website. Production Environment is the name of an extension of Scriptcase that will be called Production Console in the advisory for clarity. It's an administrative field to manage database connections and directories. While Scriptcase itself is not necessarily deployed with the website, the Production Console mostly always is pre authenticated. Remote command execution is achieved by chaining two vulnerabilities. The first is the ability to change the administrator password of the production console under certain conditions, and the second is the simple authenticated remote command execution in the connection features where user input is directly concatenated to an SSH system command. Okay, that's just bad design, but okay, okay, so this seems rather, you know, like a straightforward mess for anyone who has this system deployed in the field. Synactive discovered a means for remotely changing the administrative password, and they also discovered that remote user supply data is being directly concatenated onto an SSH command. The ability for an anonymous unknown remote user to remotely change an administrative password is clearly a very big mistake. We all know that. I draw a distinction between mistakes that happen and policies or designs that are necessarily the product of some deliberation. When you hear that a system allows anyone to remotely change an administrator's password, you think that it must be a horse horrible bug. But digging into the details of this reveals that the author of this system failed to provide the safeguards we all live with daily. Specifically, any new password can be set without the user providing their current password. Wow. So this too was a design level decision. So here are the interesting details of this first mistake There's a flaw in the system's PHP code logical flow. The first thing the change password function does, which can be invoked remotely, but the first thing it does is check to see whether the user's session has an isauthenticated variable defined for it. Since the is authenticated variable is only created inside the initialize session function, the intent was that only someone who has already authenticated would be able to change their password. You know, this perhaps excuses the lack of need to provide the current password, though if that had been required, this house of cards would not have collapsed. The clear intention was that at the time the user was being authenticated, the initialized session function would be called to initialize the session, and that would define the is authenticated variable for the future. What the author of this code failed to take into account is that even a failed login attempt, trivially caused simply by directly calling the login PHP function with an HTTP get query, causes the initialize session function to be called, and thus the isauthenticated variable would be created. At that point, the system falsely believes that the user's session has been authenticated, and the change password function, which checks for the presence of that variable, will then allow itself to be remotely called. And since that function requires no provision of the user's current password, any unauthenticated remote user is able to set whatever password they choose for the system's administrator simply by deliberately failing a first login attempt, setting the administrative password to anything they wish, then logging in for real. So we have an unintended code path coupled with the bad design pattern of not always requiring a user's current password when they're requesting its change. And we have the first half of a critical remote command execution vulnerability. The synaptive guys wrote an attacker can arbitrarily reset the password of the administrator of the production console. So take it over. With this accessibility, the attacker could retrieve database credentials and get access to them. As the production console is also vulnerable, the attacker could also leverage it to gain access to the server recommendation. Access to the password reset feature should be given only to authenticated users, which is, you know, change the condition checked by the password, but by the change password function. Also, it should be based only on the session cookie. The change password function should not take an email argument from the user, but extract it from the session while waiting for an official fix from the vendor, one should restrict the access to the scriptcase production environment extension, completely blocking and then they give a couple PHP files that that should be blocked, which would be enough to prevent any unwanted connection, as well as the exploitation of the password reset vulnerability. So at this point in the flow of the of the exploit chain, essentially we've remotely logged on as the systems administrator. So now what the now what is the exploitation of CVE 2020 547228? The first one was 27, this one is 28 a shell injection allowing remote command execution. The exact sequence of actions here is somewhat too dense to explain verbally on the podcast, but the situation is similar to what we've already seen. The developer of this low code PHP driven website creation system developed a system to allow less sophisticated users to create a complex PHP driven website using a graphical user interface. The idea was that it would not be necessary to understand PHP to create a website. Unfortunately, Synactive's analysis of the design and implementation of the tool would lead an impartial observer to conclude that this tools developer also failed to fully understand the operation of PHP enough to create a system that not only worked, but also worked securely. So what are the real world consequences of all this? For that we turn to vuln checks Vuln Checks V's recent posting last Thursday, which is what brought all this to my attention. On August 14, V posted under their headline Script Case Hunt it, Exploit it, Defend it. They began with three key takeaways. First, hundreds of scriptcase instances remain exposed a month after disclosure, with attackers actively scanning for them. Second, exploitation is simple, requiring only a few curl commands once a target is found, allowing full remote code execution. And third, clear detection paths exist and including version strings, network signatures and suspicious processes or PHP files in the webroot. So they write. One month ago, Synactive published their disclosure and deep dive on the vulnerability chain affecting Scriptcase. The vulnerabilities CVE 2025, 4722, 27 and 28 or an unauthenticated password reset and an authenticated command injection that when combined, give an unauthenticated attacker full remote code execution. And yet, despite public disclosure, functional exploits and available patches, hundreds of scriptcase instances remain exposed on the Internet. That leaves the obvious question, does this matter enough to go hunting at Volumcheck? One way we determine if a vulnerability matters is by looking for targets online. The logic is pretty easy if there are zero targets online. Well, who cares if there are many targets online, then we care if it's somewhere between zero and many? Well, it depends. Naively, we started with a Shodan query of the title scriptcase. The results were annoying. Annoying because there aren't real script because they aren't real scriptcase servers at all. These are honeypots, Franken pots that seemingly polluted every single query we've written about before the problem in quote there are too many damn honey pots, unquote. And this is another textbook case. But the fact that there are honey pots suggests that others care about scriptcase too. So we grabbed a copy of the software, built a Shodan query to avoid the decoys, and in a rare win even got a simple Google search to find to to to work for finding actual instances. And they said AI slop. The AI slop ification of Google has largely destroyed this. So this felt like a small miracle. They said the volume check Initial and Access Intelligence team routinely develops queries for Shodan, Fofa, Zoomye and Census to track down vulnerable targets. While building out our fingerprints for scriptcase on these services, we also found that our friends over at Driftnet had turned up a solid hit count of roughly 2800 Scriptcase servers exposed to the Internet via their scan content functionality. So 2800. Finally, it's not just researchers looking for Scriptcase. Gray Noise is tracking a couple dozen known malicious IPs scanning specifically for Scriptcase. That's proof attackers are on the hunt too. At the end of the day, you've got all the ingredients to answer. Does this matter? There are discoverable targets online, there's a public proof of concept, and attackers are actively looking for these systems. That matters. And now we've determined that this matters. They're now looking at exploitation. They said if finding vulnerable scriptcase servers is straightforward, exploiting them is even easier. Synactive's blog and Proof of Concept go into detail, but the reality is that it boils down to just a few curl commands, no custom tooling required. Once the password reset has been achieved, we can navigate to the production environment login page and authenticate with the new credentials. And they show script cases. Very nice looking production environment login page with a password that they provided to Scriptcase and then they provide to the login page which logs them in. They said once authenticated, we land in the production environment. With access to the production environment, we can move to exploiting CVE2025 472 28A command injection vulnerability in the content. I'm sorry, in the connection creation and testing feature, the injection logic lives in a modified version of the third party library ADoDB first, the command is built in in str understore command using attacker provided variables. With a web shell or reverse shell in place, the exploitation chain is complete. But that's only half the story for Defenders. The question becomes how do you spot this activity before or after it happens? Defenders should check whether their scriptcase deployment is vulnerable by default. The landing page exposes a version string in its HTML which can be compared directly against patched releases. We built a passive version scanner to run across shodan data and 57% of observed instances still reported a vulnerable version. That's of the publication. That's as of the publication date, which was last Thursday. And they conclude whether you're hunting, exploiting or defending the playbook is straightforward. Know how to find vulnerable targets, understand how the exploit chain works, and have a clear detection and response strategy in place. The attackers looking for Script Case aren't waiting for you to patch. And the sooner you close those holes, the less likely you are to see your own server in someone else's shell prompt. Okay, so one final piece of this that I didn't yet share was back at SYN Active's disclosure timeline. In their disclosure, although they patiently they didn't complain about this in their posting, they patiently waited until the 4th of July before their public release. And there's no doubt the developer behind scriptcase tried their patience. They show in their in their disclosure timeline that it was on February 18th of this year that they first sent a message to the editor at Script Case. They got first contact live via T chat. I don't know if that means telegram or what or, or T chat might be, you know, on the website because they do have a support chat on the website that was on. So they sent their first message on February 18th. Chat occurred on March 12th. On March 20th, their advisory report was sent to the editor. It took eight days until March 28 to get the first response from the editor. On April 4, the editor asked to retest the vulnerability on the latest version. Meaning apparently they didn't even check it themselves. They said, well tested on what we have now. On the 29th, Synactive confirms the vulnerability still works on the latest version. Then on May 15, synactive contacts the editor for a status update on the progress of the vulnerability analysis. Because they had heard Nothing, they waited two weeks. On May 30, synactive contacts the editor for status update on the progress of the vulnerability analysis. Still nothing on. On June 5, Synactive sends the exploitation script to the editor and and basically said, okay, we're releasing this publicly in a month. So you know you've had many months to fix this, you guys. And on July 4th they make their public release, full disclosure, proof of concept, everything any attacker needs to attack these systems. So from their initial contact which occurred on the 18th of February, to their eventual release of the exploitation details on the 4th of July, nearly five months elapsed with Synactive typically responding within days and Script cases side often responding either never or only after several weeks had had transpired. As I've repeatedly observed, this bizarre system of vulnerability and reporting and updates and patching and often never patching is badly broken. Now Scriptcase which is at www.scriptcase.net has one of those stunning, lovely state of the art websites with beautiful graphics, happy people, tasteful imagery and design that would inspire confidence in anyone who visited. The company is based in Orlando, Florida and along the bottom of the first page the names of several of their more prominent 45,000 plus customers scroll by. If you wait a minute, you'll see the names of Bosch, hp, Hyundai and Yamaha slide past. One reason Scriptcase might have taken so long to respond to Synactive's many attempts to communicate is that their developers appear to be far too busy just trying to keep up fixing the many other problems that appear that this product has and appear to be broken. I thought that Microsoft was bad. Okay, Microsoft is bad, but these guys are even worse.
