how to man-in-the-middle blocking/intercepting/editing all network traffic going to a single cabled device and a server

Question

I need to completely block and intercept and alter all packets going between two devices. possibly i need to isolate one device and block/intercept/edit ALL traffic going to and from it if i cannot find the cause in the packets between the devices. edit- could not remember the term. i need to be the man in the middle between the problem device and the server.

How do that? just a basic outline would be good. some pointers of where to start.

i need to be able to control exactly what one of the machines see to diagnose its exact connection issue. the two devices are a typical windows server running our PACS program and an ultrasound machine. the ultrasound machine keeps failing to connect to upload images to the server, because it keeps sending close connection requests to the server. i have another ultrasound machine of the same make but different model that connects without an issue, and no other radiology machine has this issue.

i have wireshark running on the server and can get admin access to it, that is how i have diagnosed that it is the ultrasound machine suddenly sending a close connection request. The ultrasound machine that i have almost no control over and is functionally a blackbox locked down by GE in a kind of Kiosk mode and we have no support contract with them. i can change where the Ultrasound machine sends the images, ip settings, and number of other fields but i am limited by to the Kiosked GUI.

From what i can tell the connection between works normally until the ultrasound machine suddenly sends a close DICOM connection request immediately after recieving a dicom ACK from the server. our PACS vendor suggested maybe it is something in their DICOM ack packet making the ultrasound machine error out so i would like to intercept and edit the messages.

if i can do all this through just wireshark that would be great. if this doesn't work i will just have to learn to packet sniff on the ultrasound machine and intercept all of its traffic somehow.

resources available

admin access to everything but the ultrasound machine
a network admin is available, though i would to not like to bother him.
spare cisco switches, laptops, etc basically our whole IT dept of spare parts
a very helpful PACs vendor

for further information for those of you without experience with "medical devices" Ultrasound machines are extremely locked down. i have admin rights inside of its Kiosked GUI, but no access at all to the OS.

edit, made a veeery basic network model

problemdevice<------>network wall jack<------->radiology subnet<--->wall jack<---->radiology server

radiology server is running wireshark

on a personal note this is the 4th metastack i have posted this question to. all the others having stated it lay outside scope, off topic, broke posting guidelines, or broke the stricture on software/hardware recommendations. the software recommendations stack then said the stack was "about recommending software, not assets or resources like howtos, manuals/tutorials, code fragments, etc. " i even posted it on network engineering after being referred there by stack overflow, thinking "yeah they would definitely know how to do this." nope, can't recommend things. if i need to alter this question i will just please tell me what i need to change to make it work

section i wish to alter are in the DICOM, A-ASSOCIATE accept VIVIDS70-200360 <-- DICOMSTORAGESCP element particularly the presentation context sections

    Frame 7: 372 bytes on wire (2976 bits), 372 bytes captured (2976 bits) on interface \Device\NPF_{95DCA5B3-EB26-4EA8-A80B-38B3AC886B9E}, id 0
    Interface id: 0 (\Device\NPF_{95DCA5B3-EB26-4EA8-A80B-38B3AC886B9E})
        Interface name: \Device\NPF_{95DCA5B3-EB26-4EA8-A80B-38B3AC886B9E}
    Encapsulation type: Ethernet (1)
    Arrival Time: Dec 16, 2019 12:42:47.470112000 Mountain Standard Time
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1576525367.470112000 seconds
    [Time delta from previous captured frame: 0.007570000 seconds]
    [Time delta from previous displayed frame: 0.007570000 seconds]
    [Time since reference or first frame: 0.309372000 seconds]
    Frame Number: 7
    Frame Length: 372 bytes (2976 bits)
    Capture Length: 372 bytes (2976 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ethertype:ip:tcp:dicom]
    [Coloring Rule Name: TCP]
    [Coloring Rule String: tcp]
