Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


How can providers (and maybe malicious guys) get access to virtual box?
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

How can providers (and maybe malicious guys) get access to virtual box?

colingptcolingpt Member
edited January 2016 in Help

Hi guys,

Recently, from some LET threads, I realize some providers do access their clients virtual boxes without (or maybe with?) clients' passwords.

I don't have experience to run a vps service like kvm or ovz. How can they do this? Are there different methods to access different virtualization techs? Is kvm or Xen more difficult to access than OVZ?

if provider can not access to kvm or xen image directly, they maybe reset the password and get access? But what if I have set up the ssh-key to login and disable root login and password login? Can they still get access after reset?

I did a test on digitalocean, after root password reset, it still requires ssh-key and reject password and root login.

I checked on google, but didn't find more detail, and I don't know how to describe my question properly over google. So I asked here, guys, you may point me to some references or knowledge me here, both appreciate very much. thank you.

I ask this due to my curiosity and would like to know how to prevent this . Nothing other than this.

edit: since dissolution also involved ssh sercurity, so I edit a bit of the title.

original one is How can providers get access to virtual box?

«1

Comments

  • You can't really prevent unless the server runs with your eyeballs glued to it.

    Thanked by 2colingpt doghouch
  • You are cute.

    They are virtual computers, run / emulated on a host. Long term it will always be possible to gain access either one way or the other.

    Thanked by 1colingpt
  • Install Proxmox on a KVM to see how easy it is.

    Thanked by 1colingpt
  • @masterqqq said:
    You can't really prevent unless the server runs with your eyeballs glued to it.

    good point, but may not answer my curiosity...

    thanks anyway

  • jarjar Patron Provider, Top Host, Veteran

    OpenVZ is the easiest:

    vzctl enter [container ID]

    It gets more complex under real virtualization but anyone with physical access should be considered trustworthy or not hosted with.

    Thanked by 3colingpt Jonchun netomx
  • @jarland said:
    real virtualization

    what does "real virtualization"? kvm or xen or hyper-V.


    @Wolf sure, just as jarland said, any physical access will definitely have chance to do so, just discus this, some of them may not be that easy and time consumption may give a little shield of my data, period :P

  • @Traffic said:
    Install Proxmox on a KVM to see how easy it is.

    checked that a bit. from what you said, it sounds like there should have a simple function to access everything through the node. lol

  • Real is KVM or Xen.

    Container is Docker, LXC or OpenVZ.

    Container usually allows direct entrance by design for OpenVZ it's vzctl enter. KVM you can always get access to the machine via VNC (equivalent of plugging a monitor into it) or as previously stated by others you can mount the hard disk and edit it

    Thanked by 1colingpt
  • perennateperennate Member, Host Rep
    edited January 2016

    The disk contents of the VM need to be stored somewhere. It is stored on the host node. If an attacker has access to the host node, all they have to do is find the disk contents, create a block device from it, and mount the filesystem that's on the block device.

    If the disk is encrypted, then it is a bit more difficult, since mounting the filesystem will require the encryption key. However, just as the disk contents of the VM need to be stored somewhere, the encryption key also needs to be stored somewhere, otherwise how would the VM be able to write to the disk? It is stored in memory in the VM. The VM's memory is stored in memory on the host node. So attacker can dump the memory of the process where VM is running and search for the encryption key there.

    It doesn't matter if you are running KVM/Xen instead of OpenVZ/LXC, maybe you have to run two commands instead of one command to get access but fundamentally it is the same.

    On dedicated server in someone else's datacenter it is a bit different. It is still possible to get the disk contents; there are some minor details like they are probably going to need to shutdown the server and copy the hard drive in order to get the data, but more importantly, this requires physical access: so, as long as you trust the datacenter people, it is okay, you don't have to trust that the datacenter systems won't be compromised by a remote attacker. Also, if you do encrypt the filesystem, then it's actually quite difficult to dump the memory contents on the server without power cycle (and power cycle would clear the encryption key). Of course, they could always shutdown the server, install some monitoring system (e.g. check the keystrokes while you type the encryption password over IPMI), and then boot it back up; and remote attacker could do this too.

    Thanked by 1colingpt
  • If you need security it's a case of a dedicated server in your own secured building with 0 Internet access. All ports disabled excluding power and audio :)

  • @TinyTunnel_Tom said:
    KVM you can always get access to the machine via VNC (equivalent of plugging a monitor into it) or as previously stated by others you can mount the hard disk and edit it

    after accessing through VNC, they still need password or my ssh-key to login to get access my contents? right?

  • @colingpt said:

    Yes but the admin could mount your disk and insert his SSH key into your vps

  • They get hold of the harddisk and ram is enough to break in even in a dedicated.

    Thanked by 1colingpt
  • colingptcolingpt Member
    edited January 2016

    @TinyTunnel_Tom said:
    the admin could mount your disk and insert his SSH key into your vps

    mount my disk inside the kvm? or directly change everything from the node disk. thanks

  • perennateperennate Member, Host Rep
    edited January 2016

    colingpt said: mount my disk inside the kvm? or directly from the node disk. thanks

    Mount disk from the node. With container/VM, your data is stored on provider's infrastructure and can be readily accessed. With dedicated server, it is isolated from the provider's system but still vulnerable if attacker has physical access to your system. So dedicated server is more secure because you don't have to trust that the provider's software won't be compromised, since even if datacenter software is compromised, your disk contents still can't be read.

    (Unless they have rescue mode and stuff that attacker can exploit.)

    Thanked by 1colingpt
  • colingptcolingpt Member
    edited January 2016

    @perennate said:

    Well explained and really appreciated!

    "It doesn't matter if you are running KVM/Xen instead of OpenVZ/LXC, maybe you have to run two commands instead of one command to get access but fundamentally it is the same."

    so basically, even on a dedicated node, it is better to encrypt disk in case of physical access (a thief in datacenter :-).

  • It's like you deposit some money in the bank. The bank (and staff) always have access to your account.

  • colingpt said: I ask this due to my curiosity and would like to know how to prevent this . Nothing other than this.

    Similar to a landlord having access to the rental.

  • perennateperennate Member, Host Rep

    colingpt said: so basically, even on a dedicated node, it is better to encrypt disk in case of physical access (a thief in datacenter :-).

    I wouldn't say "better", encryption means CPU overhead for disk operations. If you encrypt disk, then it is less likely that an attacker with physical access to your machine can get the disk contents. Of course, like I said, they can trick you into revealing the encryption key passphrase, e.g. by rebooting your server and monitoring IPMI traffic.

    Thanked by 1colingpt
  • colingptcolingpt Member
    edited January 2016

    @perennate said:

    >

    Just find another question, is it easy that a provider to decrypt my password used for root in a vps by accessing files and analysis them? how linux system store that information? That much more matters to me, cause I use similar "strong" passwords for all vpses I got...

    edit: ok, I guess I find it myself this time. XD thanks anyway.

  • raindog308raindog308 Administrator, Veteran

    colingpt said: mount my disk inside the kvm? or directly change everything from the node disk. thanks

    Or just clone a copy and you would never know.

    colingpt said: how linux system store that information?

    It's stored as a salted hash.

    Or at least it's supposed to be...then again...where did your OS template come from? Your provider very likely.

    colingpt said: That much more matters to me, cause I use similar "strong" passwords for all vpses I got...

    The first problem is that you shouldn't be using passwords...

    Thanked by 1colingpt
  • colingptcolingpt Member
    edited January 2016

    @raindog308 said:
    The first problem is that you shouldn't be using passwords...

    i use ssh-key to login but sudo needs password to get approved, right. Did I do something wrong (stupid) here by this way?

    raindog308 said: where did your OS template come from? Your provider very likely.

    good point can not be argued XD

  • raindog308raindog308 Administrator, Veteran

    colingpt said: i use ssh-key to login but sudo needs password to get approved, right. Did I do something wrong (stupid) here by this way?

    No. You really should not think of your passwords, keys, credentials, etc. as giving you any kind of protection against someone who can (virtually or physically) take your hard drive and mount it somewhere else. No difference than someone stealing your hard drive at home.

    Now, if you've encrypted the hard drive on your home computer, the thief is out of luck. But on a VPS, a devious and sophisticated host can get your encryption key.

    Thanked by 1netomx
  • @raindog308 said:

    at least to prevent Brute force root passwd attack from internet

  • colingpt said: Brute force root passwd attack from internet

    Don't leave ssh open on port 22, stops 99% of brute force attempts, and PermitRootLogin without-password disables any password from working, until OpenSSH is exploited again.

    If you are trying to hide from your provider, find another provider. Any reputable provider is not going to waist time rummaging through your files when there is Netflix to watch. But encrypting your drive on KVM/Xen/Windows crap is a semi-good idea, and not to hide from your provider, but your providers Government. Again, any reputable provider will hand over a cloned copy of your drive when presented a valid warrant, but if you encrypted the drive, what good will that clone be? Sure the provider can dump your active memory on the node and probably get your access key, but why when there is Nexflix to solve any free time issue they might have.

    I understand you are trying to learn something, but you are also looking like you are trying to figure out how to hide shady activity.

  • @colingpt said:
    Hi guys,

    Recently, from some LET threads, I realize some providers do access their clients virtual boxes without (or maybe with?) clients' passwords.

    I don't have experience to run a vps service like kvm or ovz. How can they do this? Are there different methods to access different virtualization techs? Is kvm or Xen more difficult to access than OVZ?

    if provider can not access to kvm or xen image directly, they maybe reset the password and get access? But what if I have set up the ssh-key to login and disable root login and password login? Can they still get access after reset?

    I did a test on digitalocean, after root password reset, it still requires ssh-key and reject password and root login.

    I checked on google, but didn't find more detail, and I don't know how to describe my question properly over google. So I asked here, guys, you may point me to some references or knowledge me here, both appreciate very much. thank you.

    I ask this due to my curiosity and would like to know how to prevent this . Nothing other than this.

    Please if us providers told you how we do this would it be a "secret" anymore?
    as you do know not every provider does this unless they have to under certain circumstances like for example abuse notice from their dedi/colo provider, they have logs sent to them from their dedi/colo provider saying one of their clients is hosting something illegal etc. so no the more better hosts on here including me(who is honest) would not just snoop into your stuff unless I am required by law to do.

    Thanked by 1colingpt
  • raindog308 said: The first problem is that you shouldn't be using passwords...

    +1 IMHO I start at the point of 'The provider (or some admin/tech/junior/pissed of staff member) will always have access to my machine(s)'

    Thanked by 1colingpt
  • teknolaizteknolaiz Member
    edited January 2016

    @miTgiB said:
    Don't leave ssh open on port 22, stops 99% of brute force attempts, and PermitRootLogin without-password disables any password from working, until OpenSSH is exploited again.

    I'd like to add something to this.

    Use a port between 1 to 1024 for SSH but not the default port 22. It is important to use a privileged port for SSH.

    Read why here: https://www.adayinthelifeof.nl/2012/03/12/why-putting-ssh-on-another-port-than-22-is-bad-idea/

    It is certainly a good idea to move from 22 though to get rid of 99% of all bruteforce attempts but don't use ports above the privileged port range (1 - 1024).

    Thanked by 1colingpt
  • @teknolaiz said:
    It is certainly a good idea to move from 22 though to get rid of 99% of all bruteforce attempts but don't use ports above the privileged port range (1 - 1024).

    That always gets posted on here and it's a load of rubbish. For that to be a problem a malicious person would already need access to your machine, at which point you're fucked anyway

  • @hostnoob said:
    That always gets posted on here and it's a load of rubbish. For that to be a problem a malicious person would already need access to your machine, at which point you're fucked anyway

    Come out of your own little world and think of the bigger picture. You won't fall apart for doing that once.

Sign In or Register to comment.