Honestly, this is a simple bug, a react website, wiht source maps, so easy to find API endpoints the application calls. Upon examination one of them did not require any authentication, the event stream publishing events from the cameras in a redacted teleommunications company office. As far as the author shows us, the feed contained JSON that contained a base64 of the raw images being sent out periodically.

As a vulnerability its not interesting, and given how often people talk about just finding webcamera streams online, its not that surprising. Its just a reminder to sanity check the APIs, especially in my mind the “odd” endpoints. This one was a server-sent event and those edge cases can often have other unexpected rules applied to them.

This one starts off with a fun mass-assignment issue. Early on in the processing chain of a HTTP request to CrushFTP’s web interface it will parse all the HTTP headers into a Java Propertiesobject. Bascially a key-value store of header names to their values. Then later on if the as2-to header is sent this enter header map will be merged into the active session’s user_info map object with no consideration for headers potentially clobbering existing values in the user_info map.

This is a problem as the user_info map contains information about the active user. Unfortunately the obvious route of corrupting the user_name or user_number values were not useful for authorization bypass as authorization uses a separate variable. However they were able to make used of some of the other information, particular the user_log_* value.

Specially by setting the user_log_path_custom value, the old log file (specified in user_log_path will be copied into the new path and the old file deleted. As an attacker can clobber both the source (user_log_path) and destination user_log_path_custom they get an arbitrary file copy primitive, and effectively a file deletion primitive.

This can be used for obvious information leak, by copying sensitive files like the local filesystem users.xml file into the webroot which is served statically. Or copying the sessions.obj which contains serialized Java objects containing information about current logins and can be used to hijack a current session. Once they are authenticated as an administrative user, there is an arbitrary class instantiation vulnerability in the admin panel that can be aboves for code execution

This vulnerability impacts kubernetes setups using NGINX as the ingress controller via ingress-nginx. At first I wanted to blame this one on block-listing when they should have used an allow-list, but its not quite that, but it is basically just a missed edge-case that allows for code execution.

There is a bit of a high privilege ask as the attacker must be able to create or update ingress objects.

Basically in creating a new ingress the system supports adding an annotation that includes a configuration snippet that’ll be used in the nginx config for the rule. Obviously there are risks with what you can do with that so ingress-nginx already would patch out certain directives like root and alias to prevent reading into unexpected directories. The patch just literally removes the directives from nginx all together.

They did not remove the content_by_lua_block however, which meant someone who can provide one of those configuration snippets could create a location entry that was served by lua provided by the configuration snippet itself.