Hackers hacken klantensysteem alfahosting - alfanet

[krisken]

[mod=Dit is een oude thread, de informatie in de oude threads is niet meer up-to-date - kijk naar de datums van de posts.
Ondertussen heeft Alfahosting maatregelen genomen om de veiligheid op te krikken.

- Alle servers kregen nieuwe DDOS preventie.
- De klantenzone kreeg een update om lekken te dichten. Het lek dat werd uitgebuit bevond zich tevens in een vergeten bestand van een hele oude versie van de klantenzone.
- Meer gegevens werden gecrypteerd in de database (niet enkel betaalgegevens en wachtwoorden)
- Onze website, klantenzone en intern systeem draaien nu al voor een groot deel via beveiligde verbinding. Dit zal in de nabije toekomst nog uitbreiden naar andere delen van onze website.][/mod]

Meer informatie hier: Zie hier: http://userbase.be/forum/viewtopic.php?p=678421#p678421




http://pastie.org/pastes/9108681

http://news.softpedia.com/news/Hackers- ... 9364.shtml

http://www.hacksurfer.com/posts/belgian ... tomer-data

[cloink]

Ouch, pijnlijke affaire...

[Goztow]

Ik ben er reseller...

http://www.alfahosting.be/bericht/beric ... DG00000040

[degrotejan]

We zijn intussen vrijdag gepasseerd, en geen database dump te zien. Zou men dan toch toegegeven hebben aan die chantage?

[Flippi]

belsec.skynetblogs.be/archive/2014/04/25/alfahosting-is-playing-with-fire-and-your-security-what-happ-8172122.html

[Goztow]

ik ga al mijn eigen paswoorden veranderen. Maar wat raden jullie aan voor mijn klanten? Ik heb bijvoorbeeld een heel klein forum draaien.

[ Post made via mobile device ]

[krisken]

Goztow, misschien eens uitkijken naar een andere provider? En alvast alle wachtwoorden (ftp, mailboxen, etc) veranderen.

[Goztow]

Ik heb alle ftp en cpanel logins veranderd. Uiteindelijk niet zo moeilijk want ik heb slechts een 10 tal klanten. Ik ben er nu wel van overtuigd dat dit bij alle providers kan voorvallen. Maar hoeveel veiliger heeft alfa ondertussen hun systeem kunnen maken??? Daar heb ik wel twijfels bij.

Alle domeinnamen en websites overzetten is wel een heel groot werk .

[ Post made via mobile device ]

[Sparky]

We zijn intussen vrijdag gepasseerd, en geen database dump te zien. Zou men dan toch toegegeven hebben aan die chantage?

Op hun twitter account hebben ze links gepost met de namen van de klanten.

[Goztow]

Tof, de mijne staat er inderdaad in =/.

[bambipower]

Mijne ook

[krisken]

Ik heb alle ftp en cpanel logins veranderd. Uiteindelijk niet zo moeilijk want ik heb slechts een 10 tal klanten. Ik ben er nu wel van overtuigd dat dit bij alle providers kan voorvallen. Maar hoeveel veiliger heeft alfa ondertussen hun systeem kunnen maken??? Daar heb ik wel twijfels bij.

Alle domeinnamen en websites overzetten is wel een heel groot werk .

[ Post made via mobile device ]

Het kan uiteraard bij éénieder voorvallen, maar een selfmade iets is in mijn ogen altijd onveiliger dan iets dat je kan kopen of kan downloaden en door een grote massa gebruikt word. Fouten bij gekende pakketten voor klantenboekhouding worden precies sneller opgemerkt. Ergens logisch : als je éénmalig iets maakt en het zo laat omdat het werkt...tjah...

PS : bovenstaande is niet altijd 100% een failsafe gedacht!

Met welk CP werk je? Backups nemen etc en overzetten naar een andere provider met eenzelfde CP is niet zo moeilijk

[Loeri]

Ivm met security is het dan niet veiliger als ze hun database met klantengegevens local/offline beheren ipv online/public?

Lijkt mij toch veiliger maar ik weet natuurlijk niet hoe het er aan toe gaat in een hostingbedrijf..

[krisken]

Neen, want je wil natuurlijk dat je gebruikers alles live kunnen aanpassen zoals hun adres, telefoonnummer, pakketten die ze afnemen live upgraden/downgraden, ... Kortom allemaal zaken die je klant prettig vinden als ze het zelf kunnen aanpassen, en waarvoor alles publiek moet staan.

[Goztow]

