More Pale Moon drama. Insists BuyVM being responsible for the breach.

stefeman

Since last thread was closed down heres continuation:

He even suggests that @Francisco would've used master key to access his machine with that analogy.

Heck, the reason this happened to begin with is not even because we did anything wrong, but because an assumed-safe environment provided by a third party turned out not to be.

I'll draw an analogy for all the people who missed the details of the situation:
Compare it to living in an apartment building. You assume your apartment is safe because the door locks, and you always make sure to lock it and keep the key safely in your pocket. The building has a more secure entrance with a door that can't possibly be breached/picked open.
Now imagine having a break-in from either one of your fellow tenants because the lock on your apartment door is busted or crappy, or the landlord who just lets himself in with the master key. Whose fault would that be? Yours or the landlord's (in both cases)?
To continue the analogy: I've moved out of the building as a result, and will move to a building where I have known and trusted the landlord for many years.

https://forum.palemoon.org/viewtopic.php?f=17&t=22520&start=20

Then he censors all replies that says otherwise.

stefeman

He bans instantly anyone that replies something else than blaming BuyVM for the incident.

Amitz

A new thread for the Kindergarten? Really?

JerryHou

Am I missing some drama here?...

captainwasabi

To whom does the finger point, it points at thee.

stefeman

@JerryHou said:
Am I missing some drama here?...

https://www.lowendtalk.com/discussion/158899/allegations-against-buyvm

AnthonySmith

3 Mistakes.

1. He/she/they OBVIOUSLY left the fucking window open.

2. He/she/they assumed someone else took responsibility for locking his own door.

3. He/she/they assumed it was the hosts responsibility to secure the empty apartment they rented with NO pre-installed locks and its own individual door not in any way connected to the apartment entrance.

1 Conclusion.

idiot.

/thread.

LTniger

He is wearing a scale male, literally. Imagine: fat male around 45 years old, with pwned ego in a scale male sitting on a chair in dark room at his parrents basement.

deank

No one with a sane mind trusts any keys to any landlord.

But that's just me.

uptime

nobody saw me do it you can't prove anything!

cybertech

Should have just bought his own data center. Then again u might not be free of Snowden conspiracy theories. Damn this world is harsh.

AnthonySmith

deank said: No one with a sane mind trusts any keys to any landlord.

But that's just me.

And leaves the windows open on a ground floor apartment and also blames the landlord.

RedSox

How to become a landlord?

yokowasis

Drama aside, is it really possible for the host to breach into kvm vps without removing / resetting the root password, e.g. Using The master password?

FAT32

@yokowasis said:
Drama aside, is it really possible for the host to breach into kvm vps without removing / resetting the root password, e.g. Using The master password?

When there's a will, there's a way, I might not know how, but I would say yes

deank

@yokowasis said:
Drama aside, is it really possible for the host to breach into kvm vps without removing / resetting the root password, e.g. Using The master password?

Oh, yeah, easily possible. Just ask @Teamacc.

His vps host just logged into his vps for fun.

donli

@yokowasis said:
Drama aside, is it really possible for the host to breach into kvm vps without removing / resetting the root password, e.g. Using The master password?

He who controls the physical hardware controls the contents of the physical hardware.

Gamma17

With unencrypted "hdd" getting into VM from the host is as easy as shutting down VM for "node reboot required for updates" or whatever and mounting VM "hdd" on the host.
Another question is - why would provider do it, and why would he then infect something with malware... a few situation could be imagined from just some employee having fun to some summerhost owner having fun, but how likely they are in this specific case?

And the "statements" TBH look stupid... to the point when one might suspect something shady. Sure it cannot be just stupidity, right? Old, unmonitored windows VM exposed to internet was hacked, how surprising...

Sad too, as i was using this browser. With such "smart" reaction to the issue... Why not just apologize, describe what measures were taken to prevent it in future, do the usual stuff? This stuff happens, it is not good but not the end of the world either. It is probably time to go search for some other browser...

willie

Sheesh, if such an idiot was involved in that browser's development, someone please remind me not to use it.

sureiam

This isn't even drama. It's just stupidity. I see no reason why they ran a Windows server short of them not knowing how up setup a harden Linux web server.

Thusly it wouldn't surprise me at all that it was compromised. Only time you use Windows server is if you have zero choice in the application needed being windows based.

This isn't worth discussion, idk why it keeps getting posted. A provider is never responsible for intrusion. Frankly even if it occurred from another VM on the same node it's still the users fault for not hardening it. Some users need to go with managed services.

Actually I can't even figure out why they needed a Windows server to begin with? Why was the archive file itself not hosted on github, sourceforge, or a simple file hosting platform?

Learntolive

@AnthonySmith said:
3 Mistakes.

1. He/she/they OBVIOUSLY left the fucking window open.

2. He/she/they assumed someone else took responsibility for locking his own door.

3. He/she/they assumed it was the hosts responsibility to secure the empty apartment they rented with NO pre-installed locks and its own individual door not in any way connected to the apartment entrance.

1 Conclusion.

idiot.

/thread.

I Agree, The hosting provider is not responsible If you just buy server and dont Even hardening it.

The op probably American who thinks he can blame other people for his own shit.

stefeman

Cause it got posted to bleepingcomputer and zdnet and cisomag with all of them quoting francisco being at blame.

This thread and the previous one should get enough SEO on google to counter that lier that censors any free discussion of the incident to look good to journalists.

Besides Francisco has not responded yet.

AnthonySmith

yokowasis said: Drama aside, is it really possible for the host to breach into kvm vps without removing / resetting the root password, e.g. Using The master password?

Incredibly easy if not encrypted, no password even required, I could clone your file system, make changes and splice bits back in if I really wanted to, while it would leave some trace if you don't know what you are looking for, 99% don't, you would never know.

deank

What surprised me the most was the fact that someone actually used a Windows server for something other than an exchange server.

ITLabs

@RedSox said:
How to become a landlord?

1. Buy land
2. Go to elitetitles.co.uk
3. Buy a lifetime Lord title
4. Land + Lord = landlord
5. $$ profit $$

AnthonySmith

Gamma17 said: With unencrypted "hdd" getting into VM from the host is as easy as shutting down VM for "node reboot required for updates" or whatever and mounting VM "hdd" on the host.

Sorry to burst your bubble but no reboot, shutdown required, for at 'least' 4 years the ability for a KVM host to have full view of your filesystem has been trivial, it might as well be OpenVZ.

The ability for any one with a KVM VPS to prevent that is also trivial though, people make a choice to trust hosts, they also make a choice to use that as an excuse not to make basic "just in case" efforts.

Harambe

No established provider has the time, nor interest, to dick around in customer servers. Let alone a fucking Windows server that's hosting publicly accessible files. Talk about delusional, and completely unwilling to accept responsibility for his box getting popped for not securing it.

Regarding his dumb analogy, I wonder if he left his BuyVM internal IP poorly protected and someone on the location-wide internal network popped his unpatched Windows box. I mean, you shouldn't do that and it should be a zero tolerance termination policy if you're caught poking at other customers.. but it would be pretty entertaining if that was the case.

willie

AnthonySmith said: for at 'least' 4 years the ability for a KVM host to have full view of your filesystem has been trivial, it might as well be OpenVZ.

Does disk encryption make it harder much? Next idea after that I guess would be nested virtualization with the inner KVM handling the encryption and maybe a QEMU patched to obfuscate the ram contents.

Gamma17

@AnthonySmith said:

Sorry to burst your bubble but no reboot, shutdown required, for at 'least' 4 years the ability for a KVM host to have full view of your filesystem has been trivial, it might as well be OpenVZ.

The ability for any one with a KVM VPS to prevent that is also trivial though, people make a choice to trust hosts, they also make a choice to use that as an excuse not to make basic "just in case" efforts.

Obviously reading is trivial.
Writing, however, would require shutdown as otherwise things will break.
I just assumed that "breaking in" in this case is either fs modification or getting access to running OS, as files were obviously modified.

AnthonySmith

Gamma17 said: Writing, however, would require shutdown as otherwise things will break

Sorry, its really simple, it requires no shutdown, in fact some of the automation these days depends on that.

Obviously with malicious intent the host would have to think about the disruptive processes but that assumes joe avg would notice an 'insert application or service' being down for +/- 1 second.

Gamma17

@AnthonySmith said:

Sorry, its really simple, it requires no shutdown, in fact some of the automation these days depends on that.

Obviously with malicious intent the host would have to think about the disruptive processes but that assumes joe avg would notice an 'insert application or service' being down for +/- 1 second.

