Archief - Q: Bijna gehacked

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
S

Sprits

Legacy Member
Gisteren wou ik een aantal dingen op mijn ftp server zetten en zag ik 3-4 files staan die ik niet kende, namelijk:
2008.php
admincp.php
r57.php
scanner.exe

Ik heb 2008.php gedownload en bekeken...
PHP: 
====================== 最后预祝安全天使的每一位朋友飞黄腾达 =======================

Codz by angel(4ngel)

Make in China

Web: http://www.4ngel.net

*****************************************************************************/

de php file bestaat uit een +- 2000 lijnen php code. Na verder onderzoek, heeft dit iets te maken met PhpSpy (of zoiets).

Kheb die files direct in een aparte map gezet, mijn website offline gehaald en alle paswoorden veranderd.
Ik heb dan een mailtje gestuurd naar mijn hosting (1-eurohost) met de vraag wie/wat deze files er heeft opgezet.
Dit was hun antwoord
Files zijn er geplaatst via ftp:

Sun Jun 1 20:04:16 2008 1 82.169.226.84 108698 /***/***/***/nibbler.be/httpdocs/r57.php.txt a _ i r nibbler ftp 0 * c

Of<wel gebruikte je een onveilig wachtwoord ofwel is via spyware / adware kje ftp wachtwoord gesniffed.
Klik om te vergroten...

Het komt alle sinds niet van mij want ik heb een ander ip adres. Ik heb geen spyware / adaware op mijn pc staan en ben beveiligd.

Normaal gezien zijn mijn paswoorden vrij complex dus het kan niet zijn dat men daar zomaar achterkomt.


Nu zit ik toch nog met een aantal vragen, namelijk...

Hoe komen deze files op mijn ftp?
Kunnen ze aan persoonlijke info geraken?
Moet ik vrezen voor nog een 'attack'? (staat nochtans niks belangrijk op...)
Kan ik te weten komen wie dit gedaan heeft via het ip adres?
d

dendaak

Legacy Member
Door een onvelig php script te draaien op je website.
Zorg dat je paswoordenverschillen van degene van je databases en ftp !tip
c

cool_boy_ke

Legacy Member
wardkennes zei:
Door een onvelig php script te draaien op je website.
Zorg dat je paswoordenverschillen van degene van je databases en ftp !tip
Klik om te vergroten...
Jup, je zou verwonderd zijn hoeveel CMS exploits hebben. Heb me er eens in verdiept en had op m'n home serverke een (redelijk bekend voor gamers) CMS geïnstalleerd en daar dan vanal mee geprobeert. Ik had dmv even te googlen voor exploits 5 minuten later een simpele uploader erop staan en de MD5 hashes voor de admin. Stel u voor wat ik daarmee kan doen op een echte website: zeer makelijk virussen verspreiden, botnetje creeëren, scripts uploaden (zoals deze), ...
De meeste mensen hebben voor alles hetzelfde paswoord, dus dat admin paswoord is waarschijnlijk ook dat van z'n email, msn, Steam, PayPal, ...
S

Sprits

Legacy Member
cool_boy_ke zei:
Jup, je zou verwonderd zijn hoeveel CMS exploits hebben. Heb me er eens in verdiept en had op m'n home serverke een (redelijk bekend voor gamers) CMS geïnstalleerd en daar dan vanal mee geprobeert. Ik had dmv even te googlen voor exploits 5 minuten later een simpele uploader erop staan en de MD5 hashes voor de admin. Stel u voor wat ik daarmee kan doen op een echte website: zeer makelijk virussen verspreiden, botnetje creeëren, scripts uploaden (zoals deze), ...
De meeste mensen hebben voor alles hetzelfde paswoord, dus dat admin paswoord is waarschijnlijk ook dat van z'n email, msn, Steam, PayPal, ...
Klik om te vergroten...
tis geen cms... tis zelfgeschreven code :s

paswoord van mijn ftp is verschillend als die van mijn databases. Het enige waarmee mijn ftp paswoord overeenkomt is deze van mijn gmail account, en daar is nix mis mee.
c

cool_boy_ke

Legacy Member
nibbler.be zei:
een onveilig script kan niet, want ik heb de volledige code van mijn website zelfgeschreven. :s
Klik om te vergroten...
Is nog geen garantie dat het veilig is hé, een injection is genoeg :)
S

Sprits

Legacy Member
Tyfius zei:
En omdat dat zelf geschreven is is dat veilig? :P
Klik om te vergroten...
dat zeg ik niet :p
cool_boy_ke zei:
Is nog geen garantie dat het veilig is hé, een injection is genoeg :)
Klik om te vergroten...

is er een beveiliging tegen injections dan?

(edit: nvm, stoeme vraag... ik heb er al wat van gevonden :))
e

exxhal

Legacy Member
Klein vraagje.

Kon je via jouw website via een script bestanden uploaden ?
e

exxhal

Legacy Member
cool_boy_ke zei:
Is nog geen garantie dat het veilig is hé, een injection is genoeg :)
Klik om te vergroten...

Dan rest de vraag of je dan via een injection waar het enkel toegelaten is jpg's te uploaden mogenlijk is om andere bestanden te uploaden en dan vooral in de root dan nog. Want ik vermoed dat de jpg's dan ook ergens in een map worden geplaatst.
S

