In some versions of OutSystems a bug was introduced which alters the way the platform detects the IPs for validation with Internal Network. Previously the platform only checked the originating IP for the request. In the below revisions the platform is checking the X-Forwarded-For header.
This means that a malicious attacker can use this header to impersonate a computer from inside your Internal Network to gain access to Internal Network protected screens / web services.
Since the local loopback interface is always required to be in Internal Network, the attacker always has an IP they can use for this (127.0.0.1) with no required knowledge of the existing configuration.
Affected Stacks and Versions
This problem affects version 9.1, in particular the following revisions:
This issue only affects OutSystems 9 Bali. OutSystems 10 is not affected by this issue.
Internal Network is an OutSystems functionality which limits access to certain screens or webservices based on the originating IP. This allows customers to define that certain functionality, usually back offices and internal web services, are only accessible from a known network.
OutSystems uses Internal Network configuration to add an additional layer of protection to its management consoles (Service Center, LifeTime). However, this mechanism is not the only protection mechanism for these consoles and internal services as these are all properly authenticated. This means the risk for Service Center access when Internal Network is breached is relatively low, giving attackers a way to attempt brute-force attacks on platform authentication which was previously unavailable to them.
Customers using Internal Network in their back office screens and internal web services should review their authentication patterns to properly assess the risk. If Internal Network is the main protection mechanism of some of your services or screens and no other means of authentication are used, you should apply the below solution as soon as possible to mitigate this vulnerability.
How do I Fix the Issue
The next release of OutSystems 9 Bali will have this problem fixed. In the meantime you can execute the following statement on your database to change this behavior:
INSERT INTO ossys_parameter (name, val) VALUES ('OutSystems.HubEdition.InternalNetwork.EnableTrustedProxies', 'True')
After inserting this value to the database, you need to recycle all your application pools in order for the workaround to be effective.
Warning: Applying the above workaround will also modify the behavior of HTTPRequestHandler's GetIP Action. It will make it so that X-Forwarded-For header is NOT followed to determine the origin ip of the request. If you are in an architecture that relies on this, namely when using Reverse Proxies or Load Balancers, please get in touch with Support for proper follow up.