“Egress filtering is the practice of monitoring and potentially restricting the flow of information outbound from one network to another. Typically, it is information from a private TCP/IP computer network to the Internet that is controlled.” – Wikipedia
During a recent external network penetration test, we were able to leverage application functionality to test our client’s current egress filtering capabilities in an attempt to capture sensitive information. This post will cover some of the tactics used in order to capture sensitive information, as well as common mitigation strategies organizations can take to narrow down outbound traffic.
Egress Exploitation
During the engagement, we discovered a publicly facing web application. While mapping out the application, I noticed there were areas within the application that contained pre-configured Microsoft SQL (MSSQL) connection strings. The connection strings contained information like hostname, database, username, and password. At times, a user can inspect the HTML code to find the password, however in this instance, I was unable to discover the password.
Responder is a toolset that came to mind since it can perform a wide variety of functions, but in this specific instance the built-in HTTP/SMB/MSSQL/FTP/LDAP rogue authentication servers are exactly what we are looking for. With Responder installed on an Internet facing host, we started it with the following command:
sudo ./Responder.py -I eth0
Now that we had Responder up and running, we can switch over to the application. As I stated previously, while mapping out the application, I discovered multiple MSSQL connection string configurations. Looking at the screenshot below, there was a JDBC connection pool alias with previously configured information. The database URL contained the host information the application was connecting to, as well as a user ID and password. Another important functionality was the “Test Connection” feature to verify the connection works.
In the next screenshot below, we changed the database URL to the IP address of our externally facing Responder agent, then clicked the “Test Connection” button.
Next, we captured our Responder window that showed us the application reached outbound via MSSQL and attempted to authenticate to the simulated MSSQL server. The credentials have been blurred to prevent any client disclosure.
Egress Remediation
Larger organizations that haven’t yet implemented egress filtering mitigations might look at this as a daunting task. There are many configuration changes, device implementations, and process improvements that can be made to get egress filtering under control.
Some engress filtering practices that can be done include:
- Firewall – Default Deny
- Default Deny denies any service / protocol not explicitly allowed through the firewall. This is definitely more secure posture, however it does require individuals to understand the flow of information that leaves the network.
- Filter Internal-Only Services
- Ensure that services that don’t typically run across the internet are blocked. Any requirement for outbound access should be filtered to a specific external IP address.
- Implement Web Proxy
- Only allow approved outbound web traffic. Force all web browsers to utilize the web proxy to perform web browsing.
- Business Justification For Outbound Rules
- Ensure there is a documented business justification for any outbound allow rules. The justification should include information about:
- Why the rules were created?
- Who created the rules?
- What applications or users are utilizing the rules?
- Who created / maintains the rules?
- Ensure there is a documented business justification for any outbound allow rules. The justification should include information about: