Collection of auth tokens of multiple subdomains not possible

[edermi]

Today I tried to collect auth tokens. The service that I'm using has cookies for the parent and a subdomain that keep authentication information, but unfortunately I was unable to fetch them using evilginx2.

auth_tokens:
  - domain: '.service.net'
    keys: ['token1', 'token2']
  - domain: 'sub.service.net'
    keys: ['subtoken1', 'subtoken2']

When commenting out the second entry, everything works as expected, but I'm missing relevant cookies that are required for impersonating a session. I also tried:

auth_tokens:
  - {domain: '.service.net', keys: ['token1', 'token2']}
  - {domain: 'sub.service.net', keys: ['subtoken1', 'subtoken2']}

but I guess that's just another way to write this and doesn't make a difference since your parser should anyway give you an equivalent abstraction.

Unfortunately, it's not a service where you may simply register a free account for testing, but I guess this is a simple bug that just has been overlooked and I can help you testing if required.

[kgretzky]

Open Web Inspector in Chrome, go to Network tab and tick "Preserve Log" checkbox. Then do the sign-in and try to find the response packet that sets the cookies in the browser. You should see the "Cookies" tab for that response packet and if you can please post the result (censor the cookie contents of course). That way we can know for which exact domains, the cookies are generated for.

[edermi]

Hi,

thanks for taking a look at it. I took a look at the source and it in theory it should work, but I had no luck during my last tests (but maybe it's my fault, I'll recheck since I gained some insights by reading the code).

I'm a bit uncomfortable pasting the exact name of the service or information pointing to it since it is an ongoing customer project; I hope the censored screenshots are enough:

Those are the requests that set the relevant cookies as well as an overview of the cookies set in the end. As you may notice, some cookies change between images, there are more requests that alter cookies (stuffing useless information in, like the company's corporate identity colors and other pointless shit). They're doing some other weird things (like giving the POST params containing username and password as well as the 2FA token the same name, so it is impossible to filter out with evilnginx) and it seems that at some points they really stress the fact that browsers are quite liberal when it comes to make the web work somehow, so maybe it's just this site and their way of doing things that makes it hard to intercept with evilnginx.

Nevertheless, again, thanks for building evilnginx2 and taking a look at the issue.

[kgretzky]

So if I understood correctly you say that also POST argument names are dynamic and often contain user IDs, for example _8329394_SessionID where 8329394 would be the ID of the user?

If the names contain some static strings like _SessionID it would be possible to solve this by adding an option to use regular expressions for key names, but I'm afraid that some POST arguments may contain only user ID as the key name and then indeed it could be impossible to easily solve.

[edermi]

No, they indeed have same names for username param and password param (Later on, the 2FA-Token is also stored in a textdata parameter....). They do it like this:

Param Posistion	Param Name	Param Value
1	textdata	userEmail
2	textdata	the actual mail address
3	textdata	userPassword
4	textdata	the actual password

Also, the order of the params seems to be not deterministic, it might also be sent this way:

Param Posistion	Param Name	Param Value
1	textdata	userPassword
2	textdata	the actual password
3	textdata	userEmail
4	textdata	the actual mail address

I guess the easiert thing here might be the possibility to assign a regex to the whole HTTP parameter string, but that is rather unrelated to the cookie problem.

[kgretzky]

Moved to #44