Offline Server
Published: 2020-05-21 20:19:03

This last semester (Spring 2020) I developed a project in my CS5940 Network Security Class.

This is the Repo: https://github.com/ray836/Final-Project-CS5490

This is the Description:

Updating Logically Air Gapped Networks Using A Delayed
Intermediate Protocol
Bruce Englert, Ray Grant & Meghana Gupta
April 28, 2020
1 Introduction
As businesses move operations online, data protection becomes an increasingly critical aspect to many
major organizations and businesses. Systems that
ensure data security will have to be designed keeping data access patterns in mind.
We envision a use case when an organization might
only be interested in allowing data access from
within its physical premises. Air gapped networks
are systems that are physically isolated from the network and Internet. However, maintaining and updating these systems requires the physical presence
of an administrator, which might not be possible
when good-faith actors need to send critical data
from remote locations to such isolated networks,
while maintaining full encryption and secrecy.
To counter this problem, we have devised a proof-of-concept for a system that allows remote actors
to transfer critical data and update the same on a
secure server that is logically air-gapped i.e. disconnected from the Internet while being connected
to a trusted local area network that is monitored
and administered by trusted actors. We run three
programs on one machine to mimic the behavior
of the three nodes as in Figure 1 and attempt to
transmit data from the online to the offline node.
Our model demonstrates that it is possible to
maintain a logically air-gapped node that can receive data from remote sources while being able to
maintain encryption and integrity guarantees.
2 Related Work
There are many concepts and ideas used in real-world businesses and organizations to secure sensitive data on local networks. Many of these protocols consist of public and private key cryptography as well as network intrusion detection systems.
One concept that really changes the dynamic is an
air-gap network. The idea is that the local network can be secured by isolating it from the public
internet and any unsecured connections. Unfortunately, air-gapped networks still have some pertinent
threats they need to be secured against. The infamous Stuxnet worm infected many of Iran’s industrial sites through compromised physical media devices [1]. Other attacks have focused on using acoustic, thermal, and magnetic channels, amongst others,
to exfiltrate data from these systems [6, 5, 4, 7].
Even so, assuming secure physical access to the
server, the ability to take your network offline prevents large numbers of attacks that would otherwise
be present.
While organizations such as the NSA use air
gaped networks for the increased security it provides, this network architecture is not practical for
business use because of the latency overhead and
complications involved in updating data on the air
gapped server and allowing it to interact with online
services. Instead, mechanisms such as firewalls and
packet filtering systems are used more commonly by
businesses.
One example of packet filtering is the MCTLS
protocol [9], which allows middleboxes, or any similar "middle nodes", placed within networks to scan
and filter out unwanted requests. Middle nodes can
act as the first line of defense by terminating potentially dangerous requests. The idea behind the
MCTLS protocol is that middleboxes are provided
the minimum level of access; if their responsibility does not require modifying data, they are given
read-only permissions. For a middlebox, a slightly
higher privilege level would be the ability to decrypt
and modify only a part of the data that the client
intends it to.
While the MCTLS protocol is efficient at allowing
middleboxes to detect potentially malicious activity,
it requires that the server or internal endpoint always be online. This increases the duration through
which the internal node is susceptible to potential
break-ins due to zero-day vulnerabilities and or unsecured online attack vectors.
1
A (Online Node) B (Middle Node) C (Offline Node)
SSL Handshake
ga mod p
KAB {n1, t1} SSL Handshake
ga mod p
gc mod p , KBC {n2}
Internet Local
1
2
KAB {n1 - 1}
gc mod p
KAB {KAC {Personal Data}, Input Data}
KAB {n3, t2}
KBC {n2 - 1}
KBC {KAC {Personal Data}, Input Data}
KBC {n4}
3
4
Repeat 3
Repeat 4
Figure 1: Architecture of our PoC system
3 Adversary model
Our model assumes that the goal of the adversary
will be to decrypt exchanged messages to reveal the
coordinates being sent to the offline server. Additionally, they might also be interested in preventing
the system from functioning at its optimal capacity.
The model includes both online and offline attackers
who are capable of snooping on the network, reading
messages and editing them.
We do not consider any possible throttling or
the omission of packets by IP providers in our model.
Additionally, we do not consider bad faith actors
within the organization’s premises or it's secured
local area network that might physically reach the
offline node and access data on it.
Because we use public and private key cryptography between nodes, we do not see a man in the middle attack as being a threat to our system. However,
we do look at potential threats that can be caused
by an end-user with SQL injection attacks.
4 Methodology
We define our system as shown in Figure 1. The architecture involves three main nodes; an online node
(node A), middle node (node B), and offline node
(node C). Node C represents the logically air-gapped
node (disconnected from the public Internet) that
hosts the secure database. Node B is responsible
for physically connecting and disconnecting the local network and the internet; it is always connected
to either one or the other but never both at the same
time. A is the producer of data that needs to be securely transferred to the offline node without being
able to communicate directly. In practice, multiple
nodes can connect to A, which will act as a trusted
relay for our system to be able to receive data from
external clients. To achieve this logical isolation, the
middle node acts as the go-between for A and C.
Since B cannot be connected to both exterior
nodes at the same time, we have come up with a
process flow for B to generate a time in the future
when it will be online so as to allow A to communicate with it. This introduces a source of randomness
that prevents an external adversary from being able
to stage a server breach. We also allow B to store
a queue of messages received from A that will be
relayed to C at an appropriate time in the future.
We now describe our protocol in more detail.
Assuming that B is online at the very start of the
system, A first establishes a SSL handshake with
B. This establishes a secret key that A and B can
later use to exchange a nonce and the future time
at which A can transfer data to B. A also initiates
a Diffie Hellman key exchange with C through B;
this ephemeral Diffie Hellman public key, g
a mod p
is passed on by B to C. B now sends over the nonce,
2
n1 and future time t1 encrypted with the shared
key KAB established in the SSL handshake. To
prevent adversaries from being able to predict the
value of t1, we use a cryptographically secure PRNG
seeded with the shared keys established during the
SSL handshake.
Once the initial authentication phase between A
and B is complete, B disconnects from the public
internet and connects to its secured local network
containing C. B establishes an SSL handshake with
C, post which it passes on g
a mod p. C responds
with its own ephemeral Diffie Hellman public key
g
c mod p, followed by another random nonce n2
encrypted with KBC. This concludes the initial authentication phase between B and C. B subsequently
disconnects from the local network and rejoins the
public internet.
At time t1, A reaches out to B by transmitting
the nonce n1 − 1 encrypted with KAB. Once this is
done, B completes the DH exchange between the A
and C, which establishes an ephemeral shared secret
KAC. A transfers data encrypted with KAC and
KAB to B, which is later delivered to the C’s secure
database. Again, before disconnecting, B gives A
the next time at which it will be online t2.
Once back on the local network, B reaches out
to C, verifies itself, and passes along the encrypted
data received from A.
The idea behind establishing the DH key exchange
is to provide an additional layer of perfect forward
secrecy - even if an attacker can decrypt the time
at which B will next connect to the public internet,
it will be unable to decrypt the private data that A
only intends for C to decrypt.
While we have tried to minimize the attack surface on all nodes, there are certain attacks that our
system is still susceptible to. We elucidate them as
follows:
• A: Since A maintains a temporary queue of messages it can only relay to B when the latter is
connected to the public internet, it is still susceptible to a server break-in. Note that we have
not specified any format for how the data is
stored at A; any protocol that ensures safety
in case of a server breach should suffice, in our
view.
• B: B has a smaller surface area for attackers to
exploit. Even so, the time during which it is online and connected to the internet makes it open
to DDoS attacks. While we use a CSPRNG
which is seeded by the encrypted nonces exchanged by A and B to generate the timestamp
at which B will be online, an attacker might,
at random, be able to analyze traffic between A
and B and figure out when B is online. Additionally, while such attacks are hard to execute,
attacks could potentially tamper with the physical source of randomness of a CSPRNG [2] to
influence the values of the timestamps B generates. B might also be open to server break-ins
during this small window.
• C: C can only be compromised if B is connected
to the public internet.
5 Implementation
We have developed a proof-of-concept program that
can be viewed at our Github repo. We consider a
json string with location coordinates as a field to
be the data we want to transmit from A to C. The
applications allows A, B and C to be run as three
separate programs on a single machine or potentially
three separate nodes.
With our implemented system we’ve run various different tests and experiments. First, we’ve
looked at how the middle node can handle bad
packets/requests. Currently the middle node is
sanitizing all input data to prevent an SQL attack. We’ve found that although the middle node
could potentially be monitoring what type of connection/requests are potential threats and keeping
a black list of ips, that is very heavy weight. Being able to analyze portions of the data that is potentially volatile to our database is something more
concrete and light weight.
We have also run tests on long term uses of data
transfers. Currently our code runs ten data transfers from the online node to offline node with a delay
range of ten to thirty seconds. These transfers currently run properly and are scalable to longer time
periods. What we have found is that the node that
acts as the server, mainly the middle node, needs to
open it’s connection at least ten seconds before the
agreed upon time. This allows the server to catch a
request made by a node acting as a client.
At present, we have not implemented the feature
that retries a connection at a later time if A misses
the connection window. Further work can build
upon this proof-of-concept to demonstrate possible
attacks and security features that might overcome
3
said attacks.
6 Conclusion
We have developed a PoC that demonstrates how
an air gapped system can be brought online while
maintaining the security that physical air gapping
can provide. Our model prioritizes securely storing
and updating data on the offline node. Future work
would include adding features in our code implementation that will address a CSPRNG to generate
online times, and allow A to use a similarly seeded
CSPRNG to predict and coordinate when B will be
online next. We are also interested in adding functions to sanitize malicious input, passed on by clients
through A, at B.
References
[1] The real story of stuxnet, February 2013.
https://spectrum.ieee.org/telecom/
security/the-real-story-of-stuxnet.
[2] Lavarand in production: The nittygritty technical details, November
2017. https://blog.cloudflare.com/
lavarand-in-production-the-nitty-gritty-technical-details/.
[3] How secure are air gapped computers from intrusion?, April 2020. https://www.coranet.com/
network-air-gapping/.
[4] M. Guri, M. Monitz, Y. Mirski, and Y. Elovici.
Bitwhisper: Covert signaling channel between
air-gapped computers using thermal manipulations. In 2015 IEEE 28th Computer Security
Foundations Symposium, pages 276–289, 2015.
[5] Mordechai Guri and Dima Bykhovsky. airjumper: Covert air-gap exfiltration/infiltration
via security cameras & infrared (ir). Computers
& Security, 82:15–29, 2019.
[6] Mordechai Guri, Andrey Daidakulov, and Yuval Elovici. Magneto: Covert channel between
air-gapped systems and nearby smartphones via
cpu-generated magnetic fields. arXiv preprint
arXiv:1802.02317, 2018.
[7] Mordechai Guri, Yosef Solewicz, Andrey
Daidakulov, and Yuval Elovici. Fansmitter:
Acoustic data exfiltration from (speakerless) air-gapped computers. arXiv preprint
arXiv:1606.05915, 2016.
[8] Alfred Menezes and Berkant Ustaoglu. On
reusing ephemeral keys in diffie-hellman key
agreement protocols. IJACT, 2(2):154–158,
2010.
[9] David Naylor, Kyle Schomp, Matteo Varvello,
Ilias Leontiadis, Jeremy Blackburn, Diego R
López, Konstantina Papagiannaki, Pablo Rodriguez Rodriguez, and Peter Steenkiste. Multicontext tls (mctls) enabling secure in-network
functionality in tls. ACM SIGCOMM Computer Communication Review, 45(4):199–212,
2015. https://conferences.sigcomm.org/
sigcomm/2015/pdf/papers/p199.pdf.
4