Honestly i see no way how a write could happen to a vm disk from outside with running OS and 100% guarantee that it will not crash or break something. Unless it is something very specific with very well known guest os behavior regarding that thing.
Or am i wrong and missing something? How does one modify MFT to increase file size for example, while there is whole os running on that FS with unknown operations to exacly the same MFT happening at the same time?

BlaZe

All this drama for his Internet Explorer looking web browser?

Pffftt.. need something more serious & important, pass.

joepie91

Gamma17 said: With unencrypted "hdd" getting into VM from the host is as easy as shutting down VM for "node reboot required for updates" or whatever and mounting VM "hdd" on the host.

"Unencrypted" barely even matters there. The host also has access to the memory of the VMs, so extracting any full-disk encryption keys is trivial.

Gamma17

@joepie91 said:

"Unencrypted" barely even matters there. The host also has access to the memory of the VMs, so extracting any full-disk encryption keys is trivial.

Obviously it is impossible to protect VM from actions performed by node admin.
But still there are differences between encrypted/unencrypted. First one being that it 100% identifies malicious intent from provider. Just looking at VM disk can be explained by administrative/support purposes, breaking encryption cannot. Second one - it still requires some extra effort/skill.
Also for me personally reason to encrypt is not protecting against "evil provider", but against someone pulling data from hdd's sold on ebay and such.

AnthonySmith

Gamma17 said: Honestly i see > no way how a write could happen to a vm disk from outside with running OS and 100% > guarantee that it will not crash or break something.

let me just assure you it is trivial.

joepie91

Gamma17 said: But still there are differences between encrypted/unencrypted. First one being that it 100% identifies malicious intent from provider. Just looking at VM disk can be explained by administrative/support purposes, breaking encryption cannot.

This is an irrelevant technicality in nearly every case, especially in the low-end hosting industry, where pretty much nobody ever goes to court over anything.

Gamma17 said: Second one - it still requires some extra effort/skill.

It requires running two commands instead of one. There are automated tools for extracting secrets from RAM.

Gamma17 said: Also for me personally reason to encrypt is not protecting against "evil provider", but against someone pulling data from hdd's sold on ebay and such.

Sure, that's a valid reason to do full-disk encryption. So long as you understand that the encryption is basically only useful for at-rest encryption (which means not for an active service), it can be a perfectly valid choice. Just don't underestimate how trivial it is to bypass it on a live system.

Francisco

A master key? To his windows install? I'm going back to bed.

I'll let my own reputation and long history of supporting my customers do the talking on this one.

We have tickets from him where he admits he didnt login to the server "for ages". Theres been plenty of nasty as hell exploits over the years and he got popped in 2017.

Theres been multiple RDP exploits in the past year, nevermind stuff like wannacry and similar.

Whatever

Francisco

deank

No need to defend yourself, Master Fran.

Anyone with an ounce of a brain can see that the guy is shitting in his pants to divert the heat from him.

ITLabs

It's cristal clear to me that @Francisco saw an opportunity to dominate the world by changing ShitMoonBrowser's code, invading an twisting his own network of Windows 3.11 BuyVMs. In his diabolic mind, he wanted to change the moon's course by sending a DDoS attack from all corrupted browsers. Luckily he was busted and decided to go back to bed and now this non sense thread can be finally closed.

hzr

joepie91 said: "Unencrypted" barely even matters there. The host also has access to the memory of the VMs, so extracting any full-disk encryption keys is trivial.

I feel like hacking a single specific mirror by the provider for no gain that gets 1 download a year and no one notices it's compromised for 2 years because no one downloads it is really stupid and pointless.

There are much easier targets to replace a binary. Their official downloads page basically eschews the free software hosting and build services/CI/etc to produce this:

And they don't enforce HTTPS and default to HTTP and the author has argued about how he won't enforce or redirect to HTTPS either.

naing

joepie91 said: Sure, that's a valid reason to do full-disk encryption. So long as you understand that the encryption is basically only useful for at-rest encryption (which means not for an active service), it can be a perfectly valid choice. Just don't underestimate how trivial it is to bypass it on a live system.

There are security through obscurity methods, such as various Digital Restrictions Management schemes, that make it non-trivial to bypass encryption. It's not security, but deterrence.

joepie91

@naing said:

joepie91 said: Sure, that's a valid reason to do full-disk encryption. So long as you understand that the encryption is basically only useful for at-rest encryption (which means not for an active service), it can be a perfectly valid choice. Just don't underestimate how trivial it is to bypass it on a live system.

