Interview with Dr. Johannes Ullrich, SANS research director and faculty fellow
In early May, Hewlett Packard Enterprise announced and provided patches for a critical password reset bug in its application management tool, Edgeline Infrastructure Manager, that could be used to carry out a remote authentication bypass attack and infiltrate a customer’s cloud infrastructure. The bug demonstrates a common form of vulnerability in one of many third-party platforms that developers commonly work with.
Dr. Johannes Ullrich, the SANS Technology Institute’s Dean of Research and faculty fellow, offers two important advice points to developers: Learn about the risks of all the frameworks you develop to, and always remember to validate, authenticate and control access around HTTP web service requests.
Q: How pervasive is HP Edgeline today?
It’s a big enterprise product with thousands of instances, and more critical because they are used to control large networks. You can manage edge systems in OT and IT networks in one platform, which is one of its selling points.
Q: Please explain how this type of vulnerability impacts developers.
This was one of those very basic authentication bypass vulnerabilities, and something you see pretty commonly. A server on the back end is used to create a mobile, web or cloud native desktop application. The application’s front end sends requests back to these web services. And developers forget that these requests have to be authenticated. So, with a bug like this, an attacker can gain insight into what’s happening on the back end with these web services, then call that function directly, making it an authentication bypass attack.
Q: What is Your Advice to Developers?
Development frameworks make it easy to create a web service and front end for it to connect to, but developers need to make sure that these requests include authentication information, which is often forgotten. Your output also still needs to be appropriately encoded. Newer frameworks may make this easier IF you read the respective guidance on how to take advantage of your framework.
For example, Cisco in 2020 patched some vulnerabilities in its Cisco Data Center Network Manager (DCNM) that would allow attackers to grab a static session key and gain admin privileges through Cisco’s REST API. Developers used this framework to create software, but they didn’t implement authentication and access control features. Other frameworks, such as React Native, Angular and Node.js, make it easy to create these apps but don’t include all the security hooks developers need out of the box.
How can ITSec and developers work together to prevent such risks?
Developers often ask for security advice regarding current frameworks and tools they are working with. At the end of the day, it comes back to old stupid errors we have been making for decades. So, start with threat modelling all the way on the left. Bring all the stakeholders in to talk about threats, risk and compliance—people from your business groups, IT and development groups—to share their different perspectives. For example, IT people worry about SQL injections and password brute force, while businesspeople are worried about business rules that can be bypassed or rules that restrict and choke business.
For example, as a young developer I managed a website that sold women’s shoes. I put an anti fraud feature that seemed cool. If a single user bought more than five pairs of shoes in one session, it was flagged and blocked. Then a movie set ordered a lot of shoes and it blocked, then cancelled the order. Lesson learned. Talk to the business before implanting what seems like a solid security rule. That’s where threat modelling comes in handy: figure out the unacceptable and the acceptable risks, and know who’s signing off on those risks.
Once you apply those rules, how do you validate development, operational and IT rules are carried through build and testing processes?
Get the list of security requirements from your teams on the far left of the project. Implement development, security and functional requirements equally throughout the process. Validate with testing throughout the project lifecycle.
For developers implementing third party code and coming in on the right of the development process, request security documentation from the vendor, including their threat models, their security testing processes and schedules. Software Bills of Materials, which are starting to gain traction, will be part of automating that process.