Ethernet II, Src: Dell_dc:33:54 (b8:2a:72:dc:33:54), Dst: All-HSRP-routers_50 (00:00:0c:07:ac:50)
    Destination: All-HSRP-routers_50 (00:00:0c:07:ac:50)
        Address: All-HSRP-routers_50 (00:00:0c:07:ac:50)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Source: Dell_dc:33:54 (b8:2a:72:dc:33:54)
        Address: Dell_dc:33:54 (b8:2a:72:dc:33:54)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 10.101.50.7, Dst: 10.250.120.61
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
        0000 00.. = Differentiated Services Codepoint: Default (0)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    Total Length: 358
    Identification: 0x4a86 (19078)
    Flags: 0x4000, Don't fragment
        0... .... .... .... = Reserved bit: Not set
        .1.. .... .... .... = Don't fragment: Set
        ..0. .... .... .... = More fragments: Not set
    ...0 0000 0000 0000 = Fragment offset: 0
    Time to live: 128
    Protocol: TCP (6)
    Header checksum: 0x0000 [validation disabled]
    [Header checksum status: Unverified]
    Source: 10.101.50.7
    Destination: 10.250.120.61
Transmission Control Protocol, Src Port: 104, Dst Port: 49268, Seq: 1, Ack: 471, Len: 318
    Source Port: 104
    Destination Port: 49268
    [Stream index: 0]
    [TCP Segment Len: 318]
    Sequence number: 1    (relative sequence number)
    Sequence number (raw): 3548356980
    [Next sequence number: 319    (relative sequence number)]
    Acknowledgment number: 471    (relative ack number)
    Acknowledgment number (raw): 2364032816
    0101 .... = Header Length: 20 bytes (5)
    Flags: 0x018 (PSH, ACK)
        000. .... .... = Reserved: Not set
        ...0 .... .... = Nonce: Not set
        .... 0... .... = Congestion Window Reduced (CWR): Not set
        .... .0.. .... = ECN-Echo: Not set
        .... ..0. .... = Urgent: Not set
        .... ...1 .... = Acknowledgment: Set
        .... .... 1... = Push: Set
        .... .... .0.. = Reset: Not set
        .... .... ..0. = Syn: Not set
        .... .... ...0 = Fin: Not set
        [TCP Flags: ·······AP···]
    Window size value: 512
    [Calculated window size: 131072]
    [Window size scaling factor: 256]
    Checksum: 0xc0fb [unverified]
    [Checksum Status: Unverified]
    Urgent pointer: 0
    [SEQ/ACK analysis]
        [iRTT: 0.000194000 seconds]
        [Bytes in flight: 318]
        [Bytes sent since last PSH flag: 318]
    [Timestamps]
        [Time since first frame in this TCP stream: 0.309372000 seconds]
        [Time since previous frame in this TCP stream: 0.007570000 seconds]
    TCP payload (318 bytes)