There are security through obscurity methods, such as various Digital Restrictions Management schemes, that make it non-trivial to bypass encryption. It's not security, but deterrence.

DRM systems have absolutely nothing to do with full-disk encryption. They're entirely different systems with entirely different technical characteristics, and most importantly, the (very limited) 'deterrence' effect of DRM is not portable to FDE.

So no, FDE remains trivially easy to get around on a live system when you control the host node, and always will be.

naing

@joepie91 said:

@naing said:

joepie91 said: Sure, that's a valid reason to do full-disk encryption. So long as you understand that the encryption is basically only useful for at-rest encryption (which means not for an active service), it can be a perfectly valid choice. Just don't underestimate how trivial it is to bypass it on a live system.

There are security through obscurity methods, such as various Digital Restrictions Management schemes, that make it non-trivial to bypass encryption. It's not security, but deterrence.

DRM systems have absolutely nothing to do with full-disk encryption. They're entirely different systems with entirely different technical characteristics, and most importantly, the (very limited) 'deterrence' effect of DRM is not portable to FDE.

No, it's not portable to FDE, but the DRM scheme is applicable to sensitive data (for DRM it's a movie file, but for VPS it can be a database or virtual disk).

In my estimation, the characteristic that AES key never appears in the RAM in full is an effective (albeit very limited) deterrence for most low-end hosting providers.

hjlow

@Learntolive said:

@AnthonySmith said:
3 Mistakes.

1. He/she/they OBVIOUSLY left the fucking window open.

2. He/she/they assumed someone else took responsibility for locking his own door.

3. He/she/they assumed it was the hosts responsibility to secure the empty apartment they rented with NO pre-installed locks and its own individual door not in any way connected to the apartment entrance.

1 Conclusion.

idiot.

/thread.

I Agree, The hosting provider is not responsible If you just buy server and dont Even hardening it.

The op probably American who thinks he can blame other people for his own shit.

don't blanket blame Americans you idiot

jaypeesmith

If what Fran says is the case, disk encryption or any other measures are beyond this person's thinking. It sounds like this person might not have even been keeping up with Windows patches. Where I work, we have rolling downtimes on our Windows servers once a month. If this person had a habit of not logging into a server "for ages", who knows what exploits he/she ignored?

deank

Well, to be reasonably fair, I believe it was an archive server that got hacked.

If the team is small or even one man, chances are that such a server is overlooked.

Though, from what I can tell from blame-shifting game he is pulling, he is pretty much incapable of anything.

WebProject

AnthonySmith said: He/she/they assumed it was the hosts responsibility to secure the empty apartment they rented with NO pre-installed locks and its own individual door not in any way connected to the apartment entrance.

some people don't have clue what you are talking as much easier to pretend to be stupid - tell that is complicated and blame someone else.

sureiam

@AnthonySmith said:

Gamma17 said: With unencrypted "hdd" getting into VM from the host is as easy as shutting down VM for "node reboot required for updates" or whatever and mounting VM "hdd" on the host.

Sorry to burst your bubble but no reboot, shutdown required, for at 'least' 4 years the ability for a KVM host to have full view of your filesystem has been trivial, it might as well be OpenVZ.

The ability for any one with a KVM VPS to prevent that is also trivial though, people make a choice to trust hosts, they also make a choice to use that as an excuse not to make basic "just in case" efforts.

This is why I never understood the whole "bare metal kvm". Defeats the security of a properly configured dedicated server.

I've also been considering moving my KVMs to a dedicated server for this reason but it's such a pain i the ass to deal with a failure of a dedicated server.

I need more research into how to setup an easy to maintain virtual system on a dedicated server. Esx came to mind but backing it up became also annoying. Need a solution thatcan work well with a deduplication backup platform

Harambe

@sureiam said:
I need more research into how to setup an easy to maintain virtual system on a dedicated server. Esx came to mind but backing it up became also annoying. Need a solution thatcan work well with a deduplication backup platform

I'd suggest Proxmox, got it running on about a dozen servers at this point. Not sure about de-duped backups, never attempted that, but it might be possible.

IonSwitch_Stan

This is specifically why you digitally sign your releases. This developer sounds like a risk to his users

SirFoxy

@Francisco fucked my bitch I concur