Bidirectional escape testing
Bidirectional or two-way escape testing verifies that escape from an isolated network can communicate both ways: from isolated environment out and then back in. Bidirectional leak could allow bad actors to connect to command & control systems and allow them to gain direct access to the isolated network environment.
Bidirectional testing has been on our to-do list for a long time. The feature request was opened on our issue tracker already in April 2017 with a ticket number 73. As with every engineering task there were quite a few “trivial” intermediate steps.
Now we are happy to announce the bidirectional testing was released as part of Beacon 4!
The ticket #73: Triple-Ping for UDP
The ticket from 2017 was brief.
The ticket (by yours truly) in full:
- Ping from Beacon is received by Receiver. Now Receiver knows that Beacon can send data one-way.
- Pingback from Receiver to Beacon. With this Beacon knows it can receive data. Or Receiver might get ICMP (or other) error.
- Pingback from Beacon to Receiver. Now Receiver knows that two-way UDP communication works between Beacon and Receiver.
The trivial intermediate steps
Our original design included only one-way testing and so our cryptographic keys were only deployed for one-way communication: from Beacon to Home. During the development phase of Beacon 3 we added a second pair of keys for supporting two-way communication: from Home to Beacon. While we dive into the code we also found ways to simplify our payload structure by removing some old and unnecessary cruft which made all our escape packets smaller thus causing less traffic for networks. We are still using the XSalsa20Poly1305 authenticated encryption cipher for our encryption between Beacon and Home.
The cryptographic keys are always unique to a Beacon config: One keypair for Beacon to Home communication and another keypair to Home to Beacon communication.
The design and implementation of bidirectional testing
After cryptography primitives were in place we had a good look into design and implementation of the bidirectional testing itself. The original plan was still sound and we just sprinkled it with details. The three messages used for “Triple-Ping” are named Ping, Pong and Ding. Ping contains most of the information since it is also used in unidirectional case: It contains beacon’s name, sequence number and description of the escape: transport type (TCP, UDP, IP, etc.), escape technique (TCP connection, UDP datagram, DNS query, broadcast message, etc.) source and destination IP addresses, maybe related port or protocol number and hop count (used to calculate how many hops the packet traveled).
Pong and Ding messages only contain two values: A sequence number from the Ping message and an identification number to identify this particular bidirectional testing for every other test. No other additional information is needed. And both ways are encrypted with public key encryption.
Every bidirectional test starts with a single Ping message. If Home receives this Ping message it is logged and Alert is sent immediately. Then Home replies with a Pong message towards Beacon. If Beacon can receive Pong it sends Ding back to Home and if Home can receive Ding message it will send another Alert immediately, this time indicating a bidirectional test was possible to escape.
Launch and feedback
The bidirectional testing was released with Beacon 4 and the feedback has been positive. By updating your Beacons to the latest release you’ll get this and other new goodies also!