DICOM, A-ASSOCIATE accept  VIVIDS70-200360 <-- DICOMSTORAGESCP
    PDU Type: ASSOC Accept (0x02)
    PDU Length: 312
    A-ASSOCIATE accept  VIVIDS70-200360 <-- DICOMSTORAGESCP
        Protocol Version: 1
        Called  AE Title: DICOMSTORAGESCP 
        Calling AE Title: VIVIDS70-200360 
        Application Context: DICOM Application Context Name (1.2.840.10008.3.1.1.1)
            Item Type: Application Context (0x10)
            Item Length: 21
            Application Context: DICOM Application Context Name (1.2.840.10008.3.1.1.1)
        Presentation Context: ID 0x01, Accept, JPEG Baseline (Process 1): Default Transfer Syntax for Lossy JPEG 8 Bit Image Compression, Secondary Capture Image Storage
            Item Type: Presentation Context Reply (0x21)
            Item Length: 30
            Context ID: 0x01
            Result: Accept (0x0)
            Transfer Syntax: JPEG Baseline (Process 1): Default Transfer Syntax for Lossy JPEG 8 Bit Image Compression (1.2.840.10008.1.2.4.50)
                Item Type: Transfer Syntax (0x40)
                Item Length: 22
                Transfer Syntax: JPEG Baseline (Process 1): Default Transfer Syntax for Lossy JPEG 8 Bit Image Compression (1.2.840.10008.1.2.4.50)
        Presentation Context: ID 0x03, Accept, JPEG Baseline (Process 1): Default Transfer Syntax for Lossy JPEG 8 Bit Image Compression, Ultrasound Image Storage
            Item Type: Presentation Context Reply (0x21)
            Item Length: 30
            Context ID: 0x03
            Result: Accept (0x0)
            Transfer Syntax: JPEG Baseline (Process 1): Default Transfer Syntax for Lossy JPEG 8 Bit Image Compression (1.2.840.10008.1.2.4.50)
                Item Type: Transfer Syntax (0x40)
                Item Length: 22
                Transfer Syntax: JPEG Baseline (Process 1): Default Transfer Syntax for Lossy JPEG 8 Bit Image Compression (1.2.840.10008.1.2.4.50)
        Presentation Context: ID 0x05, Accept, JPEG Baseline (Process 1): Default Transfer Syntax for Lossy JPEG 8 Bit Image Compression, Ultrasound Multi-frame Image Storage
            Item Type: Presentation Context Reply (0x21)
            Item Length: 30
            Context ID: 0x05
            Result: Accept (0x0)
            Transfer Syntax: JPEG Baseline (Process 1): Default Transfer Syntax for Lossy JPEG 8 Bit Image Compression (1.2.840.10008.1.2.4.50)
                Item Type: Transfer Syntax (0x40)
                Item Length: 22
                Transfer Syntax: JPEG Baseline (Process 1): Default Transfer Syntax for Lossy JPEG 8 Bit Image Compression (1.2.840.10008.1.2.4.50)
        Presentation Context: ID 0x07, Accept, JPEG Baseline (Process 1): Default Transfer Syntax for Lossy JPEG 8 Bit Image Compression, Ultrasound Image Storage (Retired)
            Item Type: Presentation Context Reply (0x21)
            Item Length: 30
            Context ID: 0x07
            Result: Accept (0x0)
            Transfer Syntax: JPEG Baseline (Process 1): Default Transfer Syntax for Lossy JPEG 8 Bit Image Compression (1.2.840.10008.1.2.4.50)
                Item Type: Transfer Syntax (0x40)
                Item Length: 22
                Transfer Syntax: JPEG Baseline (Process 1): Default Transfer Syntax for Lossy JPEG 8 Bit Image Compression (1.2.840.10008.1.2.4.50)
        Presentation Context: ID 0x09, Accept, JPEG Baseline (Process 1): Default Transfer Syntax for Lossy JPEG 8 Bit Image Compression, Ultrasound Multi-frame Image Storage (Retired)
            Item Type: Presentation Context Reply (0x21)
            Item Length: 30
            Context ID: 0x09
            Result: Accept (0x0)
            Transfer Syntax: JPEG Baseline (Process 1): Default Transfer Syntax for Lossy JPEG 8 Bit Image Compression (1.2.840.10008.1.2.4.50)
                Item Type: Transfer Syntax (0x40)
                Item Length: 22
                Transfer Syntax: JPEG Baseline (Process 1): Default Transfer Syntax for Lossy JPEG 8 Bit Image Compression (1.2.840.10008.1.2.4.50)
        User Info: Max PDU Length 131072, Implementation UID 1.2.840.114051.6.0, Version NovaRad 6.0
            Item Type: User Info (0x50)
            Item Length: 45
            Max PDU Length: 131072
                Item Type: Max Length (0x51)
                Item Length: 4
                Max PDU Length: 131072
            Implementation UID: 1.2.840.114051.6.0
                Item Type: Implementation Class UID (0x52)
                Item Length: 18
                Implementation Class UID: 1.2.840.114051.6.0
            Implementation Version: NovaRad 6.0
                Item Type: Implementation Version (0x55)
                Item Length: 11
                Implementation Version: NovaRad 6.0

