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

RCE Through JDWP Debug Port #6

Closed
DefCon42 opened this Issue Mar 6, 2019 · 29 comments

Comments

Projects
None yet
@DefCon42
Copy link

DefCon42 commented Mar 6, 2019

Describe the bug
Remote code execution is achievable through the JDWP debug port 18001 which is opened to all interfaces when launching in debug mode.

To Reproduce
Steps to reproduce the behavior:

  1. Open the program with the debug launcher dependent on your OS.

Expected behavior
No remote code execution

Environment (please complete the following information):

  • Any Windows/Linux build running with debug mode.

Additional context
Credits: https://twitter.com/hackerfantastic/status/1103087869063704576

@DefCon42 DefCon42 added the bug label Mar 6, 2019

@DefCon42

This comment has been minimized.

Copy link
Author

DefCon42 commented Mar 6, 2019

Updated to reflect new information.

@RobRoseKnows

This comment has been minimized.

Copy link

RobRoseKnows commented Mar 6, 2019

I commented on the Tweet with this too: but I don't really think this classifies as a bug. Debug mode isn't the default and it's expected behavior that debug mode would, you know, open debug ports.

@DefCon42

This comment has been minimized.

Copy link
Author

DefCon42 commented Mar 6, 2019

The issue isn't that it's opening the port, it's that it opens the port on all interfaces, not just locally.

@ctubbsii

This comment has been minimized.

Copy link
Contributor

ctubbsii commented Mar 6, 2019

I wonder if it would be useful to make the debug listening interface/port configurable (if not already) and to default to localhost.

@silascutler

This comment has been minimized.

Copy link

silascutler commented Mar 6, 2019

It may be possible to set to a specific interface, by changing:

VMARG_LIST+=" -Xrunjdwp:transport=dt_socket,server=y,suspend=${SUSPEND},address=*:${DEBUG_PORT}"

to

DEBUG_INTERFACE=<SOMETHING>
...

VMARG_LIST+=" -Xrunjdwp:transport=dt_socket,server=y,suspend=${SUSPEND},address=${DEBUG_INTERFACE}:${DEBUG_PORT}"
@nneonneo

This comment has been minimized.

Copy link
Contributor

nneonneo commented Mar 6, 2019

It is often useful to debug a misbehaving program from a different computer, or (for example) debug a misbehaving program inside a VM from outside. So, I'm not sure this really qualifies as a bug.

@DefCon42

This comment has been minimized.

Copy link
Author

DefCon42 commented Mar 6, 2019

Kernel debugging isn't really the same thing, mainly because if you mess up while doing so the VM bluescreens, which is why debugging remotely is helpful. Here it doesn't seem to have nearly as much usefulness. The fact that this is the default behavior is what's concerning.

@qwerty01

This comment has been minimized.

Copy link

qwerty01 commented Mar 6, 2019

How is this an issue? Every debug server I've used listens on 0.0.0.0 by default...and RCE is a really heavy term to use even if it wasn't normal behavior

@bartekus

This comment has been minimized.

Copy link

bartekus commented Mar 6, 2019

As @DefCon42 mention already

The fact that this is the default behavior is what's concerning.

Indeed, as I'm sure NSA is already well aware, hacker-folk are highly distrustful and trust is a fragile thing. Perhaps outlining all the basic specifics regarding the software architecture and its intended purpose could help calming them... Just saying.

@nneonneo

This comment has been minimized.

Copy link
Contributor

nneonneo commented Mar 6, 2019

I wasn’t referring to kernel debugging - debugging an app running in a foreign OS counts too (think debugging the app running in a Linux VM using Windows tools).

I can understand the concern - maybe it needs improved documentation?

@WriteCodeEveryday

This comment has been minimized.

Copy link

WriteCodeEveryday commented Mar 6, 2019

As @DefCon42 mention already

The fact that this is the default behavior is what's concerning.

Indeed, as I'm sure NSA is already well aware, hacker-folk are highly distrustful and trust is a fragile thing. Perhaps outlining all the basic specifics regarding the software architecture and its intended purpose could help calming them... Just saying.

There's probably a command and control component that uses this inside of a VM for analysis.

@quosego

This comment has been minimized.

Copy link

quosego commented Mar 6, 2019

Remove set if needed in ghidraDebug.bat/sh if non-remote.

:: set debug port
set DEBUG_PORT=18001

Checkout GhidraServer regarding network I/O.

main(String[] args)
@DefCon42

This comment has been minimized.

Copy link
Author

DefCon42 commented Mar 6, 2019

I wasn’t referring to kernel debugging - debugging an app running in a foreign OS counts too (think debugging the app running in a Linux VM using Windows tools).

I can understand the concern - maybe it needs improved documentation?

Improved documentation is definitely a must -- I wouldn't put something that allows this type of execution under the name "debug."

How is this an issue? Every debug server I've used listens on 0.0.0.0 by default...and RCE is a really heavy term to use even if it wasn't normal behavior

Issue A is that this isn't explicitly labeled as a debug server -- just under the obscure name "debug mode."
Issue B is that not every debug server you've used allows arbitrary code execution on the target.

https://twitter.com/hackerfantastic/status/1103109539589632000

@philippTheCat

This comment has been minimized.

Copy link

philippTheCat commented Mar 6, 2019

It is JDWP, it is the protocol that IDE's use to connect to the program. This needs to include arbitrary code execution if you want to do any substantial work with it.

@Amphyby

This comment has been minimized.

Copy link

Amphyby commented Mar 6, 2019

ROFL it's just a trojan from NSA team. what did you expect? :D
funny 'hackers' all around

@joepie91

This comment has been minimized.

Copy link

joepie91 commented Mar 6, 2019

How is this an issue? Every debug server I've used listens on 0.0.0.0 by default...and RCE is a really heavy term to use even if it wasn't normal behavior

Mind sharing your IP, in that case?

Reasonably-designed tools - debug servers or otherwise - never listen on 0.0.0.0 unless explicitly told to do so.

@cym13

This comment has been minimized.

Copy link

cym13 commented Mar 6, 2019

Binding on 127.0.0.1 would help but it would still be vulnerable to DNS rebinding attacks IIUC. Can this be turned off by default or use authentication?

EDIT: just noticed it's off unless launched in debug mode, seems fair to me.

@ryanmkurtz ryanmkurtz self-assigned this Mar 6, 2019

@paragonie-scott

This comment has been minimized.

Copy link

paragonie-scott commented Mar 6, 2019

My thoughts: Listening on 0.0.0.0 should still be permitted, but should not be the default value.

Secure-by-default is the only meaningful security configuration in the real world, after all. NSA might have the discipline to not do something boneheaded with an insecure default, but not everyone is NSA.

@briangordon

This comment has been minimized.

Copy link

briangordon commented Mar 6, 2019

Give me a break. This is a legitimate issue that should be fixed, but it's ridiculous to call this a deliberate backdoor. The whole point of releasing a massive project like this as open source is to win brownie points with the community, and that's rather undermined if there's a dead obvious backdoor staring everyone in the face. Who runs desktop applications on machines with network interfaces completely open to the public internet anyway? You almost always have a NAT in front of desktop machines, and firewall rules on servers.

@Banginpadr

This comment has been minimized.

Copy link

Banginpadr commented Mar 6, 2019

@qwerty01 °NSA° those words dont tell you anything? thats the issue every one have

@bcosinc

This comment has been minimized.

Copy link

bcosinc commented Mar 6, 2019

Wow! I'm glad you found this in under a day. You're quite the l33t master hacker @DefCon42. To think, the NSA spent however long to develop this and YOU exposed their super secret non-default debug mode RCE "hack". To think, all of us loser n00bs out here ALWAYS run our RE activities on live boxes attached directly to the Internet with no firewalls anywhere in sight. YOU saved us all. I can wait to see what else you contribute. Can you find the other 900000 "RCE backdoors" in this project?

Give me a break.

@ctubbsii

This comment has been minimized.

Copy link
Contributor

ctubbsii commented Mar 6, 2019

Okay folks, let's please keep the conversation civil. The issue that was reported is essentially that the default bind address for when debugging is turned on could be improved by binding by default to 127.0.0.1 instead of 0.0.0.0.

It's a reasonable suggestion for improvement, and the suggestion is appreciated. Now, let's give the developers a chance to address it. If they determine that there's a reasonable use case to leave the default at 0.0.0.0 (for convenience debugging or whatever), then perhaps they can still address it by improving the documentation to better warn users of the implication of enabling debugging.

There is a reasonable path forward here. There's no need to be uncivil to each other.

@DefCon42

This comment has been minimized.

Copy link
Author

DefCon42 commented Mar 6, 2019

Wow! I'm glad you found this in under a day. You're quite the l33t master hacker @DefCon42. To think, the NSA spent however long to develop this and YOU exposed their super secret non-default debug mode RCE "hack". To think, all of us loser n00bs out here ALWAYS run our RE activities on live boxes attached directly to the Internet with no firewalls anywhere in sight. YOU saved us all. I can wait to see what else you contribute. Can you find the other 900000 "RCE backdoors" in this project?

Give me a break.

  1. I didn't find it, as clearly stated in the issue.
  2. This is a (soon to be) open source project which anyone can run. The problem isn't the experienced reverse engineers who run this under however many layers of security, it's the guys who download this on, say, a campus-wide school network. If it's going to expose a port on every interface then it should be well-documented that it does so.
  3. Expanding on 2, I never called this a backdoor. It's simply an overlooked consequence of having undocumented default behavior.

If they determine that there's a reasonable use case to leave the default at 0.0.0.0 (for convenience debugging or whatever), then perhaps they can still address it by improving the documentation to better warn users of the implication of enabling debugging.

There is a reasonable path forward here. There's no need to be uncivil to each other.

Even if the default is to have it open (a.la ADB), there are many ways to improve it. Some sort of public/private key authentication or otherwise would be plenty.

@qwerty01

This comment has been minimized.

Copy link

qwerty01 commented Mar 6, 2019

Issue A is that this isn't explicitly labeled as a debug server -- just under the obscure name "debug mode."
Issue B is that not every debug server you've used allows arbitrary code execution on the target.

A - It's not default behavior, so I don't see how it would be mistaken for something other than that, but adding better documentation for that would probably be a good idea.
B - What? That's literally the definition of a debug server--executing arbitrary code on the target.

@Albocoder

This comment has been minimized.

Copy link

Albocoder commented Mar 6, 2019

B - What? That's literally the definition of a debug server--executing arbitrary code on the target.

That's true but how many debuggers do you know that listen to the ENTIRE WORLD instead of the localhost? I could think of ADB on top of my head that has the remote functionality but it uses PKI based solution to authenticate the user first. This however allows the whole world to connect with no authentication.

@WriteCodeEveryday

This comment has been minimized.

Copy link

WriteCodeEveryday commented Mar 6, 2019

For everyone who is complaining, the PDF https://www.rsaconference.com/writable/presentations/file_upload/png-t09-come-get-your-free-nsa-reverse-engineering-tool_.pdf, slide 23 speaks about running analysis without a GUI.

@qwerty01

This comment has been minimized.

Copy link

qwerty01 commented Mar 6, 2019

That's true but how many debuggers do you know that listen to the ENTIRE WORLD instead of the localhost? I could think of ADB on top of my head that has the remote functionality but it uses PKI based solution to authenticate the user first. This however allows the whole world to connect with no authentication.

So does gdbserver and all the ida servers, it's industry standard to have a debug server listen on * since it's meant for remote debugging, not local debugging.

However, it seems I misunderstood the context--apparently debug mode is for debugging Ghidra, not an arbitrary binary. This definitely needs to be fixed.

@ryanmkurtz ryanmkurtz added this to the 9.0.1 milestone Mar 7, 2019

@ryanmkurtz

This comment has been minimized.

Copy link
Collaborator

ryanmkurtz commented Mar 7, 2019

Thanks for all of the feedback on this issue! 127.0.0.1 will be used by default in our next release. It will also be a little easier to set the debug script variable to a different ip:port combo in the launcher scripts in the case where remote debugging is required.

@ryanmkurtz ryanmkurtz closed this Mar 7, 2019

@ctubbsii

This comment has been minimized.

Copy link
Contributor

ctubbsii commented Mar 7, 2019

@ryanmkurtz Nice use of the milestone feature in GitHub! 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.