mirror of
http://git.nowherejezfoltodf4jiyl6r56jnzintap5vyjlia7fkirfsnfizflqd.onion/nihilist/blog-contributions.git
synced 2025-07-02 11:56:40 +00:00
280 lines
14 KiB
HTML
280 lines
14 KiB
HTML
<!DOCTYPE html>
|
|
<html lang="en">
|
|
<head>
|
|
<meta charset="utf-8">
|
|
<meta http-equiv="X-UA-Compatible" content="IE=edge">
|
|
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
|
<meta name="description" content="Cloud provider threat model">
|
|
<meta name="author" content="MulliganSecurity">
|
|
<link rel="shortcut icon" href="../../../../../../assets/img/favicon.png">
|
|
|
|
<title>What can an hostile cloud provider see and do?</title>
|
|
|
|
<!-- Bootstrap core CSS -->
|
|
<link href="../../assets/css/bootstrap.css" rel="stylesheet">
|
|
<link href="../../assets/css/xt256.css" rel="stylesheet">
|
|
|
|
|
|
|
|
<!-- Custom styles for this template -->
|
|
<link href="../../assets/css/main.css" rel="stylesheet">
|
|
|
|
|
|
|
|
<!-- HTML5 shim and Respond.js IE8 support of HTML5 elements and media queries -->
|
|
<!--[if lt IE 9]>
|
|
<script src="https://oss.maxcdn.com/libs/html5shiv/3.7.0/html5shiv.js"></script>
|
|
<script src="https://oss.maxcdn.com/libs/respond.js/1.3.0/respond.min.js"></script>
|
|
<![endif]-->
|
|
</head>
|
|
|
|
<body>
|
|
|
|
<!-- Static navbar -->
|
|
<div class="navbar navbar-inverse-anon navbar-static-top">
|
|
<div class="container">
|
|
<div class="navbar-header">
|
|
<button type="button" class="navbar-toggle" data-toggle="collapse" data-target=".navbar-collapse">
|
|
<span class="icon-bar"></span>
|
|
<span class="icon-bar"></span>
|
|
<span class="icon-bar"></span>
|
|
</button>
|
|
<a class="navbar-brand-anon" href="\index.html">The Nihilism Blog</a>
|
|
</div>
|
|
<div class="navbar-collapse collapse">
|
|
<ul class="nav navbar-nav navbar-right">
|
|
|
|
<li><a href="/about.html">About</a></li>
|
|
<li><a href="/blog.html">Categories</a></li>
|
|
<li><a href="https://blog.nowhere.moe/donate.html">Donate</a></li>
|
|
<li><a href="/contact.html">Contact</a></li>
|
|
</ul>
|
|
</div><!--/.nav-collapse -->
|
|
|
|
</div>
|
|
</div>
|
|
|
|
<!-- +++++ Posts Lists +++++ -->
|
|
<!-- +++++ First Post +++++ -->
|
|
<div id="anon2">
|
|
<div class="container">
|
|
<div class="row">
|
|
<div class="col-lg-8 col-lg-offset-2">
|
|
<a href="../index.html">Previous Page</a></br></br><p><img src="../../assets/img/mulligan_sec.jpeg" width="50px" height="50px"> <ba>Mulligan Security - 21 / 01 / 2025</ba></p>
|
|
<p>
|
|
<h1><b> How safe am I from my cloud provider? </b></h1>
|
|
|
|
Since the 2010's VPS have become cheaper and widely available. From your local mom and pop datacenter where you can rent a baremetal Pi equivalent to highly secured Amazon datacenters and on-demand cpu/bandwidth allocation you can now find a broad range of options for your operational and security needs.
|
|
|
|
<br>
|
|
<br>
|
|
If clandestinity is a requirement, there also are cryptocurrency-based options in jurisdictions without LEO cooperation treatises with your own.
|
|
|
|
<br><br>
|
|
|
|
But, <b>what if the adversary is already inside?<b><br>
|
|
|
|
in this post we are going to do a threat modelling exercise:<br><br>
|
|
|
|
<ol>
|
|
<li>Context and assumptions: what are the capabilities of our adversary? what about our own OPSEC requirments?</li>
|
|
<li>Threats: what the adversary might want to acomplish (their goal)</li>
|
|
<li>Attack Scenarii: a quick list of possible attacks</li>
|
|
<li>Mitigation measures: what we can do to make those attack uneconomical, harder</li>
|
|
</ol>
|
|
|
|
<br><br>
|
|
<b> Let's start with an image to visualize exactly what the trust and security boundaries are in such a setup</b>
|
|
|
|
<img src="diagram.svg">
|
|
|
|
</div>
|
|
</div><!-- /row -->
|
|
</div> <!-- /container -->
|
|
</div><!-- /grey -->
|
|
|
|
|
|
<div id="anon2">
|
|
<div class="container">
|
|
<div class="row">
|
|
<div class="col-lg-8 col-lg-offset-2">
|
|
<h1><b>Context and assumptions</b></h1>
|
|
|
|
<h2><b>Setting up the scene</b></h2>
|
|
|
|
Alice wishes to start hosting a coordination platform for her activist group, but she doesn't want to host the platform herself for the following reasons:
|
|
|
|
<ul>
|
|
<li>Shes does not want to have incriminating data in her house</li>
|
|
<li>She is unable to provide the required level if high availability for her group's safety and operational standards</li>
|
|
<li>She has limited bandwidth/electricity to devote to her cause</li>
|
|
</ul>
|
|
<br>
|
|
<br>
|
|
|
|
She gets in touch with Bob, owner and operator of Bob's friendly datacenter, and orders from him a VPS (Virtual Private Server). Bob's pretty open-minded so Alice is free to use whatever OS she wants, gets a public IP.
|
|
<br><br>
|
|
<h2><b>Enters Leo</b></h2>
|
|
|
|
One day Bob's phone rings, it's Leo calling! Leo asks Bob to confirm that he indeed has Alice as a customer. Without further ado, Leo pays Bob a visit! After entering the premises and showing a government agency badge, Leo asks for complete access to Bob's infrastructure and binds him with a gag order to make sure no one hears about his investigation. Even if Bob is sympathetic to Alice or wishes to protect his customers he would now run afoul of his country's laws if he were to warn them. Leo might have been nice to him but he is not to be trifled with...
|
|
|
|
<h2><b> Leo sets up shop </b></h2>
|
|
Commandeering an office in Bob's datacenter, Leo gets to work. He has plenty of options:
|
|
|
|
<ol>
|
|
<li>Network sniffing: Leo can capture and log ALL trafic related to Alice's activity inside Bob's datacenter, so he will know the IP of everyone interacting with her platform</li>
|
|
<li>Firmware/hardware attacks: during maintenance windows, Leo could tamper with the BIOS/UEFI of Alice's server (if she had chosen a bare-metal option), or with her server's storage devices in order to deactivate encryption or exfiltrate data unnoticed</li>
|
|
<li>Memory attacks: Leo is able to take snapshots of Alice's VPS RAM to gather information about her activities. If she had chosen a bare-metal server he could cut the power, extract and refrigerate the RAM sticks in order to retrieve the data, but such an attack would be very conspicuous</li>
|
|
</ol>
|
|
|
|
|
|
</div>
|
|
</div><!-- /row -->
|
|
</div> <!-- /container -->
|
|
</div><!-- /grey -->
|
|
|
|
|
|
<div id="anon3">
|
|
<div class="container">
|
|
<div class="row">
|
|
<div class="col-lg-8 col-lg-offset-2">
|
|
<h1><b><b>Alice's threat model</b></h1>
|
|
Alice is very happy with her new deployment. The platform runs great and her team has started using it in earnest. Still, the bond of implicit trust that now exists between her and Bob bothers here. She decides to do a quick threat modelling exercise to calm her mind: instead of wondering about whatifs, she is going to identify the risks associated with her current setup and find ways to mitigate them.
|
|
|
|
<h2><b>Threats to Confidentiality</b></h2>
|
|
If Bob was dishonest (or compelled into acting dishonestly), he would be able to harvest information directly from her server's memory! (She doesn't know Leo is already hard at work)<br><br>
|
|
<b>Impacted assets<b><br>
|
|
<ul>
|
|
<li>decryption keys (eg: her https private key, allowing for complete decryption of her team's traffic)</li>
|
|
<li>sensitive data (ephemeral private messages on her forum that arer only kepy in RAM in an unencrypted form)</li>
|
|
<li>software state (session cookies, metadata)</li>
|
|
</ul>
|
|
|
|
<br><br>
|
|
Bob could also use side-channel attacks by monitoring the underlying server's power usage or run cache timing attack to find the value of her cryptographic secret keys even if Bob's hardware allows her to store them in a dedicated secure chip!
|
|
|
|
<h2><b>Threats to integrity</b></h2>
|
|
Someone with Bob's level of access (he is the administrator of the <i>hypervisor</i> - the software that runs Alice's virtual server) could also:
|
|
|
|
<ul>
|
|
<li>Run an evil maid attack: inject thir own code in the bootloader, in Alice's OS image or inside the hypervisor which Alice can't monitor</li>
|
|
<li>Through the hypervisor, tamper with Alice's virtual machine to compromise it</li>
|
|
</ul>
|
|
|
|
<h2><b>Threats to availability</b></h2>
|
|
|
|
Having access to the physical layer of the network as well as the power grid feeding the servers, Bob could disrupt Alice's operations in the following way:
|
|
<ul>
|
|
<li>Disconnect Alice's VM from the network</li>
|
|
<li>Throttle Alice's network traffic</li>
|
|
<li>Cut the power off to Alice's host server to perform a cold boot attack </li>
|
|
</ul>
|
|
|
|
|
|
</div>
|
|
</div><!-- /row -->
|
|
</div> <!-- /container -->
|
|
</div><!-- /grey -->
|
|
|
|
<div id="anon2">
|
|
<div class="container">
|
|
<div class="row">
|
|
<div class="col-lg-8 col-lg-offset-2">
|
|
|
|
<h1><b>Attack scenarii</b><h1>
|
|
Having finished her thread enumeration, Alice's decides to focus her efforts on three most probable/most damaging scenarii to protect herself and her organization.
|
|
|
|
<h2><b>Live RAM extraction</b></h2>
|
|
|
|
<h3>Attack</h3>
|
|
Bob powers down the serve hosting the vps and extracts its RAM, refrigerate it to analyze its contents
|
|
|
|
<h3>Countermeasures</h3>
|
|
This one is very tricky and can't be addressed without renting a bare-metal server instead. Alice would need hardware that supports RAM encryption (such as AMD SEV and SME).
|
|
<br><br>
|
|
This attack is both costly and obvious as it requires the server to go offline. Alice's decides to accept the risk for now and reevaluate based on the evolving sensitivity of the data stored on her VPS.
|
|
|
|
<h2><b>BMC Exploitation</b></h2>
|
|
<h3>Attack</h3>
|
|
A malicious firmware update is deployed to the Baseboard Management Controller (BMC), providing stealthy persistent access and enabling future compromise of the OS or hypervisor.
|
|
<h3>Countermeasures</h3>
|
|
This attack has the same issue as the previous one and could be deployed during a schedule maintenance at Bob's datacenter even if Alice was using a baremetal. If she were to migrate to such a setup, then ensuring a TPM is present on the motheboard and only signed firmware updates are accepted would be a first step. This wouldn't protect her from a malicious update signed with a legitimate key as some government agency could deploy.
|
|
|
|
<h2><b>Evil Maid Attack</b></h2>
|
|
<h3>Attack</h3>
|
|
With physical access to the server, a rogue technician could inject a rootkit into the UEFI to mainain persistance, running their code before the OS loads.
|
|
<h3>Countermeasures</h3>
|
|
A baremetal server in a physically locked enclosure such as ones used by payment processors in their datacenters would greatly reduce the likelihood of this attack. Again, Alice deems the current sensitivity of her data not sufficient to justify the costs.
|
|
|
|
|
|
</div>
|
|
</div><!-- /row -->
|
|
</div> <!-- /container -->
|
|
</div><!-- /grey -->
|
|
|
|
|
|
<div id="anon3">
|
|
<div class="container">
|
|
<div class="row">
|
|
<div class="col-lg-8 col-lg-offset-2">
|
|
|
|
<h1><b>Conclusion</b></h1>
|
|
Following her analysis, Alice understands that having a VPS gives her no privacy from her cloud provider. That all of her traffic and data can easily be seen, copied or moved. She updates her risk analysis and changes her organization's SOPS so her team can have an appropriate behavior when using the services she hosts on this platform. <br><br>
|
|
|
|
<h2><b>Organizational mitigations</b></h2>
|
|
|
|
<ul>
|
|
<li>Use of codewords when discussing operations and people</li>
|
|
<li>Use of onion services to protect the anonymity of her teammates when accessing her services</li>
|
|
<li>Use of a separate server with higher security requirements for critical data</li>
|
|
</ul>
|
|
|
|
|
|
</div>
|
|
</div><!-- /row -->
|
|
</div> <!-- /container -->
|
|
</div><!-- /grey -->
|
|
|
|
|
|
|
|
|
|
<!-- +++++ Footer Section +++++ -->
|
|
|
|
<div id="anonb">
|
|
<div class="container">
|
|
<div class="row">
|
|
<div class="col-lg-4">
|
|
<h4>Nihilism</h4>
|
|
<p>
|
|
Until there is Nothing left.</p></br></br><p>Creative Commons Zero: <a href="../../../../opsec/runtheblog/index.html">No Rights Reserved</a></br><img src="\CC0.png">
|
|
|
|
</p>
|
|
</div><!-- /col-lg-4 -->
|
|
|
|
<div class="col-lg-4">
|
|
<h4>My Links</h4>
|
|
<p>
|
|
|
|
<a target="_blank" rel="noopener noreferrer" href="http://blog.nowhere.moe/rss/feed.xml">RSS Feed</a><br/><a target="_blank" rel="noopener noreferrer" href="https://simplex.chat/contact#/?v=2-7&smp=smp%3A%2F%2FL5jrGV2L_Bb20Oj0aE4Gn-m5AHet9XdpYDotiqpcpGc%3D%40nowhere.moe%2FH4g7zPbitSLV5tDQ51Yz-R6RgOkMEeCc%23%2F%3Fv%3D1-3%26dh%3DMCowBQYDK2VuAyEAkts5T5AMxHGrZCCg12aeKxWcpXaxbB_XqjrXmcFYlDQ%253D&data=%7B%22type%22%3A%22group%22%2C%22groupLinkId%22%3A%22c3Y-iDaoDCFm6RhptSDOaw%3D%3D%22%7D">SimpleX Chat</a><br/>
|
|
|
|
</p>
|
|
</div><!-- /col-lg-4 -->
|
|
|
|
<div class="col-lg-4">
|
|
<h4>About Mulligan Security</h4>
|
|
<p style="word-wrap: break-word;"><u>Donate XMR:</u><br>86NCojqYmjwim4NGZzaoLS2ozbLkMaQTnd3VVa9MdW1jVpQbseigSfiCqYGrM1c5rmZ173mrp8RmvPsvspG8jGr99yK3PSs</p></br><p><u>Contact:</u> mulligansecurity@riseup.net <br><a href="http://msec2nnqtbwh5c5yxpiswzwnqperok5k33udj7t6wmqcleu3ifj34sqd.onion">website</a></p>
|
|
|
|
</div><!-- /col-lg-4 -->
|
|
|
|
</div>
|
|
|
|
</div>
|
|
</div>
|
|
|
|
|
|
<!-- Bootstrap core JavaScript
|
|
================================================== -->
|
|
<!-- Placed at the end of the document so the pages load faster -->
|
|
|
|
</body>
|
|
</html>
|