Backdoor gaf toegang tot gegevens van forumleden scholieren.com

De website scholieren.com, waar informatie en een forum voor jongeren te vinden is, waarschuwt zijn gebruikers dat er mogelijk onbevoegd toegang is geweest tot gegevens als gehashte wachtwoorden, e-mailadressen en gebruikersnamen.

Het forum van de website heeft een kleine 150.000 leden. Oprichter Jon Geerars geeft tegenover Tweakers uitleg over het lek: "Op 7 augustus kwamen we ineens een php-bestand tegen in een map met afbeeldingen. Het bleek dat iemand een backdoor had geüpload via de uploadfunctie voor plaatjes."

Het lek is inmiddels gedicht, maar de backdoor zou een aantal keer benaderd zijn. In een mail aan gebruikers schreef Geerars dat er niet uitgesloten kan worden dat er toegang tot gevoelige gegevens is geweest.

Geerars zegt dat de wachtwoorden wel gehasht waren met de standaardinstelling van php, maar kon niet zeggen met welk algoritme. Vanaf versie 5.5 is dat het als veilig aangemerkte bcrypt-algoritme. Of dat hier ook is toegepast, is onduidelijk.

In de mail naar gebruikers waarschuwt de site om het wachtwoord van scholieren.com aan te passen op andere sites als het daar ook is gebruikt. Gebruikers van de site zal bij een nieuwe inlogpoging gevraagd worden hun wachtwoord aan te passen. Volgens Geerars is er inmiddels melding van het incident bij de Autoriteit Persoonsgegevens gemaakt.

Reacties (84)

[Ryan_]

Dat soort bestanden sluit je toch als eerste uit wanneer je een uploadscript hebt draaien?

[Sito]

Sterker nog, met een image-upload functie sta je maar een paar extensies toe en de rest niet.

Scholieren.com is best een grote site en ik vind het schandalig dat je een backdoor kon creëren door simpelweg en PHP-scriptje te uploaden. Dat maakt het wel heel simpel.

[sir_huxley]

Extensie check maakt het niet veilig en kan makkelijk omzeild worden.
De enige manier om een upload veilig te maken is door een bestand te kopiëren naar een dir die niet van buitenaf benaderbaar is. Het beste nog vanaf een server die enkel static content kan weergeven.
Vervolgens dien je het plaatje dan via een bijvoorbeeld file_get_contents in te voegen.

[Sito]

Uiteraard. Maar stap 1 is toch om die extensies te blokken.

[m8ZBm1Si]

Ik vermoed dat ze dat hier ook gewoon hebben gedaan. Zo simpel zal het niet geweest zijn.

Stap 1 is natuurlijk een bestaande oplossing hiervoor te zoeken en niet zelf iets in elkaar te gooien.

[BLACKfm]

Dus als één of andere hacker (Wat de gebruiker dan vervolgens niet weet) een scriptje online gooit en jij gaat dat downloaden (or for that matter ieder script wat je van het internet trekt) en je weet van de helft niet wat het doet, anders dan als je het implementeerd in je website dat je moet inloggen er er gegevens in een database worden geschreven/gechecked, dan is het wel goed?

Dan kun je wat dat betreft beter zelf 'iets in elkaar gooien' waarvan je in ieder geval weet wat het doet omdat je het zelf gebouwd hebt. Zo weet je in principe ook je eigen zwakheden in het systeem en bouw je daar (indien je daar aandacht aan besteed) ook een goede beveiliging voor.

[yamitenshi]

Dus als één of andere automonteur (Wat de chauffeur dan vervolgens niet weet) een bom in een bestelbus legt en jij gaat daarin rijden (or for that matter iedere auto waar je in stapt) en je weet van de helft niet wat het doet, anders dan als je er in zit dat je moet tanken en je dan naar Amsterdam kunt rijden, dan is het wel goed?

Als jij alles zelf wil gaan bouwen is dat prima, maar dit soort denkbeelden zijn wel waarom er zo veel bagger online staat. De collectieve community weet een stuk meer dan jij alleen. Misschien ben jij natuurlijk die ene meesterdeveloper die geen fouten maakt en elk aspect van het internet compleet doorgrond heeft, maar voor de meeste van ons normale stervelingen geldt dat helaas niet.

Soms kun je iets beter aan een ander overlaten, in plaats van het zelf bij elkaar te harken. Sommige problemen zijn nou eenmaal al honderden keren opgelost, door mensen die een stuk betere code schrijven dan wij beiden bij elkaar, en worden continue onderhouden door een groter aantal developers dan bij welk bedrijf dan ook werkt.

Je downloadt niet zomaar het eerste het beste script van het internet om het vervolgens in je site te hangen, je denkt na bij wat je doet en kiest voor oplossingen die vaker gebruikt en actief onderhouden worden. Dat geldt voor beveiliging niet anders - je eigen beveiliging bouwen is de beste manier om je applicatie zo lek als een zeef te krijgen.

[mysticyx]

Dus als één of andere automonteur (Wat de chauffeur dan vervolgens niet weet) een bom in een bestelbus legt en jij gaat daarin rijden (or for that matter iedere auto waar je in stapt) en je weet van de helft niet wat het doet, anders dan als je er in zit dat je moet tanken en je dan naar Amsterdam kunt rijden, dan is het wel goed?

Nee dan is het niet goed, en dat was precies zijn punt.

[yamitenshi]

En ga je dan maar je eigen auto bouwen zodat je weet wat er in zit?

[mysticyx]

Dat kan je toch beter doen dan in een auto rijden waar de monteur een bom in heeft gelegd!

Als jij kon kiezen; rijden in een auto met bom of er zelf een bouwen, wat zou jij dan doen?

Ik bedoel alleen maar, je vergelijking slaat nergens op.

[BLACKfm]

Wat mysticyx dus zegt én je hoeft het niet nog een keer uit te leggen want het principe blijft hetzelfde, maar de vergelijking is een beetje uit verhouding.

En ik weet ook niet alles, maar tussen alle 'bagger' die online staat zijn er ook genoeg vraagstukken van mensen "Het werkt wel, maar ik wil eigenlijk ook dit of dat in het script hebben". Dan wordt het letterlijk een geval 'klok en klepel'.
Het is wel fijn dat je de taal een beetje kunt spreken, of in dit geval kunt lezen en schrijven, voordat je allemaal scripts van het internet plukt die mogelijk al vele jaren geleden zijn ontworpen en intussen niet meer helemaal veilig zijn.

Bijvoorbeeld scripts die met oudere 'MySQL' code niet meer werkt en het tegenwoordig 'MySQLi' moet zijn als je php versie een beetje bij de tijd is. (waarschijnlijk in mijn geval ook een geval 'klok en klepel', maar daar liep ik laatst nog tegen aan met oude projecten).

En hoe moeilijk kan een upload script tegenwoordig nou zijn. Er zijn 1000-en varianten te vinden, maar als daar 1% een beetje degelijk beveiligd is dan is het veel.

[m8ZBm1Si]

Zomaar een ongerelateerde vraag: Schrijf je je code volledig zelf (plain php) of gebruik je een framework / wordpress / etc. ?

[BLACKfm]

Niet dat ik het elke dag doe, maar ik schrijf het liever helemaal zelf ja. Maar dat is dan voornamelijk om de reden dat ik een standaardoplossing dan niet 'begrijp'. Ik soms websites voorbij komen dat ik denk 'Dat kan in een uurtje met kladblok in elkaar gepoets worden' en er hangt een website achter van 50mb voor 10 pagina's tekst.

En omdat ik dan precies weet wat ik gebruikt heb kan ik ook onderbouwd aangeven welke functies er in zitten en hoe lastig iets is om toe te voegen. Bij een standaard pakket (wat je op een gegeven moment ook van voor naar achter kent natuurlijk) ben je soms uren aan het zoeken waar je precies moet zijn, als je het dan al goed kunt aanpassen zonder dat je iets anders weer sloopt.

[xiphoid]

Het idee dat zelf schrijven een oplossing is omdat er geen bekende exploits voor zijn, wilt niet zeggen dat developers met 15+ jaar ervaring in hun pakket wel of niet beter zijn ivm privacy/security voor de php software.

Een nieuwe versie van PHP kan nieuwe problemen blootleggen en die komen wel naar voren. En als iemand je site target, dan is een fuzzing process op je data input iets waar ze met net zoveel kans (al niet meer) bugs kunnen vinden die dingen doen die jij niet had voorzien tijdens het even snel in elkaar gooien van je eigen complete forum pakket. Voordeel van ervaring is dat jaren lang proben en vinden van exploits en bugs door derden (en je eigen team) je de bekende problemen wel al gepatched hebt. jij stopt focus op je nieuwe eigen software en wilt avatar support en maakt dezelfde fout waarschijnlijk dat met malformed header bij uploaden van avatar jouw eigen software die code uitvoert. Je focus was op beveiligd uploaden van een image zodat er avatars waren en schiet eventueel validation er in..

Ik heb hoofdpijn, uit mijn woorden komen is beetje lastig, sorry als het slecht nederlands is.

Maar, mijn punt is, Als je het zelf schrijft wilt niet zeggen dat er geen bugs in zitten.

[yamitenshi]

We zijn inmiddels alweer aangekomen bij PDO

Anyway, een basaal uploadscript is supersimpel. Bestandje pakken, wegschrijven, klaar. Maar beveiliging blijft een complex probleem.

Je kan alleen maar valide bestandsextensies toestaan, maar dat houdt mij niet tegen om een PHP bestand een andere extensie te geven.

Je kan checken of je plaatje echt een plaatje is, maar dat weerhoudt mij er niet van om er dan maar PHP code achteraan te plakken.

Je kan kijken of je een plaatje fatsoenlijk kan resizen, maar dat weerhoudt mij er niet van PHP in de metadata te stoppen.

Stiekem wordt je simpele uploadscript dus al snel vrij complex. De oplossing? Zoek iemand die dat al eens gedaan heeft, en goed gedaan heeft. Open-source heeft zijn voordelen - het is namelijk verrassend makkelijk om eens rond te vragen welke 1% van die 1000-en varianten dan een beetje degelijk beveiligd is. Oh, en configureer je webserver goed - dan was heel het uploadscript nooit een probleem geweest.

Security is juist een hele goede reden om niet alles zelf te gaan bouwen, maar een framework te gebruiken dat het overgrote deel op een fatsoenlijke manier voor je doet. Dan hebben we het niet alleen over uploads, maar ook bijvoorbeeld database-interacties, want voor simpele applicaties schrijf ik echt mijn eigen queries niet meer.

Alles zelf bouwen "omdat je dan tenminste weet wat het doet" is waarschijnlijk precies hoe deze ellende ontstaan is. En als het in dit geval niet zo is, dan zijn er talloze gevallen waarin dat wel geldt. Maar zoals ik zei, als jij alles zelf wil bouwen, ga vooral je gang.

[janw.oostendorp]

-

[Reactie gewijzigd door janw.oostendorp op 28 juli 2024 14:11]

[sir_huxley]

De extensie gebruik je enkel om het bestand op te slaan voor toekomstige weergave.
Niet voor controle.

Een oude post maar nog zeker nuttig:
http://web.archive.org/we...d-in-php-web-applications

[hellfighter87]

Ik ben het met je eens dat die images op een remote server horen te staan die ook alleen images snapt.
Echter 20 images ophalen via file_get_contents en ze dan inline injecten in je html maakt het niet echt snel.

[sir_huxley]

Indien je veel plaatjes hebt zou je inderdaad beter op een static content server kunnen plaatsen nadat ze veilig zijn bevonden.

De manier die ik beschrijf is als volgt

originele naam is test1.jpg
originele naam is test2.jpg

wordt opgeslagen onder in db met als veld
id:1000,filetype:jpeg
id1001,filetype:gif

daarna wordt die weeregeven via:
view.php?id=1000
view.php?id=1001

ipv
test1.jpg
test2.gif

op die manier kun je nog steeds meerdere bestanden gelijktijdig ophalen.

[Diamondo25]

En weet je wat je dan krijgt? XSS . Zoals bij imgur gebeurde

[Maikie18]

De enige manier om een upload veilig te maken is door een bestand te kopiëren naar een dir die niet van buitenaf benaderbaar is.

Kun je kort omschrijven hoe je zoiets voor elkaar kunt krijgen? Want die server die van buitenaf benaderbaar is zal toch bij die directory moeten kunnen en dus wellicht zal die directory dan ook op een of andere manier dan weer benaderbaar zijn van buitenaf

[sir_huxley]

Door de directory waar de plaatjes staan buiten de root te plaatsen

voorbeeld:
d:\webserver\www\
zet heb dan bijvoorbeeld in
d:\pictures
Als je het plaatje dan wilt tonen zet je eerst de content header in php/asp/etc
daarna laadt je het plaatje in via file_get_contents of vergelijkbaar.
zie eerder genoemde link
http://web.archive.org/we...d-in-php-web-applications

[faim]

Bestanden tonen doormiddel van een PHP-script is ontzettend traag en onnodig.
Gewoon zorgen voor de juiste rechten op de upload map en bestand, en de juiste configuratie van de webserver, dan is er niks aan de hand.

[sir_huxley]

Dat is niet correct! op die manier kun je nog gewoon een javascript file injecteren die vermomd is als plaatje. Het is dus niet enkel de rechten aanpassen, er komt heel wat meer bij kijken. Het tonen van plaatjes via PHP hoeft niet traag te zijn bij gebruik van een cache.

[Feanathiel]

Zolang je gebruik maakt van sessies, kan er maar een enkel verzoek tegelijkertijd worden afgehandeld. Je zult dus moeten wachten tot de gehele afbeelding binnen is voordat je pas met de volgende verder kunt. Statische content heeft dat limiet vaak niet.

[faim]

Dat is zeker wel correct!
Een browser zal nooit Javascript uitvoeren waarvan het MIME-type niet gelijk is aan dat van een script, dus dat gaat al helemaal niet op.

Je verzoek gaat alsnog door de PHP-module, dus dat zal altijd een stuk trager zijn dan dat het alleen door de webserver gaat, ook al doet het PHP-script verder niks.

[beerendlauwers]

Precies, in de .htaccess van de upload directory (als je Apache draait) gwn de PHP engine uitzetten

[Verwijderd]

Extensies hebben nauwelijks betekenis buiten Windows/DOS.

Fout 1 is dat de gebruikte directory PHP en/of executie rechten heeft. Dat mag nooit voorkomen. Alleen scripts in specifieke directories mogen uitvoerbaar zijn. Andere directories niet, en upload of anderszins openbaar beschrijfbare directories al helemaal niet.

Fout 2 is dat er inderdaad gecontroleerd moet worden of iets wel echt een afbeelding is. Niet op basis van extensie, maar door een image parser die de afbeelding daadwerkelijk begrijpt. (Sowieso zinvol - dan kun je meteen de resolutie controlen en eventueel scalen, etc.)

[Patriot]

Extensies hebben nauwelijks betekenis buiten Windows/DOS.

Dat valt op zich ook wel weer mee. Sowieso gebruiken de gangbare webservers de extensie wel om te kijken wat ze moeten doen als een bepaald bestand wordt opgevraagd (bijv. doorsturen naar de PHP interpreter).

[Joen]

Volgens mij kijken de meeste webservers gewoon naar het MIME type en niet naar de extensie.

[Patriot]

Nouja, de gangbare webservers die ik heb gebruikt (Apache en Nginx) doen het op basis van extensie. Op basis van MIME is ook gewoon lastig, een PHP-bestand wordt bijvoorbeeld niet zomaar als zodanig herkend als het bestand niet begint met de PHP openingstag.

[CARLiCiOUS]

Fout 2 is dat er inderdaad gecontroleerd moet worden of iets wel echt een afbeelding is. Niet op basis van extensie, maar door een image parser die de afbeelding daadwerkelijk begrijpt. (Sowieso zinvol - dan kun je meteen de resolutie controlen en eventueel scalen, etc.)

