vcenter_saml_login
vcenter_saml_login copied to clipboard
vCenter 7.0.3 Support
I was recently on an engagement and identified a vCenter 7.0.3 server. After troubleshooting this script I determined that this version requires a POST parameter RelayState for successful authentication. This change adds the RelayState parameter to add support for vCenter 7.0.3.
This could break compatibility with older versions and should be tested.
Hey!
I really appreciate the information and pull request. We had reports that 7.0.3 had broken the flow, but hadn't hadn't had time to investigate just yet so this is really helpful!
I have access to a few older instances, so will test the change and work on a solution to get this in.
Thanks again!
I saw those issues! That's the reason I figured I would just ship over the changes I made to get it to work. It's hacky and will probably break something else, but it worked for my instance.
A bit more info about the RelayState parameter in case it's not in older versions. It acts as a sort of CSRF token where it provides you the parameter value in the initial SAML request and you provide it back when you provide the SAML response.
I no longer have access to that version of vCenter so that's about the extent of what I can provide, but feel free to ask any questions to get this working for newer versions.
Cheers!
Hello, sorry to dust off an old issue but I came across this exact issue when attacking a 7.0.3 server (with permission of course :-) today. I was getting the "expected 302 redirect" and tried out @Xerzzul 's modification of the script and it worked (I think!). The script completes and I get the Cookie: VSPHERE-UI-JSESSIONID=xxx
as expected. However, try as I may to load this cookie and chrome and refresh https://ip.of.the.vc
this will NOT get me into vCenter. Background info that may be important:
- I found the data.mdb file from a full backup on the customer's network that an admin had access to.
- When I run the Python script and specify
fully.qualified.domain-name-of.vcenter
the script fails with theException: 302 redirect
message. - However, when I run the Python script with the IP of the vCenter, everything completes and it spits out a cookie like I mentioned.
When I visit https://ip.of.the.vc, I get a JSESSIONID
cookie value. I've tried changing that to the value I get from the Python script, as well as adding a fresh cookie called VSPHERE-UI-JSESSIONID
and when I hit http://ip.of.the.vc/ui
, the page refreshes and I am not logged in, and the browser now says http://ip.of.the.vc/websso/SAML2/SSO/vsphere.local?SAMLRequest=xxxxxx
I'm trying to figure out if I'm chasing my tail but would LOVE if someone could help me troubleshoot?
Hello, sorry to dust off an old issue but I came across this exact issue when attacking a 7.0.3 server (with permission of course :-) today. I was getting the "expected 302 redirect" and tried out @Xerzzul 's modification of the script and it worked (I think!). The script completes and I get the
Cookie: VSPHERE-UI-JSESSIONID=xxx
as expected. However, try as I may to load this cookie and chrome and refreshhttps://ip.of.the.vc
this will NOT get me into vCenter. Background info that may be important:
- I found the data.mdb file from a full backup on the customer's network that an admin had access to.
- When I run the Python script and specify
fully.qualified.domain-name-of.vcenter
the script fails with theException: 302 redirect
message.- However, when I run the Python script with the IP of the vCenter, everything completes and it spits out a cookie like I mentioned.
When I visit https://ip.of.the.vc, I get a
JSESSIONID
cookie value. I've tried changing that to the value I get from the Python script, as well as adding a fresh cookie calledVSPHERE-UI-JSESSIONID
and when I hithttp://ip.of.the.vc/ui
, the page refreshes and I am not logged in, and the browser now sayshttp://ip.of.the.vc/websso/SAML2/SSO/vsphere.local?SAMLRequest=xxxxxx
I'm trying to figure out if I'm chasing my tail but would LOVE if someone could help me troubleshoot?
Did you ever figured this out ?
I didn't - had to find another attack path :-(