Skip to content
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.

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

Security Issue on dokodemo inbounds #1213

Closed
XRaySup opened this issue Apr 29, 2024 · 9 comments
Closed

Security Issue on dokodemo inbounds #1213

XRaySup opened this issue Apr 29, 2024 · 9 comments
Labels
enhancement New feature or request to deploy To be deployed during the time

Comments

@XRaySup
Copy link

XRaySup commented Apr 29, 2024

Describe the bug
Dokodemo Inbound works as a proxy server. it seems that if we provide a sni to the inbound port then the server forwards the connection to the provided sni without any restriction. it looks like a security issue

To Reproduce
Steps to reproduce the behavior:

  1. First server: Create a dokodemo inbound on port i.e. 443 with whatever target IP you want.(should not be the second server IP)
  2. Use an existing Vless was tls config. it can be any other protocol with tls security. make sure the config is working fine.
  3. Change the address in the config to the first server IP address
  4. make sure the config has a valid sni and host parameter similar to certificates for tls.
  5. in this case the first server IP address works as clean IP and passes all traffic.

Expected behavior
I expect that Dekodomo only forwards the traffic to the target IP.
it looks like some users scan all Iran VPS providers' IPs, and then use these local IPs as clean IP.
so they can use these IPs and overload the VPS.

we have seen this issue on the latest version of Sanaei but did not check on the Alireza Panel,
the source issue might be from the Xray core.

@XRaySup XRaySup added the bug Something isn't working label Apr 29, 2024
@pulsarice
Copy link

followRedirect should be off.
I think sniffing should be off too.
These two options can cause the destination IP address to be overridden.
Can you create the Dokodemo-Door inbound manually in xray advanced settings without adding it via UI form fields?

@pulsarice
Copy link

pulsarice commented May 2, 2024

I tested it and can confirm that sniffing is the problem.

There's a website my.ip.fi with ip address of 91.198.120.42 that returns your IP address when you visit it.
I set up a Dokodemo-Door with source port of 1234 and destination ip of 91.198.120.42 and destination port 443.
my server's IP address is A.A.A.A

First with sniffing ON:
from my home computer I ran these commands

C:\>curl https://my.ip.fi:1234 --resolve my.ip.fi:1234:A.A.A.A
A.A.A.A

C:\>curl https://google.com:1234 --resolve google.com:1234:A.A.A.A
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="https://www.google.com/">here</A>.
</BODY></HTML>

The first command's output is as expected.
But the second command shows that my server forwarded the traffic to google.com. It actually sniffed domain name from TLS header.

Then I disabled sniffing on Dokodemo-Door:

C:\>curl https://my.ip.fi:1234 --resolve my.ip.fi:1234:A.A.A.A
A.A.A.A

C:\>curl https://google.com:1234 --resolve google.com:1234:A.A.A.A
curl: (60) schannel: SNI or certificate check failed: SEC_E_WRONG_PRINCIPAL (0x80090322) - The target principal name is incorrect.
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

C:\>curl https://google.com:1234 --resolve google.com:1234:A.A.A.A -k
A.A.A.A

The first command's output is as expected.
The second command throws an SSL error (because server didn't forward traffic to google.com, But to 91.198.120.42)
In the 3rd command to make sure that it actually forwarded the packet to my specified 91.198.120.42 destination, I ran curl with -k switch to skip SSL checks and as you can see the connection is made to my.ip.fi, not google.com

@pulsarice
Copy link

@alireza0 It might be a good idea to turn off sniffing by default on Dokodemo-Door inbounds when first created by user.

@alireza0 alireza0 added enhancement New feature or request to deploy To be deployed during the time and removed bug Something isn't working labels May 2, 2024
@alireza0
Copy link
Owner

alireza0 commented May 3, 2024

Thank you for your analyse. I will consider it in next version.

@alireza0
Copy link
Owner

alireza0 commented May 3, 2024

It is now sniffing will be disabled by default!
Available in next release soon

@alireza0 alireza0 closed this as completed May 3, 2024
@pulsarice
Copy link

It is now sniffing will be disabled by default! Available in next release soon

Thanks. Just a question: Disabled on all protocols or only Dokodemo-Door?

@alireza0
Copy link
Owner

alireza0 commented May 3, 2024

All protocols by default (for new inbounds).
Lots of admins don't know about the usage and they will be confused.
Only one who knows how to use the benefits, could enable and configure it by their desired configuration.
Also some extra feautres of sniffing are added

@alipour66m
Copy link

All protocols by default (for new inbounds). Lots of admins don't know about the usage and they will be confused. Only one who knows how to use the benefits, could enable and configure it by their desired configuration. Also some extra feautres of sniffing are added

این مشکل فقط برای پروتکلDokodemo-Door وجود داره یا برای vless و بقیه هم هست؟

@pulsarice
Copy link

مشکل از اونجاست که این پروتکل Dokodemo-Door احراز هویت نداره. بقیه پروتکل‌هایی که احراز هویت دارن، قاعدتا نباید همچین مشکلی داشته باشن.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request to deploy To be deployed during the time
Projects
None yet
Development

No branches or pull requests

4 participants