I have a school projet that require me to emulate the CVE-2020-1472 (Zerologon) on a local environment.
I am currently trying to test following github script but I am facing some issue that I haven't been able to solve since then.
To sumerize, I have a :
Ubuntu 16.04 machine with Samba 4.3.8 Domain Controller Active Directory
Windows Server 2019 that joined the domain EXAMPLE.COM that I created with Samba.
I've made several test and I can succesfully modify the password of the "Administrator" account with first part of the POC :
./cve-2020-1472-exploit.py -n EXAMPLE-DC -t 1.2.3.4
Problem comes when trying to run impacket to extract some data from the domain :
secretsdump.py -no-pass -just-dc Domain/'DC_NETBIOS_NAME$'#DC_IP_ADDR
It sucesfully log in but then I get this message :
Password:
[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
[*] Using the DRSUAPI method to get NTDS.DIT secrets
[-] DRSR SessionError: code: 0x20e4 - ERROR_DS_CANT_FIND_EXPECTED_NC - The naming context could not be found.
[*] Something wen't wrong with the DRSUAPI approach. Try again with -use-vss parameter
[*] Cleaning up...
UPDATE 1 :
I also tried to use the -use-vss option but it also fails after login in.
[-] RemoteOperations failed: DCERPC Runtime Error: code: 0x5 - rpc_s_access_denied
[*] Searching for NTDS.dit
[-] 'NoneType' object has no attribute 'request'
[*] Cleaning up...
I tried to get some information about the DRSR SessionError: code: 0x20e4 - ERROR_DS_CANT_FIND_EXPECTED_NC but I didn't found any usefull informations on internet..
I hope someone have already faced this error or have knowledge regarding Active Directory because I'm really stuck
Thanks in advance and have a good week !
UPDATE 2:
I made a post on impacket's github and it seems like the DRSUAPI approach hasn't been tested against a non Windows AD before. So secretsdump wont works.
Every page mentioned SAMBA as vulnerable so I wonder if they really tested to exploit the vulnerability or if it was just a theoretical assumption.
Related
I'm migrating an old Windows Server 2003 AD hosted on a VM to a new one based on Windows Server 2016 (also on a VM).
The Server 2003 (let's call it OLD-AD) was the only Domain Controller. Now I'm migrating this server by installing Active Directory on a new server (let's call it NEW-AD) and adding it as a Domain Controller.
So I followed this step-by-step guide : https://blogs.technet.microsoft.com/canitpro/2014/04/01/step-by-step-active-directory-migration-from-windows-server-2003-to-windows-server-2012-r2/
Except I didn't dcpromo OLD-AD yet to remove it as a DC.
It seems to work (rough translation of the message, our workstations/servers are not in english) :
$> nltest /dclist:mydomain.local
Get the list of domain controllers of « mydomain.local » from « \\OLD-
AD.mydomain.local ».
OLD-AD.mydomain.local [DS] Site : Default-First-Site
NEW-AD.mydomain.local [PDC] [DS] Site : Default-First-Site
But when I shut down OLD-AD, I'm not able to contact a DC for authentification anymore.
Also, this doesn't work :
$> nltest /dcname:mydomain.local
NetGetDCName failed : Status = 2453 0x995 NERR_DCNotFound
I have no idea where to look to get more informations and diagnose this issue. Any pointers will be appreciated !
I've seen this error before. It has nothing to do with your migration procedure. I've reproduced the error then ran it slightly differently with success. Run command like this instead and it will work:
nltest /dcname:mydomain
See example screenshot below:
I've got an instance of sonarqube 5.5 running.
I wanted to use the sonar-ldap-plugin 1.5.1 in order to delegate the authentication and authorization to the Active Directory service of my company.
The configuration for the LDAP plugin is the following (modulo some obfuscation):
sonar.authenticator.createUsers=false
sonar.security.savePassword=false
sonar.security.realm=LDAP
ldap.url=ldap://host.my.domain
ldap.user.baseDn=OU=Users,OU=Organic Units,DC=my,DC=domain
ldap.user.request=(&(objectClass=user) (sAMAccountName={login}))
ldap.authentication=DIGEST-MD5
ldap.bindDn=CN=harmlessServiceAccount,OU=users,OU=Organic Units,DC=my,DC=domain
ldap.bindPassword=<the user password in clear text>
sonar.log.level=DEBUG
And the sonarqube server reports the following error:
2016.07.13 10:19:38 INFO web[o.s.p.l.LdapContextFactory] Test LDAP connection: FAIL
2016.07.13 10:19:38 ERROR web[o.a.c.c.C.[.[.[/]] Exception sending context initialized event to listener instance of class org.sonar.server.platform.PlatformServletContextListener
java.lang.IllegalStateException: Unable to open LDAP connection
...
Caused by: javax.naming.AuthenticationException: [LDAP: error code 49 - 8009030C: LdapErr: DSID-0C0904DC, comment: AcceptSecurityContext error, data 52e, v1db1^#]
...
I did the exact same query with ldapsearch and did not meet any problem. So I think the Active Directory service is correct and accepts this user and the DIGEST-MD5 SASL mechanism.
I also used the same user through sonarqube with the SIMPLE (unsecure) mechanism and it was working "properly" as well.
I also tried to put the md5 hash of the password instead of the password.
And I tried a lot of other things I'm not proud of...
I read many similar issues online (stack overflow, other sources) and couldn't find a solution yet.
Do you see anything wrong in my configuration?
Am I doomed to use the SIMPLE mechanism and let everyone's password move around in clear text?
I cannot use CRAM-MD5 neither GSSAPI as they are not supported by my company's active directory service.
The error code 49, has a subcode in it that tells you what the failure cause was. You reported:
[LDAP: error code 49 - 8009030C: LdapErr: DSID-0C0904DC, comment: AcceptSecurityContext error, data 52e, v1db1^#]
The data 52e part is the key.
Check out the list I maintain here, and you will see that 52e means bad password for your bind user. 525 would be bad DN for your user, so you have the correct LDAP DN, but the wrong password.
I just encountered this and fixed it on sonarqube 6.x. and ldap plugin 2.2
The 52e will be a bit misleading I found as it can be invalid password, but that is also possible if the login is incorrect. http://ldapwiki.com/wiki/Common%20Active%20Directory%20Bind%20Errors
I had the following in my config
ldap.bindDn=domain\query_account
This has worked for other things but not SonarQube. Your line sonar.log.level=DEBUG actually helped me, I turned it on and it showed me the problem, I needed to escape the \ character. So this worked for me.
ldap.bindDn=domain\\query_account
this might not be your problem, but it definitely was mine. Hope it helps.
I'm new to Drupal and recently installed 8.1.2 and the LDAP module. I've been trying for 2 days to connect to our local Active Directory. However, every time I tried to run the server test I got an error: "Failed to bind to server. ldap error #49 Invalid credentials".
I'm sure the settings are correct and the credentials definitely are (I tested direct in Active Directory and in PHP). I also tried an online LDAP connection and that failed with the same error too. I thought maybe it's just the test that doesn't work so I tried logging in with a known AD account but it didn't work. As a final test I just installed Drupal 7 (and the modules for that) instead and with the same settings everything worked perfectly first time (tests ran as expected and I logged in with an AD account).
I know the LDAP module for 8 is in development mode but it seems to imply it is working. Has anyone got this working though? Please can you let me know whether I could be overlooking something simple with the settings in 8 or if it is a bug. I really don't want to use Drupal 7, but we definitely need our users to be able to log in using their network details.
I been searching for an answer for this for a long time now. There are a zillion discussions but none seems to have helped me (I have tried everything I have read).
I have an ASP.net website that send apple push notifications. I created a Console app using push sharp - run it on my server, the push notifications get sent/received successfully. I run the console on my local dev system, it also works. I run my 'website' from IIS Express on my local system - the push notifications are also successful. But running in IIS on my server, I am getting the dreaded 'The credentials supplied to the package were not recognized' - any help at this point would be fantastic. Thanks
Previously, every time I have run into this issue, I have had to delete the cert out of my local machine cert store and re-import it. Then it all seems happy. I can't see how it could be a global permissions issue or invalid cert if simply re-importing it fixes the issue.
How I finally fixed it was using the winhttpcertcfg tool from the Windows Resource Kit to grant permission to the specific user that was using the cert.
The syntax would be:
"C:\Program Files (x86)\Windows Resource Kits\Tools\winhttpcertcfg" -i cert.p12 -c LOCAL_MACHINE\My -a UserWhoUsesTheCert -p passwordforp12
i'm trying to upload my app engine project for the very first time and i have no clue why it is not working. the error from my terminal is:
[me][~/Desktop]$ appcfg.py update ProjectDir/
Application: tacticalagentz; version: 1
Host: appengine.google.com
Starting update of app: tacticalagentz, version: 1
Scanning files on local disk.
Error 404: --- begin server output ---
This application does not exist (app_id=u'tacticalagentz').
--- end server output ---
i'm using python 2.6.5 and ubuntu 10.04.
not sure if this is relevant, but i just created a google app engine account today. and i also just created the application today (like a couple of hours ago). this is really frustrating because i just want to upload what i have so far (as a demo). in my app.yaml this is my first line:
application: tacticalagentz
Furthermore, i checked on my admin console, and i CLEARLY see the app id right there, and it matches letter for letter with the app id in my app.yaml
could someone please enlighten me and tell me what i am doing wrong? or is it something beyond my comprehension (like indexing issue with Google that they need time to index my app id) ?
thank you very much in advance
apparently adding the "--no_cookies" parameter will work
appcfg.py update --no_cookies ProjectDir/
the way i was able to find my answer was by uploading my app from my Mac OS X (thank god i have linux mac and windows). AppEngine on Mac OS X comes with a GUI interface, and it worked for uploading. so then i found the command they used in the console, which included "--no_cookies". perhaps if you run into similar issues in the future, this is one approach to getting the answer
App Engine for Java have the same problem. The problem is about account login.
If you are using Eclipse, use Sign In button.
If u are using command-line, use "-e" option, like this:
appcfg.sh -e your#email.com update yoursite/
I had the same problem. When I changed the name of the app I used in the launcher to match the one in the app engine, It worked without any problem. The way I figured out, it was the name mismatch which caused the problem. You can see the name of your registered app in the admin console of app engine.(https://appengine.google.com/)
Here's what fixed it for me:
i had an instance of dev_appserver.py myProjDirectory/ on a different terminal.
i guess the scripts are somehow linked and aren't thread safe
An alternate option that worked for me is to just "Clear Deployment Credential" from the Control option of the GUI. When the app was deployed after this, it opened a google page to allow GAE to access the user profile and then deployment was successful.
The key bit is
This application does not exist (app_id=u'tacticalagentz').
which is telling you that appspot.com doesn't know of an application by that name. The admin console (https://appengine.google.com/) shows your applications. Check there. You might have made an inadvertent typo when you registered the app.