Bit of an odd bug in the SecurityPoint UTM Firewall admin and user panels. During the normal login flow a user starts off with an empty sessionID value, once they authenticate successfully the server returns a filled in sessionID. The bug lies in what happens when the authentication flow fails, it seems like an uninitialized value is used so whatever data happened to be there before gets reused. So if an attacker waits for someone to login to the panel (this bug exists across both user and administrative panels) then fails a login, the recently logged in user’s sessionID will be returned.

From that point there is one major hurdle to overcome, an attacker trying to reuse the sessionID must have the same fingerprint as the original user. The fingerprint is a MD5 of the remote address and the user agent string. this fingerprint is a pretty significant hurdle, as it requires the attacker either compromise the victim’s machine already, or that the panel access be behind a NAT so all access comes from the same REMOTE_ADDR.

One attack avenue the author didn’t explore was MD5 collisions, the attacker does have complete control over the user-agent. So what really needs to match is teh md5(remote address|user-agent) and not the actual remote address and user-agent strings. Getting a collision, especially when its fairly blind as you don’t know the expected hash but I can imagine some environments where you could reasonably predict the user-agent being used and a limited IP range so the collisions could be generated offline and just tested against the live service once generated.