Every application eventually reaches "End of Life" - the point where it stops receiving updates and security patches. Sometimes the vendor sunsets the product, sometimes the maintainer walks away, sometimes the company gets acquired and the new owner doesn't care. Whatever the reason, organizations end up running software that will never be fixed.
This blog uses a retired application called Omega Enterprise Gateway to show what that risk looks like in practice. We'll walk you through how Sprocket decompiled the application's .NET assemblies to find a critical authentication bypass that will never be patched.
What is Omega Enterprise Gateway (OEG)?
So often in penetration testing, we are trained to focus on many classic high impact scenarios, such as phishing employees, obtaining sensitive data, or lateral movement & privilege escalation in Active Directory networks. More often overlooked are the applications that control or monitor the physical world we live in - which might be a scary thought. So where does the OEG application fit in to what we are discussing?
Omega Enterprise Gateway sits in the monitoring layer that connects sensors and gateways to dashboards, alerting, and data retention. It typically does not actuate equipment, but it influences outcomes because operators and downstream systems trust its readings and alarms. It ingests measurements such as temperature, pressure, humidity, and flow, stores historical records for audits, and notifies staff when values exceed thresholds. In environments like cold storage, regulated labs, cleanrooms, and production lines, that monitoring and alerting layer is critical. A security issue here can lead to loss of visibility, integrity problems in recorded data, missed alarms, or a network foothold that enables lateral movement toward OT systems.
A user who is tasked with logging in to this application will see the following login page when accessing it:
Right from the jump, we can see the application deploys with the default credentials admin:Omega, and during a penetration test that would undoubtedly be a quick thing to try. In almost a decade of pentesting, I have reported cases of default credentials in production almost monthly. But what might be an option for breaking past this login screen in a case where the default credentials have been properly hardened? We might try directory brute forcing to find some hidden endpoints that are missing auth or leaking data. Perhaps we hit the login form with some SQLi payloads. All good things to try, but occasionally decompiling an application to understand how else it might be flawed can be rewarding.
How Missing OWIN Middleware Authentication Exposes Controllers
After a little bit of poking around in the install directory, we land on the assembly
C:\\Program Files\\OMEGA Engineering\\OMEGA Enterprise Gateway\\Omega.Infrastructure.ServiceManager.exe:
For those unfamiliar, OWIN (Open Web Interface for .NET) is a specification that allows .NET applications to run web components independently of IIS. The Startup class includes a Configuration method where features such as authentication, cross-origin handling, and routing are added to the application's request handling flow. If you are familiar with IIS <modules> defined in the IIS configuration file, you are familiar with this concept already. Same pipeline pattern, same ordering sensitivity, same consequences when misconfigured. The difference is just that IIS modules are declarative (config file) and coupled to IIS, while OWIN middleware is programmatic and runs in any host, including a standalone Windows service like OEG. The takeaway is simple; if authentication isn’t registered in this pipeline, every endpoint behind it is open unless the developer explicitly locked it down.
Why the ResetPassword Endpoint is Accessible Without Authentication
Ok... so the application is missing authentication enforcement at the middleware layer. There is still opportunity for a controller level authorization requirement though. Remember, in ASP.NET Web API, if there's no global auth filter and no [Authorize] attribute, every endpoint is pre-auth. Let's take a look at a critical controller!
If we think about what controllers might be relevant to authentication bypass, the login controller is an obvious choice. Perhaps the second most obvious choice is the ResetPassword flow for a given application. While we would expect the "Forgot Password" flow for a given application to be available without Authentication, the "Reset Password" flow we tend to associate with a more privileged workflow. One where the user has already proven they know their existing password, but want to reset it. Of course this isn't always the case... but in more than one case in the history of testing web applications, not having a hard line in the sand between these functions led to authentication bypasses and account takeovers.
[HttpPost]
[Route("~/user/ResetPassword")]
public async Task<IHttpActionResult> ResetPassword(dynamic parameters)
{
bool result = false;
string email = parameters["user"]; // user-controlled
string password = parameters["answer"]; // user-controlled (NEW password)
// ...
result = await _userDataProvider.ChangeOrgAdminPassword(email, password);
msg = (result ? "Your password is reset." : "Failed to reset password");
// ...
}
Lets translate the abbreviated code above into a simpler statements.
- We are dealing with an HTTP POST request
HttpPosttohttp(s)://example.host/user/ResetPassword - There is NO
[Authorize]declaration, so the POST request can come from a pre-authenticated user - Two user controlled values are needed for the POST request -
userandanswer - Assuming the two values are provided and valid, the POST request will succeed and the supplied users password will be changed.
This means that a pre-authenticated user needs NO special access and simply needs to know the username of the user they want to target during password reset. This isn't difficult when we consider the application has a default user - admin
This is a good time to sneak in an honorable mention to those who disable or rename default accounts!
In other words, we can simply send:
POST /user/ResetPassword HTTP/1.1
Host: 192.168.1.3:8181
Content-Type: application/json
Content-Length: 38
{"user":"admin","answer":"NewPassw0rd1!"}
And we will receive:
Lastly, we try the new password:
Great success!
Taking the time to look at all the other controllers that lack authentication requirements, the above ends up just being one of many sensitive actions that should be decorated with some [Authorize] tags - but for the sake of this blog, these points are proven:
- IT Admins: Running applications after they are retired, sunset, or "end of life" is high risk. Vulnerabilities like this can leave organizations scrambling to find mitigations or replacements for critical systems. This is usually more time consuming than pressing the vendor for an urgent patch.
- Devs: Never assume that functionality which is not exposed in the web user interface cannot be reached. This is the concept of security by obscurity - or in other words, the concept of hoping users don't find a specific value or function, and that being the only security control around that value or function.
Impact
The impacts might not be as obvious when compared to traditional goals of "Domain Admin to own the network" or "SQLi to dump the database"- but when we think through what these systems that live between traditional IT and OT systems we can come up with the following:
1) Loss of visibility and delayed response
If an attacker can crash OEG, disable services, break collectors, or corrupt the database, operators lose the dashboard and the alarm layer they rely on.
- Practical effect: a freezer warms up, a cleanroom drifts out of spec, or a process line runs “wrong” for hours before anyone notices.
2) Alarm suppression or alarm flooding
If the compromise lets someone change alarm thresholds, notification routes, or alert rules:
- Suppression: real excursions never page anyone.
- Flooding: constant false alarms create alarm fatigue and people stop trusting alerts.
3) Data integrity and audit-trail damage
OEG stores history for troubleshooting and compliance. If an attacker can alter, delete, or backfill records, the impact is often:
- failed audits or investigations,
- inability to prove conditions stayed within limits,
- “we don’t know what happened when” during an incident.
4) Pivot into adjacent OT/IT systems
OEG often sits on a network that touches both worlds and may integrate with other systems (e.g., OPC consumers, other monitoring servers, cloud connectors). A compromise can lead to:
- a foothold to reach other OT hosts,
- credential harvesting (service accounts, device creds),
- lateral movement into broader corporate IT if it’s domain-joined or shares infrastructure.
In the case of a real Sprocket client, the OEG deployment was never complete. The deployment was still mostly default and there was no data of value within. This is where #4 (Pivot into other system) becomes the most desirable outcome as a tester. We took the time to break in to the administrative interface of this web application just to find it wasn't ever in production. Bummer... but not a complete disappointment if we can turn this trusted network node into a useful pivot!
Wrapping Up
During this exercise we discussed what it means when software is no longer actively maintained. We used a live example of software that both falls into this category and is critically vulnerable. To find the vulnerability we used JetBrains dotPeak and inspected the relevant application assemblies to demonstrate how authentication flaws can be discovered within an OWIN application. Finally, we brainstormed potential real world or physical impacts that could occur as a result of compromising a host that monitors OT systems.
Keep an eye out for the Part 2, where we will dive back in to the code and maybe we are lucky enough to find a code execution bug! Check the classic calc.exe popped sneak peak image below!
If you are in charge of critical systems like those discussed in this blog, contact Sprocket about our Attack Surface Management (ASM) and Continuous Penetration Testing (CPT) offerings today!