Dat is een heel gevaarlijk advies. Een valide jpeg image kan gewoon php code bevatten (in de exif-data, of in de body zelf, maakt niet uit, zolang het tussen <?php ?> staat). Als je de server zover krijgt om dat als .php op te slaan wordt het gewoon uitgevoerd.

Het is juist cruciaal om goed op te letten naar onder welke extensie je het bestand opslaat. Dat moet je absoluut whitelisten en niet gaan knoeien met blacklists. Een paar voorbeelden.
- Stel je filtert op .php extensie, dan upload je als .PHP of .php5 -> code execution.
- Stel je staat .rar toe, dan upload je het bestand met een .php.rar extensie. Apache kent de .rar extensie niet, en om een of andere reden kijkt apache in dat geval naar de een na laatste extensie. Voila .php -> code execution.
- In oudere php-versies (weet niet precies wanneer dit gefixt is) kon je bestandsnamen met een NULL-byte erin uploaden. Dus bijvoorbeeld "bestand.php\x00.jpg" Je code checkt de extensie: .jpg, mooi, en schrijft hem weg onder bijvoorbeeld "/var/www/html/uploads/bestand.php\x00.jpg". Dat gebeurt via low level C, waar strings worden getermineerd met een NULL-byte. Oeps, het bestand wordt dus weggeschreven in "/var/www/html/uploads/bestand.php" -> code execution.

Geloof me, je wil bestandsnamen gewoon random genereren en er alleen .jpg, .png of .gif achter plakken (op basis van gedetecteerd imageformaat of whatever). Dat scheelt je enorm veel hoofdpijn.

[Verwijderd]

Extensies zijn irrelevant. Geüploade bestanden mogen nooit uitvoerbaar zijn. Zie Fout 1.

[CARLiCiOUS]

Extensies zijn zeker wel relevant. Elk leesbaar bestand met een .php extensie (met of zonder executie rechten) wordt gewoon uitgevoerd door mod_php. Je moet php expliciet uitzetten voor een bepaalde subdirectory. Hoe je dat doet verschilt per webserver en vaak heb je de rechten niet (denk aan shared hosting). Dit zal je dus gewoon moeten oplossen met de juiste extensies.

Maar zelfs met een uploads directory waarbij php uitstaat, kan je nog steeds .html of .js plaatsen, en heb je een xss. Niet zo erg als code execution maar absoluut niet wenselijk.

[Verwijderd]

Je creëert problemen waar ze niet hoeven zijn. Standaard PHP aanzetten op alle directories om ze vervolgens selectief uit te zetten is de wereld op zijn kop.

[RobinJ1995]

Dat is waarschijnlijk net wat er gebeurt is... enkel extensie gecheckt.

[NicoJuicy]

Kan omzeild worden https://null-byte.wonderh...-root-rfi-part-1-0162818/

[Verwijderd]

Waarom is dit überhaupt mogelijk? Want zo creëer je echt een gigantisch beveiligingsprobleem als je niet ieder plaatje opnieuw verwerkt. Goed dat ik weet in ieder geval.

[Reactie gewijzigd door Verwijderd op 28 juli 2024 14:11]

[Patriot]

Dat is vrij dubieus, dat werkt alleen bij een bijzonder brakke configuratie.

[Bender]

Er wordt van uit gegaan dat beveiliging door de software vBulletin ingeregeld wordt, maar dat is mogelijk niet het geval.

[Anonymoussaurus]

Geerars zegt dat de wachtwoorden wel gehasht waren met de standaardinstelling van php. Vanaf versie 5.5 is dat het als veilig aangemerkte bcrypt-algoritme.

Heel erg onduidelijk. Wat is er nou gebruikt? 5.5 of een versie ouder? Maakt nogal een groot verschil dus. Ervan uitgaande dat de standaardinstelling is gebruikt, is het dus gehasht met MD5, SHA256, of haval160,4, aldus deze site: http://php.net/manual/en/function.hash.php

[Reactie gewijzigd door Anonymoussaurus op 28 juli 2024 14:11]

[hackerhater]

Het is wel dat PHP het gebruik van Bcrypt ten zeerste aan raad.

[Anonymoussaurus]