Sprits

Legacy Member
exxhal zei:
Dan rest de vraag of je dan via een injection waar het enkel toegelaten is jpg's te uploaden mogenlijk is om andere bestanden te uploaden en dan vooral in de root dan nog. Want ik vermoed dat de jpg's dan ook ergens in een map worden geplaatst.
Klik om te vergroten...

het upload scriptje stond in /root/admin/ en de files werden verplaatst naar /root/anime/upload/
de images worden inderdaad in een andere map opgeslagen.
e

exxhal

Legacy Member
hopa
In plaats van de upload stop te zetten genereert het PHP script bij een verkeerde extensie alleen een JavaScript foutmelding. Maar de upload procedure wordt niet stopgezet! Het lijkt er op dat de programmeur een simpele toevoeging van "exit()" over het hoofd heeft gezien.

Door deze blunder in de beveiliging kan de hacker een willekeurig bestand uploaden naar de directory "components/com_expose/expose/img/". In de meeste gevallen gaat het hierbij een PHP script - een zogenaamde PHP shell - zoals "c99.php" of "r57.php" waarmee de hacker op afstand de website kan overnemen.
S

Sprits

Legacy Member
dus eigelijk is het volgende voorbeeld niet goed?

PHP: 
if ($_FILES['imagefile']['type'] == "image/jpg" || $_FILES['imagefile']['type'] == "image/jpeg" || $_FILES['imagefile']['type'] == "image/pjpeg") {

uploadprocess

}
else {
		echo "ERROR: Wrong filetype. Only .jpg or .jpeg allowed.";
	}
e

exxhal

Legacy Member
t'ja na de upload het bestand controleren of het wel een jpg is zou ook een optie zijn.:lol:
S

Sprits

Legacy Member
Ik ga is wat tijd vrijmaken om mijn volledige code te herzien en meer beveilinging aan te brengen.

Aan de ene kant ben ik al blij dat ik niks kwijt ben...

Bedankt allesinds voor de uitleg :)
t

taLa.

Legacy Member
Wat velen hier vergeten is dat het niet noodzakelijk jouw site is die gehacked is. Het komt vaak genoeg voor dat op een shared host 1 onveilige site staat waarlangs ze binnen geraken, en vervolgens aan alle accounts op die machine kunnen. Het probleem ligt dan bij een gebrekkige configuratie en/of beveiliging van je host, die dit normaalgezien toch enigszins kan voorkomen of beperken.

Ik weet het natuurlijk niet, maar ik heb toch de indruk dat dit hier wel eens het geval kan zijn, zeker omdat je aangeeft zelf beveiligd te zijn en sterke paswoorden te gebruiken en afgaande op het onprofessionele karakter van de reply van je host. Uiteraard controleer je best eerst of het aan jou lag vooraleer je je host aanspreekt - doorzoek al je code op zoek naar vulnerabilities, eventueel door iemand die er meer vanaf weet. Kijk ook eens of je logs kan terugvinden van eventuele file uploads.

Overigens is jouw voorbeeldcode inderdaad niet goed: de controle op type is slechts een controle op het MIME-type zoals opgegeven door je browser tijdens het uploaden. Dat is echter geen garantie dat het bestand ook effectief van dat type is: een typisch voorkomende aanvalsmethode speciaal ontworpen om dergelijke if-checks te omzeilen is om het MIME-type te spoofen. Zo kan iemand bijvoorbeeld een PHP script uploaden en als MIME-type JPEG meegeven, en het dan requesten - Apache zal het dan ook effectief uitvoeren omdat het bestand eindigt op .php.

Het is dus veiliger om te controleren op de extensie van het bestand ipv op het MIME-type. Zorg er ook altijd voor dat je de functies is_uploaded_file en move_uploaded_file gebruikt. Doe ook eens wat research inzake security van PHP uploads, kan nooit kwaad. Bv. een handige methode voor het uploaden van afbeeldingen is om ze door de GD functies te jagen en te laten omzetten naar .pngs. Op die manier zullen niet-afbeeldingen met een .jpg/.png/.gif extensie toch niet op de server belanden, omdat de GD-functies zullen falen bij het converteren.
R

RpR

Legacy Member
Sorry maar als je bestanden upload in de root zijn home dir dan wilt zeggen dat uw script ofwel rechten heeft op de home ofwel als root wordt uitgevoerd. Beiden zijn extreem gevaarlijk.
T

TiZon

Legacy Member
Ik heb een upload-script op mijn site draaien.
Daar heb ik eens last meer gehad, ik controleerde op extentie (explode op .) en dat was niet zo goed blijkbaar want als je dan bijvoorbeeld .jpg.php uploade, dan ging dat.

Nu gelukkiglijk opgelost, maar ik heb nog eens mijn mysqs-database in rook zien opgaan omdat ik op shared hosting zat en iemand anders een uploader had waar je alles kon zien.

Nog een zot script ze... Ik kon heel de content van de HD zien....
Veel beveiligingslekken, maar ik ben er redelijk zeker van, dat de mijne nu veilig is :)
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan