8000 panic: runtime error: index out of range, when using AD Explorer · Issue #1 · Macmod/ldapx · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

panic: runtime error: index out of range, when using AD Explorer #1

8000
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
slemire opened this issue Dec 13, 2024 · 4 comments
Open

panic: runtime error: index out of range, when using AD Explorer #1

slemire opened this issue Dec 13, 2024 · 4 comments
Assignees
@Macmod
Labels
bug Something isn't working help wanted Extra attention is needed

Comments

@slemire
Copy link
slemire commented Dec 13, 2024

ldapx runs fine with bloodhound-py and ldapsearch but crashes when I connect using AD Explorer

goroutine 19 [running]:
main.handleLDAPConnection.func3()
        C:/source/ldapx/proxy.go:139 +0x7aa
created by main.handleLDAPConnection in goroutine 18
        C:/source/ldapx/proxy.go:115 +0x7b6

To reproduce:

  • Start ldapx without any middleware: ldapx -t x.x.x.x:389
  • Connect to 127.0.0.1 with AD Explorer
@slemire
Copy link
Author
slemire commented Dec 13, 2024

Could be because ADExplorer uses GSS-API, based on some pcaps I took

@Macmod Macmod self-assigned this Dec 13, 2024
@Macmod
Copy link
Owner
Macmod commented Dec 14, 2024

I'll look into this. Thanks for pointing it out!

@Macmod Macmod added the bug Something isn't working label Dec 14, 2024
@Macmod
Copy link
Owner
Macmod commented Dec 14, 2024 •
edited
Loading

Apparently some messages sent by AD Explorer during SASL / GSSAPI establishment don't fit the "standard" expected format for LDAP messages. I'll try to check in the following days if we can just detect this condition somehow and get it working by just sending these "extra" packets back and forth between client and server.

@Macmod
Copy link
Owner
Macmod commented Dec 14, 2024 •
edited
Loading

Seems liks this is a bigger issue than I first thought - even if we could make it not panic and forward the messages back and forth, SASL/GSS-API encrypts the messages, so ldapx would not actually do anything but sit in the middle of the connection. So we can either:
(1) Explicitly state that ldapx doesn't support SASL / GSSAPI (not ideal)
(2) Add a flag to try to "downgrade" the auth somehow by intercepting and changing the first BindResponse (theoretically possible?)
(3) Implement active decryption of SASL / GSSAPI in ldapx (impossible?)

I'll have to study which of (2) and (3) is the way out, but more testing is definitely needed to solve this one.

[16/12/2024] Update. I tried to intercept the BindResponse and reply an authMethodNotSupported (resultCode 7) to ADExplorer - it seems that it first tries to use SASL / GSSAPI (type 3), and if it gets an authMethodNotSupported back it tries again with NTLMSSP Negotiate (type 10). But then, if we reply code 7 again, it just sends an UnbindRequest and throws an alert saying that the server does not support the requested authentication method.

I also tried to remove the supportedSASLMechanisms attribute from the response of the initial search that ADExplorer does in the RootDSE (or change it to PLAIN only), but then ADExplorer tries with NTLMSSP Negotiate only. I'm not sure if there's any case in which ADExplorer is forced to do a simple bind / use an unencrypted channel.

If anyone has any ideas about this I'd appreciate it. It's possible that we can do (3) but then we would need to implement active decryption of SASL / GSSAPI and NTLMSSP Negotiate by explicitly requiring the user to specify the credentials via command-line arguments. For now I'll add a disclaimer mentioning this issue in the README to let users know about the issue.

@Macmod Macmod added the help wanted Extra attention is needed label Dec 16, 2024
Macmod added a commit that referenced this issue Dec 16, 2024
@Macmod
Adding disclaimer regarding issue #1.
f10d3ba
@Macmod Macmod mentioned this issue Jan 21, 2025
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@Macmod Macmod

Labels
bug Something isn't working help wanted Extra attention is needed
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@slemire @Macmod
0