Most decent switches have a port mirroring functionality. Configure the port the problematic system is connected to to mirror the traffic to the port of the system where WireShark is running. This would require performing the capture in promiscuous mode. — Greg Askew, Jan 03 '20 at 15:52
i get what you are saying, we are an all cisco shop so it should be doable. would this block the flow of packets that i don't approve to the problem device? — Jason Dossett, Jan 03 '20 at 16:18

Yevhen Stasiv · Answer 1 · 2020-01-03T17:22:51.983

0

You can spoof arp and have the machine send the data to your device instead of it's intended destination, and capture all the data into a pcap.

You could then rewrite the pcap to be how you want, and re-transmit it using tcpreplay.

I am not sure how ultrasound machines work or why they are even networked, but you should be able to omit the bad packet this way.

For a more 'on the fly' solution consider looking into 'proxyshark' or 'netsed'. Hard to say without seeing a pcap, to know what exactly needs being modified.

edited Jan 03 '20 at 17:22

answered Jan 03 '20 at 17:13

Yevhen Stasiv

263
2
5

I am reticent to use arp spoofing on the radiology dept switch, maybe if i put another switch in between the US machine and the radiology dept switch and use that instead. the ultrasound machine "under the hood" is just a windows xp or vista PC that has been HEAVILY locked down and has a bunch of specialized input devices attached. My access is through a specialized GUI. it needs to be networked to send large image files, usually a gig, to a radiology information system for review by radiologists, who are several hundred miles away. i will post pcaps in a moment thanks – Jason Dossett Jan 03 '20 at 18:02
If you do not want to use arp spoofing you will need to configure a monitor session (SPAN) on the interface.. Is the frame provided from the rad machine to the server or from the server to rad machine? Its possible altering the stream may not resolve this issue (does the machine continue trying to send images to the server even after it requests a connection close? if so, it might work) Are the images sent through a plain channel? It may be possible to 'Export Objects' right from the capture using Wireshark (File -> Export Objects). – Yevhen Stasiv Jan 04 '20 at 00:51
Are you aiming to make some sort of 'production environment' solution through modifying the stream on the fly? (This is wonky for medical equipment) – Yevhen Stasiv Jan 04 '20 at 00:51
The frame that might be the culprit comes from the server to the device. The dicom channel is never open long enough for any other packets to go through. US sends dicom request, server accepts it and sends the back the the US sends a close request. With no traffic in between the accepting and close and the server never sees any further traffic other than some tyoical tcp/ip closing packets. However from the US side, on the GUI screen whatever error happens doesn't catch up to the xfer process and the system thinks it's trying to send. – Jason Dossett Jan 04 '20 at 03:42
1

I might setup a port span just to see what traffic it might be spewing out to nowhere After the close request. All of this purely for diagnostic purposes, not a production solution. If I cant come up with anything by monday afternoon we are probably just going to crack it open, pull out the C drive and look for the error logs of the US machine. – Jason Dossett Jan 04 '20 at 03:43
Basically I need to prove the issue is beyond the reach of our access and that we need to contact the Vendor, GE, and get a quote for support. Last time something like this happened I set upper managements expectations really high as i able to rig a solution involving a the server, a powershell script, a couple going into windows services and turning off everything that might interfere with file xfer across a network and turning on every service related to file xfer. But that was the old system and not dicom like the new system, but a regular old SMB and windows network file xfer. – Jason Dossett Jan 04 '20 at 03:52
It's making the connection through a regular ethernet channel – Jason Dossett Jan 04 '20 at 03:53

how to man-in-the-middle blocking/intercepting/editing all network traffic going to a single cabled device and a server

1 Answers1