Ja, maar dat maakt geen hol uit als ze het toch niet gebruiken. Ze zeggen dat het is gehasht met de standaardinstellingen van PHP. Zoals het overkomt, doen ze nogal geheimzinnig over welke versie ze gebruiken, waardoor het dus onduidelijk is welke hashing zij gebruikte/gebruiken.

[latka]

Ze gebruiken VBulletin 3.8.8. Erg upgraderig zijn ze dus niet. Die versie komt ergens uit 2006. PHP5.5 is van 2013. Tenzij ze alle paswoorden eerder gereset hebben is het niet waarschijnlijk dat BCrypt gebruikt is (nb. puur even gekeken naar de versies en de release dates op basis van het non-antwoord van de eigenaar).

[Anonymoussaurus]

SHA256 is nog wel te doen, maar MD5 wil je echt niet hebben.. Het is of SHA256 met salt, óf bcrypt.

[latka]

Uit forumposts uit 2006:

$password_hash = md5(md5($password_text) . $user_salt);

Ik ben bang....

Update: bcrypt vanaf VBulletin 5. Even updaten dus.

[Reactie gewijzigd door latka op 28 juli 2024 14:11]

[Wasrek]

Zojuist de proef op de som genomen: Ik blijk sinds 2008 niet meer ingelogd geweest te zijn en kan met mijn standaardwachtwoord uit die tijd gewoon inloggen. Met andere woorden: In ieder geval een deel van de wachtwoorden is waarschijnlijk met een oud algoritme opgeslagen.

[duqu]

Klopt, ik heb eraan toegevoegd dat hij zelf niet wist welk algoritme er was gebruikt.

[Anonymoussaurus]

Top, bedankt . Dacht ook al dat het communicatiefout was aan de woordvoerder en niet bij jou.

Vind het overigens wel vreemd dat de oprichter (!) niet eens weet over hoe z'n eigen website wordt beveiligd (of naja, de gegevens dan).

[Reactie gewijzigd door Anonymoussaurus op 28 juli 2024 14:11]

[biglia]

Zo vreemd is dat toch niet? Misschien is de oprichter niet (meer) de persoon die het technisch allemaal in goede banen leidt. Mijn baas weet ook geen enkele technische details, maar kan wel het bedrijf succesvol runnen.

[Anonymoussaurus]

Weet ik, maar tegelijkertijd is hij in dit geval ook de woordvoerder. Dan zou je echt de details wel moeten weten als de pers/media om details vraagt. Desnoods bel je even snel met de IT-afdeling om wat vraagjes te stellen.

[Verwijderd]

Je hebt functies zoals password_verify denk dat ze die bedoelen, crypt or hash is not safe voor passwords

[AW_Bos]

En als je slim bent zet je zelfs execute-rechten op die directory uit....

[Patriot]

Die heb je niet nodig voor om een PHP-script in die map te laten draaien, daar heb je alleen leesrechten voor nodig.

[AW_Bos]

Hm.... dat is waar. Tenzij je de CLI gebruikt, geloof ik. Anders moet je met directives in virtual hosts de boel afschermen.

[Reactie gewijzigd door AW_Bos op 28 juli 2024 14:11]

[Patriot]

Hm.... dat is waar. Tenzij je de CLI gebruikt, geloof ik.

Volgens mij niet hoor. Het script wordt voor wat het systeem betreft niet uitgevoerd, alleen gelezen.

Anders moet je met directives in virtual hosts de boel afschermen.

Yup. Idealiter zet je het op een locatie waarbij de kans ook zo klein mogelijk is dat er in de map waar de bestanden staan alsnog PHP-scripts uitgevoerd kunnen gaan worden.

[yamitenshi]

Ook als je de CLI gebruikt heb je aan leesrechten genoeg, als je maar execute rechten hebt op de PHP interpreter.

[Verwijderd]

Ik wil je tegelijkertijd een +1 en een -1 geven. De beste oplossing is natuurlijk: execute standaard uit, en alleen specifiek aanzetten op directories waar dat noodzakelijk is.

[ExIT]

<Directory /path/to/dir>
Order allow, deny
Deny from all
php_admin_flag engine off
</Directory>

