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

ValueError when connecting via loopback #159

Closed
calebstewart opened this issue Jul 18, 2021 · 5 comments · Fixed by #160
Closed

ValueError when connecting via loopback #159

calebstewart opened this issue Jul 18, 2021 · 5 comments · Fixed by #160
Labels
bug Something isn't working

Comments

@calebstewart
Copy link
Owner

Bug Description

This is normally only a testing problem, as practically, you aren't often connecting to localhost. That being said, when connecting to a bind shell on the local machine, pwncat is unable to use localhost. Getting the peer name from the socket apparently results in a different return value for the loopback device vice a normal IP address.

image

You can use 127.0.0.1, and it works just fine. This should be relatively easy to test/fix. I just need to figure out what exactly the expected return value is for a loopback device.

pwncat version

Provide the output of pwncat --version or a commit hash if working from
a development branch.

$ pwncat --version
0.4.3

Target System (aka "victim")

My local machine, which is an Arch Linux host.

Steps to Reproduce

Steps to reproduce the behavior:

  1. Start a listener with ncat -e /bin/bash -klnvp 4444
  2. Attempt to connect to the listener with pwncat localhost 4444
  3. See error

Expected Behavior

A connection is established in the same way as using 127.0.0.1 in place of localhost.

@calebstewart calebstewart added the bug Something isn't working label Jul 18, 2021
@Mitul16
Copy link
Contributor

Mitul16 commented Jul 18, 2021

I have seen this before.
This happens when we create the bind shell using IPv6 protocol or AF_INET6 address family
And thus we do not get (host, port) pair tuple as the return value which is what pwncat expects.

@Mitul16
Copy link
Contributor

Mitul16 commented Jul 18, 2021

Using the port 1337, you may receive something similar to ('::1', 1337, 0, 0) instead of ('127.0.0.1', 1337)

@calebstewart
Copy link
Owner Author

Per the Python socket documentation

image

This should be relatively easy to fix. The flow info and scope ID aren't important in this context so I'm pretty sure we can safely ignore them.

@Mitul16
Copy link
Contributor

Mitul16 commented Jul 18, 2021

Is this any helpful?

Screenshot from 2021-07-18 22-59-55

@Mitul16
Copy link
Contributor

Mitul16 commented Jul 18, 2021

I did thought about fixing it 😁 , but I thought who is using IPv6 anyway.
And the current implementation for parsing the host and port using an IPv6 address will throw an error as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants