A lot of next gen firewalls have the ability to tag web browsing with a user associated to the computer it came from. I'm going to show you how to change who the firewall thinks you are for Palo Alto User-ID, and likely other devices.
Palo Alto uses a secondary software package called User-ID Agent. This software monitors the event log on domain controllers and pulls the username associated with a computer from the event log. So when you logon an event is registered with the domain controller, User-ID Agent pulls the info and updates it's data with who is logged in.
If you do a runas /user:domain\user (must have the actual credentials) and start any application, that will register on the domain controller as a new logon to that computer and will adjust the user appropriately. It does not change back or register as "no user" if there is a logoff, only logons change it. So from that point on all traffic is associated with a different user, still your IP address but it says "User x was logged into the computer at this time".
Palo Alto can do traffic filtering by user id, so if you knew the login for an account that is unrestricted, as far as the firewall rules are concerned, you could login as yourself, do a runas and start a cmd prompt (or whatever) then close it and all your traffic will be reported as belonging to the other user possibly bypassing rules setup to block other users traffic.
Or you could hang some co-worker as you went to some horrific granny-tranny spanish-mistress bondage porn site and it got registered in the firewall logs and now HR and IT will be grilling some poor soul about their internet browsing habits.
Things such as opening outlook will revert back to being reported as your user is logged into the computer as it authenticates to AD. Anything that authenticates to AD will create a logon event and will change the user reported as logged on to the computer.
Wednesday, July 17, 2013
Connect to an SSL page through a Socat Proxy
So lets say you have a device, at a remote location, that has a SSL web page. You can only access it from the local subnet and you don't want to disrupt any users to kick them off their machine.... or you plan to bounce off a client there, maybe without their knowledge.
We will make the following conditions for this example:
You're in the 192.168.20.0/24 subnet.
You can access subnet 192.168.3.0/24
192.168.3.11 - device with an ssl page that is accessible ONLY from the 192.168.3.x/24 subnet 192.168.3.20 - device you have access to on that subnet
192.168.20.10 - your machine
We can use Socat to make the connection because it has the option for an openssl connection type.
Copy over Socat, and it's dependencies:
cygcrypto-0.9.8.dll
cygminires.dll
cygncurses-8.dll
cygreadline6.dll
cygssl-0.9.8.dll
cygwin1.dll
cygwrap-0.dll
to the 192.168.3.20 machine and issue the following command:
socat TCP-LISTEN:8100,fork OPENSSL:192.168.3.x:443,verify=0
This tells socat to start listening on 192.168.3.20 port 8100 (or whatever port is available), and fork incoming connections so it can handle multiple connections at a time.
*Fork is not really necessary for this example, probably better to leave it out, but if you need multiple connections to the device you need the fork option.
Then send that traffic over an openssl connection to 192.168.3.11 port 443 and NOT to verify the ssl cert for the page you're trying to connect to (verify=0).
*You can change it to verify the ssl cert (verify=1) but if the certificate is not correct, ie self signed, or intended to be used on a public site and you're accessing it internally, etc. the connection will not succeed.
Then on 192.168.20.10 open your browser and put in 192.168.3.20:8100. Viola you have access to your SSL site that requires a connection from the local subnet.
Now, before we go any further the connection between 192.168.20.10 and 192.168.3.20 is NOT encrypted, that means anyone sniffing the traffic will see everything that's sent between 192.168.20.10 and 192.168.3.20. That's bad. Especially since you're probably going to have to type in credentials to access the page, and if the sniffer misses that, then there's still the cookie that can be stolen as well.
Traffic between 192.168.3.20 and 192.168.3.11 IS encrypted, BUT since we have verify=0 it will accept a forged certificate. That's also bad. But if the device has an invalid cert to begin with there's nothing we can do about it.
You can secure your connection between 192.168.3.20 and 192.168.20.10 by generating ssl certificates Instructions can be found here but that requires access to a system with openssl or some other cert signing software and since you're likely to be dealing with windows machines that's unlikely to be handy, but it can be done. You would need to change TCP-LISTEN to OPENSSL-LISTEN also.
We will make the following conditions for this example:
You're in the 192.168.20.0/24 subnet.
You can access subnet 192.168.3.0/24
192.168.3.11 - device with an ssl page that is accessible ONLY from the 192.168.3.x/24 subnet 192.168.3.20 - device you have access to on that subnet
192.168.20.10 - your machine
We can use Socat to make the connection because it has the option for an openssl connection type.
Copy over Socat, and it's dependencies:
cygcrypto-0.9.8.dll
cygminires.dll
cygncurses-8.dll
cygreadline6.dll
cygssl-0.9.8.dll
cygwin1.dll
cygwrap-0.dll
to the 192.168.3.20 machine and issue the following command:
socat TCP-LISTEN:8100,fork OPENSSL:192.168.3.x:443,verify=0
This tells socat to start listening on 192.168.3.20 port 8100 (or whatever port is available), and fork incoming connections so it can handle multiple connections at a time.
*Fork is not really necessary for this example, probably better to leave it out, but if you need multiple connections to the device you need the fork option.
Then send that traffic over an openssl connection to 192.168.3.11 port 443 and NOT to verify the ssl cert for the page you're trying to connect to (verify=0).
*You can change it to verify the ssl cert (verify=1) but if the certificate is not correct, ie self signed, or intended to be used on a public site and you're accessing it internally, etc. the connection will not succeed.
Then on 192.168.20.10 open your browser and put in 192.168.3.20:8100. Viola you have access to your SSL site that requires a connection from the local subnet.
Now, before we go any further the connection between 192.168.20.10 and 192.168.3.20 is NOT encrypted, that means anyone sniffing the traffic will see everything that's sent between 192.168.20.10 and 192.168.3.20. That's bad. Especially since you're probably going to have to type in credentials to access the page, and if the sniffer misses that, then there's still the cookie that can be stolen as well.
Traffic between 192.168.3.20 and 192.168.3.11 IS encrypted, BUT since we have verify=0 it will accept a forged certificate. That's also bad. But if the device has an invalid cert to begin with there's nothing we can do about it.
You can secure your connection between 192.168.3.20 and 192.168.20.10 by generating ssl certificates Instructions can be found here but that requires access to a system with openssl or some other cert signing software and since you're likely to be dealing with windows machines that's unlikely to be handy, but it can be done. You would need to change TCP-LISTEN to OPENSSL-LISTEN also.
Subscribe to:
Posts (Atom)