[Reactie gewijzigd door ExIT op 28 juli 2024 14:11]

[DJMaze]

Ik heb vernomen dat het lek NIET in vBulletin zit en dat vBulletin gepatcht is.

[Bender]

Bron?

[DJMaze]

Ja die heb ik, die mag @duqu aan mij vragen

[duqu]

Ben benieuwd! Graag wel via een dm dan

[xiphoid]

Versie 3.8 van vBulletin is wel enorm oud ondertussen, en met de fouten die al jaren bekend zijn is het ook niet echt een verrassing. PHP object injection, faq.php die mysql database gegevens weergeeft, CVE-2016-6483, etc. AvatarSQLInject, etc.

[AW_Bos]

Waar baseer je op dat ze die versie draaien?

[Phyxion]

<meta name="generator" content="vBulletin 3.8.8" />

Staat gewoon in de source. Dik 3 jaar oud. Echter worden er ook security patches uitgebracht voor 3.8.8 dus als ze dat nou in ieder geval updaten dan is het niet zo'n ramp. Maar ja, dat weet je niet

[AW_Bos]

Maar dat is geen sluitend bewijs, dat ze een oude vBulletin draaien.
Tegenwoordig is het al erg dom als ze versienummers van software in de source plaatsen. Daar heeft een gebruiker niks aan, en het hoort dan ook in het Admin-paneel.

[Phyxion]

Jawel, dan wordt de generator aangepast.
Het is gewoon 3.8.8, en dat kan je o.a. ook gewoon hier bekijken:
https://forum.scholieren.com/modcp/
of
https://forum.scholieren.com/admincp/
Hover maar over het logo heen.

Daarnaast heeft 3.8.8 gewoon security updates ontvangen. Zie ook hun website of hier.

[Reactie gewijzigd door Phyxion op 28 juli 2024 14:11]

[xiphoid]

Omdat hun bestanden en css en js en andere files allemaal 3.8.8 zeggen.

[AW_Bos]

Of het is een templateset die overgekopieerd is uit oudere versies.
Ik neem aan dat ze geen oude vBulletin hebben draaien. Dan waren ze nu allang het haasje geweest met die hack-botjes op het internet, en hadden ze inmiddels lering getrokken uit hun fouten.

[Reactie gewijzigd door AW_Bos op 28 juli 2024 14:11]

[xiphoid]

Waarom zou je oudere javascript voor de engine gebruiken, alle public readable files met vb header heeft 3.8.8 in de header.. Maar goed, als je zo nodig tegen wilt werken, dan draaien ze versie 5 voor mijn part, die is net zo lek. Ik ga hier echt geen discussie van maken hoor. Er is geen bewijs dat het niet 3.8.8 is, er is wel duidelijk meerdere aanduidingen dat het wel 3.8.8 is. Zelfs renamed .php files, upgrade files, xml packs, etc, alles heeft de 388 tag

[AW_Bos]

Elders is het e.e.a hier al bevestigd hoor dat ze oude meuk lijken te draaien
maar 100% zekerheid heb je niet, tenzij je de code in kan kijken

[Reactie gewijzigd door AW_Bos op 28 juli 2024 14:11]

[xiphoid]

Ik heb jaren tech support voor vB gedaan, ik denk dat ik wel weet in welke files ik kijken kan ..

[AW_Bos]

Hopelijk niet in de PHP-source

[xiphoid]

Ik had het over js/css etc files, https://forum.scholieren.com/archive/archive.css
https://forum.scholieren....vbulletin_global.js?v=388

sorry dat het je nog niet duidelijk was na enkele posts.

[AW_Bos]

Ik geloof er na een optelsom nu meer van dat ze daar oud spul draaien. Echter vraag ik me af waarom ze niet updaten? Lijkt mij toch dat je een updates blijft krijgen met je abonnement?

[xiphoid]

