Check alle échte Black Friday-deals Ook zo moe van nepaanbiedingen? Wij laten alleen échte deals zien

Verschillende sites gedefaced, wat is het lek?

Pagina: 1
Acties:

  • Ron!n
  • Registratie: Juli 2003
  • Laatst online: 21:11
Mijn probleem:
Meerdere van mijn websites zijn de afgelopen tijd gedefaced of gewijzigd, in totaal op dit moment 5 stuks de afgelopen maand (meerdere malen). Het lijkt me geen gerichte aanval op mijn bedrijf, maar een scriptkiddie attack die gewoon willekeurig sites zoekt met zwakheden.

Iets meer over mij/mijn bedrijf:

Samen met een vriend van mij heb ik een bedrijf dat o.a. websites creëerd. Ikzelf doe niets technisch, dat doet mijn vennoot. We nemen onze hostingruimte af van een hostingbedrijf (domeinbalie), wijzelf zijn slechts reseller.

Door wie worden de hacks uitgevoerd?

Verschillende partijen, waarom ik dit denk? Er worden steeds verschillende dingen gedaan.
De een verwijderd de complete website en verwijderd de database, de ander plaatst een iframe dat probeerd malware te installeren, de ander veranderd alleen de index. Bepaalde sites kan ik terugvinden op een site waar gedefacede sites worden gepost (zone-h.org, nu offline zie ik). Ook zie ik daar andere websites opstaan die op dezelfde server bij mijn host staan (maar niet van mij zijn), dit vind ik erg vreemd en zou duiden op zwakheden in de beveiliging van de server.

Waar zouden de zwakheden kunnen zitten?

Ik was eerst 100% ervan overtuigd dat dit bij onze host zat, aangezien sommige sites totaal anders in elkaar zitten, geen CMS hebben, verschillende soort beveiliging, enz. Maar aangezien er nu ook een site op onze tweede host (transip) is gewijzigd ga ik hier niet meer van uit.
Wat zijn dan gevoelige punten? Dit zou een zwakheid kunnen zijn:

Het contactformulier
- is de afhandeling en errorcontrole wel correct?
Form code
PHP:
1
2
3
4
if(isset($_POST['verzenden']))
{
    MailSend($db_data, $naam, $email, $telefoon, $opmerking, $sitemail);
}