Ik heb alle ftp en cpanel logins veranderd. Uiteindelijk niet zo moeilijk want ik heb slechts een 10 tal klanten. Ik ben er nu wel van overtuigd dat dit bij alle providers kan voorvallen. Maar hoeveel veiliger heeft alfa ondertussen hun systeem kunnen maken??? Daar heb ik wel twijfels bij.

Alle domeinnamen en websites overzetten is wel een heel groot werk .

[ Post made via mobile device ]

Het kan uiteraard bij éénieder voorvallen, maar een selfmade iets is in mijn ogen altijd onveiliger dan iets dat je kan kopen of kan downloaden en door een grote massa gebruikt word. Fouten bij gekende pakketten voor klantenboekhouding worden precies sneller opgemerkt. Ergens logisch : als je éénmalig iets maakt en het zo laat omdat het werkt...tjah...

PS : bovenstaande is niet altijd 100% een failsafe gedacht!

Met welk CP werk je? Backups nemen etc en overzetten naar een andere provider met eenzelfde CP is niet zo moeilijk

Maar lle domeinnamen staan netjes op naam van de klant. Die dus moet akkoord gaan met de overstap.

ik zou wel kunnen alfa vragen om hun dns te verwijzen naar een andere host, neem ik aan... maar dan blijf ik nog steeds klant bij hen.

[ Post made via mobile device ]

[Sub Zero]

Het kan uiteraard bij éénieder voorvallen, maar een selfmade iets is in mijn ogen altijd onveiliger dan iets dat je kan kopen of kan downloaden en door een grote massa gebruikt word. Fouten bij gekende pakketten voor klantenboekhouding worden precies sneller opgemerkt. Ergens logisch : als je éénmalig iets maakt en het zo laat omdat het werkt...tjah...

Niet noodzakelijk. Bij een bekend en veel gebruikt pakket zijn de zwakke plekken beter en sneller bekend. Als je niet regelmatig updates installeert, dan ben je een vogel voor de kat, want het aantal exploit-pogingen per uur zal vrij zichtbaar zijn. Als ik naar de apache logs kijk hier, dan is 't soms redelijk stevig

Als je een custom pakket gebruikt (zelfgeschreven of laten schrijven), dan moet de aanval ook bijna custom made zijn. Er moet dan al iemand zijn die de nodige kennis heeft en er zijn tijd en moeite wil in steken om de zwakke plekken te gaan aftasten. Waarbij in tegenstelling tot een bekend pakket er gewoon met een gigantisch kanon geschoten wordt en er hopelijk iets blijft plakken.

[proz]

@Goztow & bambipower

Kan je Twitter die account/post niet laten verwijderen ?

https://support.twitter.com/forms/abusiveuser

[krisken]

Het kan uiteraard bij éénieder voorvallen, maar een selfmade iets is in mijn ogen altijd onveiliger dan iets dat je kan kopen of kan downloaden en door een grote massa gebruikt word. Fouten bij gekende pakketten voor klantenboekhouding worden precies sneller opgemerkt. Ergens logisch : als je éénmalig iets maakt en het zo laat omdat het werkt...tjah...

Niet noodzakelijk. Bij een bekend en veel gebruikt pakket zijn de zwakke plekken beter en sneller bekend. Als je niet regelmatig updates installeert, dan ben je een vogel voor de kat, want het aantal exploit-pogingen per uur zal vrij zichtbaar zijn. Als ik naar de apache logs kijk hier, dan is 't soms redelijk stevig

Als je een custom pakket gebruikt (zelfgeschreven of laten schrijven), dan moet de aanval ook bijna custom made zijn. Er moet dan al iemand zijn die de nodige kennis heeft en er zijn tijd en moeite wil in steken om de zwakke plekken te gaan aftasten. Waarbij in tegenstelling tot een bekend pakket er gewoon met een gigantisch kanon geschoten wordt en er hopelijk iets blijft plakken.

Absoluut, maar patches en updates moet je toch altijd volgen? Schrijf je in op de nieuwsbrief van het gebruikte programma en je krijgt zelf een mailtje wanneer er een update uit is. Zelf een zelfgeschreven systeem heeft updates en patches nodig. Dus waarom het wiel opnieuw uitvinden (tenzij je echt zaken nodig hebt die custom zijn, dat is weer wat anders)

[degrotejan]

Laat ons wel wezen: uiteindelijk valt het hier nog mee. Uw adresgegevens staan op internet, dat is niet fijn, maar de financiiële data is teminste veilig gebleven. Al bij al een flauwe hack dus. En zo te zien ook ene zonder winst.

[Goztow]

Welke andere gegevens zijn ondertussen gepost?

[ Post made via mobile device ]

[bambipower]