Omdat vBulletin na aankoop van IB echt wel stuk meer crap is geworden, en updaten nou geen garantie meer geeft. Veel oude bekenden van vBulletin sites die er al 10+ jaar zijn, zijn blijven hangen op versie 3 en vonden versie 4 niet wat vB ooit was (en zeker niet zo goed). En upgraden van 10+ jaar oude communities naar bijvoorbeeld XenForo (van Kier/Ashley/Mike die ook vBulletin 3 gemaakt hebben) is echt wel een hele klus dan die veel mensen niet willen ondernemen.

[ExIT]

Ja. En niet alleen op basis van extensie, je stopt ook het kunnen uitvoeren van scripts in bepaalde mappen.

[Oerdond3r]

Vind dat de oprichter ontzettend eerlijk is over wat er precies gebeurd is. Of hij heeft niet door dat het lek in zijn website vrij makkelijk te verhelpen was en had de hack daadwerkelijk niet zien aan komen. Of hij heeft wel door dat het niet slim in elkaar zat maar is er gewoon alsnog eerlijk over.

User generated content moet je gewoon altijd zelf serveren dmv een php script ( die ook de authenticatie en authorisatie voor een bepaald bestand kan checken bv ). In het ergste geval wordt het php script gedownload ipv uitgevoerd omdat je het Apache/Nginx liet serveren.

Static serveren kan ook, door het op een andere server te zetten of je Apache/Nginx ervoor in te stellen.

Een les die ik dankzij dit artikel nog eens goed in mijn achterhoofd knoop

[Reactie gewijzigd door Oerdond3r op 28 juli 2024 14:11]

[livePulse]

Komt de term "scriptkiddy" toch weer in een ander daglicht te staan...

[CAPSLOCK2000]

IT is moeilijk.

De marketeers van de grote softwarehuizen hebben jarenlang verkondigd dat hun software zo makkelijk is dat iedere halve zool er zonder enige opleiding mee om kan gaan. Dat doet iedere halve zool dus ook.
Een paar keer next, next, finish klikken kunnen ze ook wel. Nadenken over de implicaties van de (default) keuzes die ze accepteren kunnen ze echter niet. Daarvoor ontbreekt de achtergrond en de belangstelling om er meer over te lezen; voor de meeste mensen is IT gewoon iets dat je gebruikt, niet meer.

Ik zie hierboven opmerkingen als "dat zet je toch direct uit!". Ik vraag me dan af waarom het uberhaupt ooit aan heeft gestaan. Als het zo gevoelig is dan moet het uit staan, tot iemand het aan zet en daarbij precies aangeeft wat de grenzen zijn. Als je denkt dat product daarmee ongeschikt wordt voor "gewone" gebruikers, dan is het product gewoon ongeschikt. Je hebt het geschikt gemaakt door het risico af te schuiven op de onwetende gebruiker.

IT is als geneeskunde in de Middeleeuwen. De meesten zijn goed bedoelende kwakzalvers wiens vakkennis bestaat uit verhalen over mythische beesten en onredelijke goden. Een deel van die kennis klopt wel, maar de toepasser weet niet waarom en kan de kennis dus ook niet aanpassen aan de situatie.
Gat in je arm? Pleister er op zodat je het bloed niet meer ziet en klaar!

[Oerdond3r]

Wat veel gebeurd is dat mensen met programmeren beginnen, vervolgens html, css, php en mysql genoeg snappen om systemen te kunnen bouwen, en verder helemaal niet verdiepen in de veiligheid van systemen ( want het werkt toch? ). Erger is nog als deze mensen professionele opdrachten gaan aannemen. Met alle SQL injecties en XSS attacks van dien.

Zo ben ik ook begonnen (voornamelijk zelfstudie), uiteindelijk bij het bedrijf dat ik werkte genoeg van collega's opgepikt om mijn kennis van beveiliging bij te kunnen spijkeren gelukkig. Ik heb daarnaast ook een opleiding Informatica gedaan, maar kan me niet herinneren dat we het daar überhaupt over software security gehad hebben ( niet in depth in ieder geval).

[W00fer]

Dat alleen al is behoorlijk raar dat er niet over software beveiliging gepraat wordt.

[mutley69]

Als er iemand is, die tijd heeft - om security-testing te doen, dan zijn't toch wel zij - de scholieren zekerst?