Howdy, Stranger!

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


ChicagoVPS hacked, bunch of VPS customers offline - Page 7
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.

ChicagoVPS hacked, bunch of VPS customers offline

145791016

Comments

  • @Shardhost overselling e3's ;)

  • @joepie91 said: Wait - does this mean you are not using PDO? If you were using PDO

    SolusVM is Perl, not PHP.

  • @Taz said: @Shardhost overselling e3's ;)

    I thought E3s but came to the conclusion that some heavy overselling so just assumed big nodes.

  • FranciscoFrancisco Top Host, Host Rep, Veteran

    @William said: SolusVM is Perl, not PHP.

    SolusVM is PHP.

    Very very very bad PHP.

    They don't use PDO either, they just have a database class they made that wraps mysql_*

    Francisco

  • @Francisco said: SolusVM is PHP.

    Very very very bad PHP.

    They don't use PDO either, they just have a database class they made that wraps mysql_*

    Francisco

    Thanks for this post. Very Very useful

  • pubcrawlerpubcrawler Banned
    edited November 2012

    Haven't scoured WHT or others for griping folks yet. Saw two threads on WHT with maybe 1-2 customers...Hmmm

    Imagine lots of these VPS accounts are very idle. Outage was a late evening east coast time and overnight. Once we get to 24 hours and above, I'd expect to hear the complaints roll in.

    If I counted right, there were 10 severs destroyed in the attack. 1000 accounts means an even load of 100 per server. Far less than some think CVPS loads them. Still downright profitable money there.

  • FranciscoFrancisco Top Host, Host Rep, Veteran

    @soluslabs said: Thanks for this post. Very Very useful

    I didn't say it was exploitable though? Your API side was the most clean part of the whole project. I figure the API was done by Phil/Jason directly.

    I still question the comment of it being an API exploit. while it isn't efficient to pull all API keys and walk the array as joepie is figuring, you're not passing any variables to SQL yet either meaning the only thing that would be technically able to use any exploits would have to already be authorized anyways.

    Francisco

  • @W1V_Lee said: I know not every customer will visit WHT or LET but I was expecting to see more upset folks about.

    @Spencer said: Or because 99% of them are sitting idle.

    As spencer said, most of them are probably empty :P Mine had nothing on it, too unreliable and crappy performance to use it for anything worthwhile.

  • @pubcrawler said: Imagine lots of these VPS accounts are very idle

    Mine was only idle because it could not do anything else. The performance was great up until about August and then SSH was slow, my BNC was laggy as heck and the disk IO was slow as well. At that point I moved my BNC off and it was fast as heck and kinda just been letting my time run out. Granted I did not ticket as I put in 2 tickets back in August which fixed it for maybe 12 hours.

    So yea, it is either abusers on there and them not doing much about it other than killing a process here and there or oversold. With this recent mishap, I decided to just cancel. Unfortunately my experience with them has gone down hill since August and yea, this was just the push over the edge for me.

    **NOTE I did not lose any data nor had downtime. It was just unusable and no sense in keeping it around even though I did pay. Oh well.

  • Any other "victims" of the SolusVM imaginary exploits ?

  • joepie91joepie91 Member, Patron Provider

    @soluslabs said: Thanks for this post. Very Very useful

    I'm sort of waiting for a response to my post from you guys.

    @qhoster said: imaginary exploits ?

    Source?

  • @qhoster Yeah, none of this is real. Chris just wiped everyone's VPS for teh lulz.

  • Karma is a bitch but cocaine is a tigress.

  • @joepie91 said: Wait - does this mean you are not using PDO? If you were using PDO, SQL injection would not even be a possibility, so there would be no reason to pre-fetch all API users. Not to mention that it's very bad practice to move database operations (selecting rows) to your application code.

    We don't use PDO. I was merely saying that the function would not suffer a mysql injection due to the way it works.

    @joepie91 said: This is bad. Very very bad. You should not be rolling your own security unless you are an experienced cryptographer that has had his implementations peer-reviewed. Especially deriving it from some other bit of data is a big no-no - it only weakens your security.

    Don't forget your just talking about an API key and how it's generated. We are not encrypting important data!

  • joepie91joepie91 Member, Patron Provider

    @soluslabs said: We don't use PDO. I was merely saying that the function would not suffer a mysql injection due to the way it works.

    I don't really care about the way that particular API function works - you should be using PDO for the entire panel, period. The "fetch all users first and then compare" thing is nothing more than a very nasty hack that shouldn't ever appear in production code. Just use PDO already, and there's no need for hacky solutions like this.

    @soluslabs said: Don't forget your just talking about an API key and how it's generated. We are not encrypting important data!

    I am not 'just' talking about an API key. I am talking about a supposedly secure token that gives you access to make significant changes on servers and potentially cause serious damage. Security isn't just about encrypting things, it's just as much about protecting sensitive data or functionality in general. An authentication token should be generated in a cryptographically secure way, no exceptions. Add to that that there is quite literally no reason to derive an API key from some other bit of data (after all, the resulting key is stored anyway, so the derivation doesn't have to be reproducible and in fact shouldn't be). So why are you deriving it from something else in the first place, instead of using a purely random key?

    I suggest you have a watch to understand why a derivation like that is bad:

  • AnthonySmithAnthonySmith Member, Patron Provider

    Am I missing a trick here, I have read this whole thing and all I can make out is that there is no solusvm exploit (or at least one one that caused this) and there is no real problem with lightty that could have caused this and no one knows what cvps are talking about because they decided not to tell anyone?

    Does that about sum it up?

  • AnthonySmithAnthonySmith Member, Patron Provider

    @Jack thanks

  • @Jack said: I'll send you an email with the info I've got :)

    That should make @jshinkle want to share more with you in the future

  • AnthonySmithAnthonySmith Member, Patron Provider

    having read the email, it seems unlikely that's what happened, not impossible but winning the lottery unlikely.

  • Believe what you want to believe, It's is what it is. If you don't like it, then don;t like it. He only knows half the story and the basis of what happened, thus, he's running his mouth on shit he doesn't know.

    @Jack, if you want to keep running your mouth go for it, but obviously i have more important things to do then to baby sit you. I knew i shouldn't have opened my mouth and told you anything, heh.

    @miTgiB, right, not happening.

  • AnthonySmithAnthonySmith Member, Patron Provider

    So IP verification is off or that is the exploit?

  • @jshinkle said: Believe what you want to believe, It's is what it is. If you don't like it, then don;t like it. He only knows half the story and the basis of what happened, thus, he's running his mouth on shit he doesn't know.

    @Jack, if you want to keep running your mouth go for it, but obviously i have more important things to do then to baby sit you. I knew i shouldn't have opened my mouth and told you anything, heh.

    image

  • As I see a lot of people bashing CVP as a customer I figured I'd toss my 2 cents in. I host 2 servers with them, initially I bought them to play with and now I host a site on each one, I have no need for 2 but I figured what the hell.

    I have both of my VPS's knocked out and my backups were simply on the local boxes. My sites are still down and they are trying to recover them, I am not here on the forums bitching because I myself am a Server Admin and I would hate to be the techs trying to resolve customer complaints on top of get everything working again.

    I'll admit I am upset by this outage but I get what I pay for, I spent a whooping $14/month for my 2 VPS's with 2 GB RAM. So if I really was concerned about high availability I would have VMWare host or be hosted through AWS or Azure.

  • KuJoeKuJoe Member, Host Rep

    @AnthonySmith said: So IP verification is off or that is the exploit?

    Based on what I read the API does check the IP but it sounds like it also allows the localhost to access the API unrestricted (hence why I blacklisted the localhost from the API directory). Of course I don't know the whole story but with the word "bruteforce" being thrown around it sounds like the API ID/Key were manually altered in the database to be something very simple because by default I don't see how anybody could do it without investing millions of dollars of computing power.

  • rds100rds100 Member
    edited November 2012

    @KuJoe it looks like the API key user/password might be derived from a constant seeded with only 32bits of randomness, but that would still require about 4 billion attempts to exhaust the entire possible key space - not practical. Unless there is another shortcut somewhere.

    But i am more sold out on the theory that CVPS did something stupid and is just throwing bullshit and using SolusVM as an excuse card.

  • @Jack want to share what information you got with everyone?

  • KuJoeKuJoe Member, Host Rep

    @rds100 said: @KuJoe it looks like the API key user/password might be derived from a constant seeded with only 32bits of randomness, but that would still require about 4 billion attempts to exhaust the entire possible key space - not practical. Unless there is another shortcut somewhere.

    Is the 4 billions attempts based on the fact that they need to find both the ID and Key at the same time?

  • MaouniqueMaounique Host Rep, Veteran

    @apollo15 said: want to share what information you got with everyone?

    Even if Chris did something terribly wrong, if he sent a PM it is probably because that was intended to remain private.
    I would personally hate the idea of splashing PMs all over, even in the eventuality the guy denies what he said.
    M

  • AnthonySmithAnthonySmith Member, Patron Provider

    @KuJoe

    Thanks for the clarification makes more sense now that you summarised it :)hey have built a solid

    I am not bashing cvps for the record, I know a few people have issues with Chris but the fact is they have built a brand many people like.

    I think the reality is you are probably 100% on the button, I would like to think if it is a real exploit that they would have sent the information to solusvm for the good of the community, given solusvm's reply I think this is unlikely or solusvm are helping them with damage limitation which is probably not the case.

  • rds100rds100 Member
    edited November 2012

    @KuJoe said: Is the 4 billions attempts based on the fact that they need to find both the ID and Key at the same time?

    From what soluslabs said both the ID and Key are somehow derived from the "installation ID". Which is generated when you are installing the Master. Using a perl program with perl's rand() function - it is seeded from /dev/urandom reading 4 bytes from there.

    So if you want to be creative - recreate the whole process - run all possible 32 bit numbers, generate all 4 billion possible SolusVM installation IDs, generate all 4 billion possible ID/KEY pairs, try them.

This discussion has been closed.