oxeo0/blog-contributions
1
0
Fork 0
mirror of http://git.nowherejezfoltodf4jiyl6r56jnzintap5vyjlia7fkirfsnfizflqd.onion/nihilist/blog-contributions.git synced 2025-07-02 06:46:42 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

create separate section for bare-metal servers

Browse source
This commit is contained in:
midas 2025-01-29 18:59:16 +01:00
parent 02a0d6b3c0
commit 4ae8e808c1
1 changed files with 47 additions and 7 deletions
Download patch file Download diff file Expand all files Collapse all files

54
opsec/cloud_provider_adversary/index.html
View file

@ -183,8 +183,47 @@ in this post we are going to do a threat modelling exercise:<br><br>
<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.
<h1><b>VPS Attack scenarios</b><h1>
<h2><b>Live RAM extraction</b></h2>
<h3>Attack</h3>
Bob makes a RAM snapshot of the virtual machine. on a VPS it is very easy and can be done without notice.
<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).
<h2><b>Malicious Libvirt or Xen Interception</b></h2>
<h3>Attack</h3>
Bob modifies the hypervisor's behavior to manipulate network, disk, or console input/output in real time.
Can inject fake SSH authentication prompts or steal plaintext database queries before they reach encrypted storage.
<h3>Countermeasures</h3>
None, this would be undetectable from within the VPS.
<h2><b>Covert Persistent Backdoor via VMState Injection</b></h2>
<h3>Attack</h3>
Bob can embed custom logic in the hypervisor to modify the VPS state after every reboot, reinfecting it persistently.
Similar to NSA’s DEITYBOUNCE attack, where malware implants are injected into firmware or hypervisor layers to reinfect systems post-wipe.
<h3>Countermeasures</h3>
Hardly any, if the modification has been done directly in the kernel and in such a way that disables rootkit-detection or other security systems then it can't be detected or mitigated
<h1><b>Conclusion</b></h1>
A VPS provides no privacy from a malicious cloud provider. If used, only encrypted data should transit/be stored in it and the decryption keys should never be present anywhere accessible by it.
</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>Bare Metal Attack scenarios</b><h1>
<h2><b>Live RAM extraction</b></h2>
@ -192,21 +231,21 @@ in this post we are going to do a threat modelling exercise:<br><br>
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).
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.
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 server.
<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.
This attack has the same issue as the previous one and could be deployed during a schedule maintenance at Bob's datacenter. Ensuring a TPM is present on the motheboard and only signed firmware updates are accepted is a first step. This wouldn't protect her from a malicious update signed with a legitimate key as some government agency could deploy. Another, better option is to opt for a physical enclosure only she can access in the datacenter and be present during maintenance. Such enclosure would need to be monitored and trigger a server poweroff in case of breach.
<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.
A physically locked enclosure such as ones used by payment processors in their datacenters would greatly reduce the likelihood of this attack.
</div>
@ -215,7 +254,8 @@ in this post we are going to do a threat modelling exercise:<br><br>
</div><!-- /grey -->
<div id="anon3">
<div id="anon2">
<div class="container">
<div class="row">
<div class="col-lg-8 col-lg-offset-2">