Functie MailSend
PHP:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
function MailSend($db_data, $naam, $email, $telefoon, $opmerking, $sitemail)
{
  global $boodschap;
  
  $naam                     =                   strip_tags($naam);
  $naam                     =                   addslashes($naam);
  $email                    =                   strip_tags($email);
  $email                    =                   addslashes($email);
  $telefoon                 =                   strip_tags($telefoon);
  $telefoon                 =                   addslashes($telefoon);
  $opmerking                =                   strip_tags($opmerking);
  $opmerking                =                   addslashes($opmerking);
  $sitemail                 =                   strip_tags($sitemail);
  $sitemail                 =                   addslashes($sitemail);
  
  $message = "BERICHT VERZONDEN VANAF HET CONTACTFORMULIER OP DE WEBSITE:\n\n\nNaam: ". $naam."\nE-MAIL: 

".$email."\nTelefoonnummer: ".$telefoon."\n\nBericht:\n\n".$opmerking;
  if($naam != "" && $email != "" && $telefoon != "" && $opmerking != ""){ // Goed ingevuld formulier

    $naam       =       addslashes($naam);
    $telefoon  =       addslashes($telefoon);
    $opmerking  =       addslashes($opmerking);
    
    $headers .= "From: ".$naam." <".$email.">" . "\r\n";
    $onderwerp = "Bericht via website";

    mail($sitemail, $onderwerp, $message, $headers);
    $boodschap = "<script language='JavaScript' type='text/javascript'>
                    <!--
                        alert(\"Hartelijk bedankt! Uw bericht werd succesvol verzonden...\");
                    // -->
                    </script>";
  }else{ // Niet goed of onvolledig ingevuld formulier:
     $boodschap = "<script language='JavaScript' type='text/javascript'>
                    <!--
                        alert(\"Het bericht kon niet worden verzonden. U heeft bepaalde velden foutief of 

onvolledig ingevuld...\");
                    // -->
                    </script>";
    }
}


Navigatie
- de standaard index.php die dynamisch inhoud inlaad, de variabele $page zorgt hiervoor.
PHP:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
    <div id='inhoud_links'> <!-- Start inhoud_links -->
    <?php // Bepalen paginatitel: 
            switch($page)
            {
                case "home":
                    echo "\t\t<p class='titel' title='Its Hammertime'><img 

src='graphics/title_itshammertime.jpg' alt='Its HAMMERTIME' /></p>\n";
                    include("home.php");
                    break;
                case "diensten":
                    echo "\t\t<p class='titel' title='Diensten'><img 

src='graphics/title_diensten.jpg' alt='Diensten' /></p>\n";
                    include("diensten.php");
                    break;
                case "projecten":
                    echo "\t\t<p class='titel' title='Projecten'><img 

src='graphics/title_projecten.jpg' alt='Projecten' /></p>\n";
                    include("projecten.php");
                    break;
                case "bedrijf":
                    echo "\t\t<p class='titel' title='Bedrijf'><img 

src='graphics/title_bedrijf.jpg' alt='Bedrijf' /></p>\n";
                    include("bedrijf.php");
                    break;
                case "partners":
                    echo "\t\t<p class='titel' title='Partners'><img 

src='graphics/title_partners.jpg' alt='Partners' /></p>\n";
                    include("partners.php");
                    break;
                case "contact":
                    echo "\t\t<p class='titel' title='Contact'><img 

src='graphics/title_contact.jpg' alt='Contact' /></p>\n";
                    include("contact.php");
                    break;
                case "colofon":
                    echo "\t\t<p class='titel' title='Colofon'><img 

src='graphics/title_colofon.jpg' alt='Colofon' /></p>\n";
                    include("colofon.php");
                    break;
                default:
                    echo "\t\t<p class='titel' title='Its Hammertime'><img 

src='graphics/title_itshammertime.jpg' alt='Its HAMMERTIME' /></p>\n";
                    include("home.php");
                    break;
            }
    ?>

TinyMCE
- Heb gezien dat hier problemen mee zouden kunnen zijn en dit direct op verschillende sites uitgeschakeld of in een map geplaatst die via .htaccess afgeschermd is, is dit voldoende?

Achterliggende serversoftware?
code:
1
2
3
4
5
6
7
8
9
10
11
General server information:
Operating system    Linux
Kernel version  2.6.22.14-72.fc6
Machine Type    x86_64
Apache version  2.2.8 (Unix)
PERL version    5.8.8
PHP version     5.2.5
MySQL version   5.0.45-community
cPanel Build    11.23.3-RELEASE 25133
Theme   cPanel X v2.6.0
cPanel Pro  1.0 (RC1)


Tips worden zeer gewaardeerd, zit een beetje met het handen in het haar of ik alles moet verhuizen naar een andere host. Als het advies is om een professioneel bedrijf naar de beveiliging te laten kijken dan snap ik dat, ookal is dat niet echt financieel haalbaar is het als het moet gewoon maar de harde realiteit.

Ik snap dat ik geen van mijn eigen sites mag posten en zal dit dus niet doen, als mensen mij willen pm-en om ze te testen op SQL-injections e.d. zal ik uiteraard de URLs sturen.

What's in the case?


Verwijderd

Ik ben de 'vennoot' waar het in de openingspost over ging. Inmiddels doen we het PHP-gedeelte bij websites grotendeels anders, helemaal op een OO-correcte manier. Toch kan ik niet inzien hoe websites zoals in de openingspost omschreven omstandigheden zo kunnen worden gehackt/defaced. Dus idd: tips en/of helpende opmerkingen worden zeer gewaardeerd!

  • GlowMouse
  • Registratie: November 2002
  • Niet online
HTTP access logs geven geen duidelijkheid? Op het filesystem staat wanneer de files zijn gewijzigd, dan kun je vrij gericht zoeken.

Je mailscript bevat wel een foutje, maar daarmee kun je geen bestanden wijzigen. De indexfile ziet er veilig uit.

[ Voor 40% gewijzigd door GlowMouse op 12-06-2008 23:05 ]


Verwijderd

Bij een eerdere aanval op 1 van de genoemde sites (op 3 juni 2008) werd de index.php gedefaced en troffen we diverse vreemde PHP-bestanden aan in verschillende mappen van de site. Ook werd de door de site gebruikte MySQL-database volledig verwijderd.

Een nader onderzoekje leerde dat de hacker in kwestie een script-bestand had geupload dat ik hier even pietje.php noem (de werkelijke naam refereert naar degene die dit script schreef - dit was niet de hacker zelf omdat je het script op diverse hack-fora tegenkomt). Dit bestand toont in de browser een prachtige interface waarmee de gebruiker door alle mappen (ook de .htaccess-beveiligde) kan surfen en naar hartelust dingen kan wijzigen/verwijderen. Ook was het mogelijk om SQL-query's te draaien. De werking was me niet helemaal duidelijk, maar ik heb het script in dit bestand nog in bezit. Een PM naar mij of Ron!n en ik stuur het je op als je ons ermee zou kunnen helpen.

Hoe dan ook, in de access-logs trof ik genoeg 'foute' ip-adressen aan die een hele hoop verdachte acties ondernamen op tijdstippen waarop de 'hack' zou kunnen zijn uitgevoerd. Tussen alle normale bezoekers zaten deze regels (ip-adressen, bestanden en URL's heb ik even gewijzigd in **** ivm regels op Tweakers.net):

code:
1
2
***.***.116.238 - - [02/Jun/2008:18:22:06 +0200] "GET /pietje.php HTTP/1.1" 200 68743 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)"
***.***..116.238 - - [02/Jun/2008:18:22:23 +0200] "POST /pietje.php HTTP/1.1" 200 66344 "http://********.**/pietje.php" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)"


Zoals je ziet was er bij regel 2 een POST-request gedaan. Dit valt op omdat vrijwel alle andere gelogde bezoeken GET-requests deden. En juist bij deze twee regels begon de ellende. De bezoeker met dit ip-adres en velen daarna (die een hoop deden met de verdachte bestanden) deden dit vanaf internet-abo's in het Midden Oosten (Turkije, Irak, Syrie, Saudi-Arabie, Egypte) en eentje in Monaco. Hier tussendoor zaten nog enkele normale bezoeken. Uren ging dit zo door, en waren het ook veel vreemde mensen die alleen kwamen kijken. Bezoekers-aantallen uit deze regio's namen die dag ook explosief toe :/ .Dit maak ik althans op uit de access-logs...

Hierna hebben we de complete website er af gegooid, de verdachte scripts en bestanden lokaal bewaard en alles weer opnieuw erop gezet. De DB was dankzij een eigen backup zo de ellende weer te boven. Toch kon ik nergens een zwakheid vinden (zie openingspost voor info hierover), noch elders ontdekken hoe dit kon gebeuren. Deze site is vandaag weer voor een tweede maal 'gehackt', hoewel dit keer alleen de index.php werd gedefaced. Het spreekt voor zich dat we dit nu spuugzat zijn (zachtjes uitgedrukt).

  • GlowMouse
  • Registratie: November 2002
  • Niet online
En je ziet niet hoe pietje.php ooit geupload is? Evt weer naar het tijdstip van aanmaken kijken.

Wanneer dat onduidelijk is, zou ik met de hoster contact opnemen. Bij slecht beveiligde shared hosting kan een andere gebruiker bestanden in jouw map wegschrijven.

  • sh4d0wman
  • Registratie: April 2002
  • Nu online

sh4d0wman

Attack | Exploit | Pwn

Hoogstwaarschijnlijk een Remote File Upload exploit als ik een wilde gok mag doen.
Zodra dat php bestand geupload is kan dat inderdaad veel schade aanrichten, ik heb er toevallig wel eens eentje gedownload uit nieuwschierigheid.

Een voorbeeld:

[|Description:|]
A security bug has been discovered in MetaForum 0.513 Beta. This bug can be used by an attacker to upload a malicious php file on the server.
During the upload, the MIME type of the file is the only verified parameter. The extention isn't.
This enables a attacker to fake the MIME type of a php file so that it is considered as an image.

Je zou eens even kunnen zoeken of Tiny hier recent of in het verleden gevoelig voor is geweest.

edit: even voor je gezocht:

Cpanel heeft geen heel recente exploit wat ik zo zie.

TinyMCE heeft eind vorig jaar deze: CMS Made Simple <= 1.2.2 (TinyMCE module) - Remote SQL Injection Advisory. Ik weet niet welke versie je hebt.

$_GET["templateid"] isn't properly checked at line 27, this results in a sql injection at line 67

• An attacker can break database through browser! P.o.C. :

[ Voor 29% gewijzigd door sh4d0wman op 12-06-2008 23:39 ]

This signature has been taken down by the Dutch police in the course of an international lawenforcement operation.


Verwijderd

@GlowMouse:
Helaas konden we het tijdstip van aanmaken toendertijd niet zien. Dit ligt aan de mogelijkheden van het resel-pakket dat wij gebruiken bij provider Domeinbalie.nl. Bovendien ging het access-log dat op dat moment op de server stond ook maar slechts een dag terug. De twee regels die ik eerder poste waren de eerste verdachte. Hiervoor was het bezoek zoals op alle andere normale dagen (mensen die de normale bestanden op de site bekijken; plaatjes, PHP-files, CSS etc.).

@sh4d0wman: TinyMCE kende idd zo de nodige gevoeligheden in het verleden. Op deze bewuste site stond TinyMCE in een met .htaccess beveiligte website. Tenzij je gebruikersnaam en -wachtwoord weet lijkt het haast onmogelijk om er dan bij te komen zou je denken. En in theorie zou meneer of mevrouw hacker deze gegevens kunnen hebben gepikt + gebruikt om hier vervolgens binnen te komen, maar dit lijkt uiterst onwaarschijnlijk omdat het een wilekeurige hack lijkt te zijn. De hacker/defacer in kwestie had nl. een aardige lijst met door hem/haar gedefacede websites opgebouwd - te zien op de eerder genoemde website zone-h.org. Dit suggereert dat men op een andere manier zich toegang heeft verschaft tot het bestandssysteem...

Tot nu toe zijn er drie mogelijkheden hiervoor te bedenken:

1. Hacker kwam binnen via zwakheid in 1 van onze scripten
Bijna onmogelijk via ons, maar wellicht dat wij iets over 't hoofd zien hier. Ook hierbij speelt de vraag: hoe weet men dan dat er zwakheden spelen? Kan er hiervoor een geautomatiseerd iets zijn gebruikt?

2. Hacker jatte gebruikersnaam en wachtwoord van .htaccess-beveiligde map
Zeer onwaarschijnlijk. Geldt sowieso voor alle gebruikersnaam-/wachtwoordcombinaties, tenzij er met een script naar gefisht is... Maar wie weet had men ze helemaal niet nodig.

3. Hacker misbruikt shared hosting-server zwakheden
Dit zou kunnen. Er kunnen zwakheden zitten in gebruikte software zoals cPanel of het FTP-systeem. Beide worden volgens de provider haast dagelijks (automatisch) ge-update naar de nieuwste versies. En het feit dat we bij twee verschillende hosting-providers werden aangevallen ontkracht dit helemaal. Beiden gebruiken totaal andere beveiliging en software. Edit: wat wel verdacht was is dat de hacker hier veel andere sites op dezelfde shared-hosting server heeft gedefaced. Hier kwamen we achter door in z'n 'scorelijstje' te kijken op zone-h.org. De meeste defacements vonden kort op elkaar plaats...

Er kunnen natuurlijk nog meer mogelijkheden zijn. Weet ze nu niet even 1-2-3 neer te pennen...

[ Voor 5% gewijzigd door Verwijderd op 13-06-2008 00:10 ]


  • sh4d0wman
  • Registratie: April 2002
  • Nu online

sh4d0wman

Attack | Exploit | Pwn

Voor exploits heb je geen gebruikersnaam of wachtwoord nodig. Het is dus goed mogelijk dat de cracker een bepaalde exploit in bezit heeft welke nog niet openbaar is. Kun je op zone-h nog een logica zien in de gehackte sites? Is er op enig punt een overeenkomst in software?

Je hoster zal toch wel logging uit een backup kunnen trekken of niet? De vraag is natuurlijk of je hier iets aan hebt ;)

This signature has been taken down by the Dutch police in the course of an international lawenforcement operation.


Verwijderd

In elk geval was het duidelijk dat bij één bepaalde serie hacks er heel veel websites, gehost bij dezelfde provider tussen zaten. Maar waarom dit zo ging is ons nog steeds niet duidelijk.

We zijn er nog druk mee bezig, na het weekend even meer.

  • Joen
  • Registratie: Juli 2003
  • Laatst online: 20-11 13:02
Keep us notified! :)
Ik vind dit wel zeer bizar en ben ook zeer benieuwd hoe ze nu precies je site shebben kunnen defacen....
Pagina: 1