search

GoSecure / pyrdp

RDP monster-in-the-middle (mitm) and library for Python with the ability to watch connections live or after the fact
https://www.gosecure.net/blog/2020/10/20/announcing-pyrdp-1/
GNU General Public License v3.0
1.52k stars 246 forks source link

Smart Cards not working with the MITM component #382

Open keremenci opened 2 years ago

keremenci commented 2 years ago

When connecting to a server via pyrdp MITM, smart cards are not working properly. The device appears on the remote host but the certificates in the smart card are unaccessible.

obilodeau commented 2 years ago

Supporting SmartCard is not something we are interested in at this point. I don't even know how to test it.

That said, if you are willing to do the exploration and the code changes required, we can guide you.

keremenci commented 2 years ago

I used EIDVirtual to create a smart card out of an usb stick. By installing EIDVirtual on the server, one can use the smart card manager to view the certificates on the smart card in the remote server. It appears that the device is recognized but the certificates cannot be read from the card. I dumped the incoming and outgoing network packets but couldn't figure out the decryption in wireshark. Would love some help with that

obilodeau commented 2 years ago

Information about how to decrypt TLS traffic with Wireshark can be found in Wireshark's wiki. An easier-to-follow tutorial with screenshots is also available here: https://unit42.paloaltonetworks.com/wireshark-tutorial-decrypting-https-traffic/.

Record the whole conversation then open the pcap following the TLS decryption instructions. The TLS master-secrets will be in pyrdp_output/logs/ssl.log.

Good luck and keep us posted on your progress!

keremenci commented 2 years ago

After dumping the incoming and outgoing packets via tcpdump using the following filters:

I don't seem to be able to filter the traffic by rdp in wireshark, and all I see is a bit of TLS1.2 traffic followed by a large amount of TCP packets. I did configure wireshark to use the log field and also supplied the private key in the preferences > protocols > TLS

This is what i did in order:

Any ideas what I may be missing? My networking knowledge is a bit limited so any help would be appreciated.

keremenci commented 2 years ago

Also, it seems that all the IO requests and responses pass through except the 0x000900a4 | FSCTL_SET_REPARSE_POINT call, which has something to do with SCardGetStatusChangeW (Couldn't really figure out this part).

obilodeau commented 2 years ago

I did configure wireshark to use the log field and also supplied the private key in the preferences > protocols > TLS

Don't supply the private key. Supply the TLS master secrets. Load the ssl.log in the red square here: Wireshark screenshot for TLS config

keremenci commented 2 years ago

I tried various combinations of supplying the pk and the log and was not successful

keremenci commented 2 years ago

These two IO requests (as defined in the docs) from the server never receive a response. Any ideas on what the cause may be? image

obilodeau commented 2 years ago

I think it might be because we implemented MITM for Device IO since it is how we collect files but we haven't done anything regarding smart cards. One approach would be to use a debugger at the right spots and see if you could pass through the exchange back and forth instead of intercepting them.

For example:

install ipdb

add a statement to trigger the debugger at the right spot. In pyrdp/parser/rdp/virtual_channel/device_redirection.py, under:

    def parseDeviceIORequest(self, stream: BytesIO) -> DeviceIORequestPDU:

Add:

import ipdb; ipdb.set_trace()

Restart pyrdp-mitm and see what is mishandled (it might not be the first time the debugger trips)

Good luck!

keremenci commented 2 years ago

It appears that the major function field is set to 0x0000000C and the minor function is 0 even though it is explicitly stated that this is not a valid state of the pdu in the docs. image

obilodeau commented 2 years ago

You are not providing enough details. Without them, I can't help you.

keremenci commented 2 years ago

Yes, my bad. Had to tend to some other stuff and could not exactly pay attention. Sorry for any inconvenience this may have caused.

Now that i'm back, I realized that what I said here was incorrect. There is nothing wrong with the pdu.

Upon further investigation, and some parsing by hand, I managed to extract the ioctl codes for the smart card DeviceIOControl calls. I couldn't find anything about the codes that I parsed, but then stumbled across the definitions in the smart card extension page

There really should be no issue for smart cards, as all the pdu's that pass through are just forwarded with no modifications, and I couldn't find anything that was mishandled.

Do we need to do some additional work to support the protocol extensions?

It appears that the major function field is set to 0x0000000C and the minor function is 0 even though it is explicitly stated that this is not a valid state of the pdu in the docs. image

obilodeau commented 2 years ago

Does that feature use DynamicChannels or VirtualChannels? We don't support DynamicChannels just yet. See #232 for the beginning of that work.

Res260 commented 2 years ago

@olivier i checked, it's the rdpdr channel (device redirection)

On Fri., Jan. 28, 2022, 10:25 Olivier Bilodeau, @.***> wrote:

Does that feature use DynamicChannels or VirtualChannels? We don't support DynamicChannels just yet. See #232 https://github.com/GoSecure/pyrdp/pull/232 for the beginning of that work.

— Reply to this email directly, view it on GitHub https://github.com/GoSecure/pyrdp/issues/382#issuecomment-1024326083, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADPMNLY5BF5HA7672EQ63STUYKYP3ANCNFSM5LONWC3Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you are subscribed to this thread.Message ID: @.***>

keremenci commented 2 years ago

It seems that the server can access the reader while the issues manifest themselves when we try to access the contents of the card.

Certutil hangs here image EIDVirtual smart card manager sometimes hangs and sometimes does not start at all. Starting the program via a regular rdp and switching over to the mitm also causes it to hang.

SCM Microsystems PC/SC diagnostic tool identifies the device as working but trying to access it causes the process to hang image

The behaviour is really chaotic, debugging drops the connection. Dumping the PDU information either causes the smart card resource manager of windows to not start at all, or drops the connection after the following exchange:

900e0 -> SCARD_IOCTL_ACCESSSTARTEDEVENT
90014 -> SCARD_IOCTL_ESTABLISHCONTEXT
9002c -> SCARD_IOCTL_LISTREADERSW
90108 -> SCARD_IOCTL_GETDEVICETYPEID
90014 -> SCARD_IOCTL_ESTABLISHCONTEXT
90108 -> SCARD_IOCTL_GETDEVICETYPEID
90018 -> SCARD_IOCTL_RELEASECONTEXT
900a4 -> SCARD_IOCTL_GETSTATUSCHANGEW
900a4 -> SCARD_IOCTL_GETSTATUSCHANGEW
90014 -> SCARD_IOCTL_ESTABLISHCONTEXT
9002c -> SCARD_IOCTL_LISTREADERSW
900a4 -> SCARD_IOCTL_GETSTATUSCHANGEW
90014 -> SCARD_IOCTL_ESTABLISHCONTEXT
90014 -> SCARD_IOCTL_ESTABLISHCONTEXT
900b0 -> SCARD_IOCTL_CONNECTW
900a4 -> SCARD_IOCTL_GETSTATUSCHANGEW
900bc -> SCARD_IOCTL_BEGINTRANSACTION
900a8 -> SCARD_IOCTL_CANCEL
900a8 -> SCARD_IOCTL_CANCEL

I should also point out that this exchange occurs before the credentials are entered in the login screen

I am kind of lost at this moment. Any ideas?