Artificial truth

The more you see, the less you believe.

[archives] [latest] | [homepage] | [atom/rss]

Don't even try firstheberg
Sat 29 March 2014 — download

This is a cross post with fr33tux.org.

We wanted to try firstheberg VPS to run some Tor-nodes. This was a bad idea, for multiples reasons. We bought one of the cheapest ones, to play around, bench the bandwidth, check the CPU behaviour, ...

Default setup

The default system is awkward, with some gtk2-related files (libgtk2 is installed) in /etc, emacs, tex-mf, … 30 binaries are setuid, more than my desktop: awesome!

The setup pulls some files from this host, and adds a backdoor monitoring access. We installed Tor, sat a firewall up, and the relay started smoothly (with reasonable bandwidth limits). And then it went down.

Welcome to hell

We didn't hear anything from the support, nor got an email, or saw a notice on the website. Doesn't seems nice. We rebooted it. Approximatively three hours later, it went down again. Time to email the support. Maybe they detected the fact that we ran a Tor node and weren't happy with this? This is the answer we got:

The copy is over, I just rebooted your server

What the fuck are you talking about?! What copy? What were you doing to our VPS? And it went down. Again. This was becoming ridiculous. Once again, we emailed the support.

This one is on the login screen on the VNC console, could you give us the root password or log into it in order to let us verify its configuration without rebooting it?

This is insane. Maybe the support didn't get what the V letter stands for in VPS? Did they lost the password of the hypervisor? At this point, we abandoned the idea of using firstheberg for anything, and added it to our blacklist. We grabbed some popcorn, sat up a poor-man's keylogger, changed then gave the root password.

The holy-shit-batman-mayhem

The support installed tcpdump. I don't even know what to say. I mean, we are inside an hypervisor: they can monitor our traffic. Why the hell do they need to check it from inside our VM? Then, they checked if the ssh backdoor^wmonitoring key was still there, issued some bogus network commands, and then, the epic fail happened /etc/init.d/networking restart, and then a shitload of ^c and ^d.

The network is gone. The shell is gone. The VNC is gone. Aren't you supposed to help instead of locking us out of our machine?

Fr33tux was bitching about this on twitter, and surprise, he got an email .

FirstHeberg.com (@FirstHebergcom) a ajouté un de vos Tweets à ses favoris !

I rebooted the VPS, and it went online. Or was it? The super-siny-web2.0-half-working (I'm dead serious: The web interface is a piece of crap, and half of the links are not even working) interface doesn't even provides this indication: I don't care about your monitoring nor your about shiny graphes: Just tell me if the machine if off or on! This is completely wtf.

Everything is normal

Since it seems that the main way to get support is Twitter (emails are so 1990), we asked on it for a refund (And were to told to fuck off). We were told that the downtime was due to a scheduled maintenance, and that the support was informed.

Despite the fact that it's clearly written in the article 4.3 that they must inform the client of any deliberate downtime, we didn't get any email, nor did the support told us anything related.

The VPS is now online since 2 days, but for how long?

Conclusion

Don't go for firstheberg for anything serious. In fact, don't choose them for anything at all.

Bonus

  • They are running old and vulnerable versions of mediawiki, SMF, ...
  • People behind firstheberg have a nice website
  • You can scare your friends with their we-are-always-in-maintainance webpage.
  • Monitoring ?
  • Feel free to port-scan your server's gateway, and be amazed.
  • Their internal network is looking like a vulnerable pentesting lab.
  • Try to check if the domain <script>alert(1)</script> is available.