en welke gegevens hebben ze nog achter de hand. Alfahosting beweert wel, dat het geen financiele gegevens zijn, maar moet je dat geloven?
Of weten ze het zelf wel?
Kwestie van informatie geven, blijven ze toch wel op de achtergrond

Beste klant

Om de veiligheid van uw gegevens blijvend te kunnen garanderen, voeren we een algemene reset uit van de wachtwoorden van mijn.alfahosting.be. We gebruiken nu namelijk een nieuwe vorm van encryptie voor uw gegevens. Deze extra beveiliging heeft niets te maken met de openSSL bug "Heartbleed" die eerder deze maand bekend gemaakt werd en momenteel zijn uw gegevens dus nog steeds veilig.
Onderaan deze mail vindt u uw nieuwe wachtwoord voor mijn.alfahosting.be. Voor uw websites of andere diensten die u bij ons ontneemt verandert er verder dus helemaal niets. Eenmaal aangemeld op mijn.alfahosting.be kan u uw wachtwoord nog steeds veranderen naar een ander wachtwoord naar uw voorkeur. Om u hier verder te helpen, ontvangt u alvast enkele tips voor een veilig wachtwoord.
- Maak gebruik van en hoofdletters en kleine letters en symbolen en getallen
- Vorm een eenvoudige zin om, door letters te veranderen in symbolen en cijfers
- Gebruik minstens 11 karakters
Een voorbeeld van deze tips zou kunnen zijn: Wij zijn klant bij AlfaNet. Omgevormd is dit dan: W1jZ1jnKl@ntB1jAl7@N€t

Uw nieuw wachtwoord: xXxxXXXxxxXXX

Vriendelijke groet

Het AlfaNet - Team

Ik lees dat er ook al nagegevens gelekt zijn, maar welke zijn dat? http://www.webhostingtalk.nl/bedrijfsvo ... z306B0zJeC

[Flippi]

Tof, de mijne staat er inderdaad in =/.

De mijne ook, maar die staat ook op mijn website en op infobel, etc....
M.a.w. als het daar bij blijft, dan kan ik er nog mee leven.

[meon]

- Vorm een eenvoudige zin om, door letters te veranderen in symbolen en cijfers
- Gebruik minstens 11 karakters
Een voorbeeld van deze tips zou kunnen zijn: Wij zijn klant bij AlfaNet. Omgevormd is dit dan: W1jZ1jnKl@ntB1jAl7@N€t

Lettersubstitutie is een slecht idee omdat de meeste brute force-attacks daar rekening mee houden. Wachtwoorden horen random te zijn. De veiligheid in dit voorbeeld ontstaat door de lengte van het wachtwoord.

[krisken]

Klopt!

Beter is om een zin te nemen en daar de eerste letters van te nemen.

Ik woon in 2010 Antwerpen, in de Koestraat nummer 8! kan dan worden

20IwidKn810!

Of iets in die aard

[ubremoved_15739]

Of je genereert een "strong/secure password": Secure Password Generator.

[offtopic]
Hoeveel van de paswoorden hier op Userbase zou men kunnen beschouwen als strong/secure?
Misschien een admin die dit kan aangeven?
[/offtopic]

Doch de belangrijkste vraag is of het gebruikte lek ook gevonden is (en verholpen).
Anders kunnen klanten hun paswoorden (nodeloos) blijven veranderen...

[ITnetadmin]

Als een admin dat hier kan aangeven, hebben we een serieus probleem, want dan worden de paswoorden in cleartext bewaard.
Vermoedelijk worden de paswoorden hier gewoon als hash bewaard, al dan niet met een unieke salt.

[Goztow]

phpbb hasht standaard. alfahosting trouwens ook blijkbaar.

[ Post made via mobile device ]

[ITnetadmin]

Een hash is uiteraard enkel een rudimentaire bescherming, die het paswoord onleesbaar maakt en dus moeilijk te achterhalen, maar uiteraard niet onmogelijk. Hopelijk waren de paswoorden gesalt.

Voor de leken: een salt betekent een paswoord voorzien van een extra set karakters, uniek per paswoord, zodat 2 identieke paswoorden toch voor verschillende hashes zorgen, en de hacker zijn password tables op elk paswoord afzonderlijk moet laten berekenen.
De salt is zelfs geen "cryptographic secret", wordt gewoon in de DB bij de password hash bewaard, en dient enkel als bemoeilijking door alle hashes uniek te maken.

Maw: ELKE internet service die je je paswoord toestuurt als je op "forgot pwd" klikt bewaart dit paswoord dus in cleartext, en is te vermijden. Een betere service zal met een link met tijdelijk token werken. (Enfin, "beter", een "forgot pwd" knop is als de zwaarbeveiligde voordeur op dubbel slot doen maar de sleutel van de lichte achterdeur onder de mat leggen)

[ Post made via mobile device ]

[ubremoved_15739]

Allemaal goed en wel.
Doch indien ik op userbase inlog via http://userbase.be (poort 80) gaat mijn username en paswoord ook als clear tekst naar de webserver van userbase.

Wat mij betreft verhouden http en https zich zowat als telnet en ssh...

Ook bij alfanet/alfahosting laat men (ook heden) de klanten toe om op hun cpanel te connecteren:

• poort 2082: clear tekst
• poort 2083: ssl

Poort 2082 zou men al beter niet meer toelaten. En dan begint natuurlijk het hele verhaal over certificaten.

Misschien moeten we hen eens een distributie van BackTrack / Kali of zo opsturen.

[Sub Zero]

Allemaal goed en wel.
Doch indien ik op userbase inlog via http://userbase.be (poort 80) gaat mijn username en paswoord ook als clear tekst naar de webserver van userbase.

https://userbase.be werkt ook hoor. We enforcen het alleen niet.

[ubremoved_15739]

Ja, dat weet ik.
Maar vindt je het zelf niet beter over ssl?
Voor al je gebruikers?
Altijd?

[Sub Zero]

De reden dat ik het niet van de eerste keer aangezet heb voor iedereen is omdat ik eerst wou afwachten wat de implicaties waren qua server load enzo. Nadien blijkt het allemaal wel mee te vallen, dus misschien moeten we dat maar gewoon doen. Het is er alleen nog niet van gekomen.
Net na het invoeren heb ik eens wat stats bekeken en liep ongeveer 10-15% via https. 'k Zal het nog eens herbekijken

[bambipower]

overschakelen zal ook nadelen hebben: zoals resultaten die (tijdelijk) verdwijnen in google

[_ketter_]

wat betreft wachtwoorden er dergelijke zorg ik er altijd voor dat voor sites die onvoldoende beveiligd zijn, zoals bv. userbase (login over https niet afgedwongen), het kraken van het wachtwoord geen impact heeft voor andere sites.

gewoon een uniek wachtwoord gebruiken, het hoeft niet eens complex te zijn want dat maakt uiteindelijk niet zoveel uit.

[Kenw00t]

Allemaal goed en wel.
Doch indien ik op userbase inlog via http://userbase.be (poort 80) gaat mijn username en paswoord ook als clear tekst naar de webserver van userbase.

https://userbase.be werkt ook hoor. We enforcen het alleen niet.

Vreemd, ik gebruik nochtans HTTPS Everywhere en userbase is de enige website die hij blijkbaar niet naar HTTPS kan forceren.

[Loeri]

Vreemd, ik gebruik nochtans HTTPS Everywhere en userbase is de enige website die hij blijkbaar niet naar HTTPS kan forceren.

Wanneer je op userbase.be zit moet je de extensie/app openen en add this site klikken.

[FunkStar]

In versie 3.5.1 (stable) heb je geen add knop.
Regels kan je zo te zien ook niet meer aanpassen.

[Loeri]

Ik gebruik enkel de beta voor google chrome en hier krijg ik wel 'add this site': https://www.dropbox.com/s/bzl5b7wp5qj4y ... .04.47.png

[Goztow]

Officiële reactie alfanet:
http://www.tijd.be/nieuws/ondernemingen ... anet&ckc=1

Antwoord op een mail van mij gaat in dezelfde zin.

[freebymusic]

Hallo iedereen

Ik merkte dat er heel wat onduidelijkheid nog was over wat er juist gebeurt is.

De hacker had een deel gegevens vastgekregen. Dit was geen gevoelige informatie (betaalgegevens, wachtwoorden,...)

Hiernaast bewaren wij zelf de logingegevens van de technische controlepanelen niet waardoor deze niet achterhaald konden worden. In het bericht verwijst Dhr. Ales naar de websites verder beveiligen. In eerste plaats is dit naar Open source CMS systemen. We zijn voorstanders hiervan maar deze dienen goed up to date gehouden te worden om alle veiligheidslekken te dichten.

Het zijn namelijk deze lekken die de meeste problemen veroorzaken. SPAM mailings en DDoS zijn de meest voorkomende problemen die eenvoudig te voorkomen zijn met deze updates.

Als er verder nog iemand vragen heeft over de veiligheid van de server of zijn/haar webruimte mogen ze steeds mailen naar [email protected] of eens inbellen naar +32. 13 555 387.