Sinds deze wedstrijd begon als een intern project, hebben we veel aandacht besteed aan de flow om de website te hacken. Het was slechts een klein zijprojectje om onze collega's te informeren dat kleine fouten soms in een grote catastrofe kunnen uitmonden. Door ons te concentreren op de flow van de hackme wedstrijd, zijn we vergeten om de applicatie voor kwaadwillende deelnemers te beveiligen, iets wat ons op de eerste dagen van de wedstrijd alweer in de steek liet. Hier volgt een kleine beschrijving van de problemen die we zijn tegengekomen en hoe we ze hebben opgelost.

Een van de eerste hackers van de website merkte op dat de website kwetsbaar was voor XSS-aanvallen. Het was vrij naïef van ons om te denken dat de hacker niet zal proberen HTML of JavaScript code te injecteren in de applicatie. Het toevoegen van input validatie was niet mogelijk omdat de gebruiker directe invoegrechten op de database heeft. Dus het enige wat we konden doen is uitvoerfilteren met behulp van de htmlspecialchars() methode in PHP.

Een klein stukje JavaScript werd toegevoegd om er zeker van te zijn dat als een afbeelding niet kon worden geladen, een demotiverende anti-xss afbeelding werd getoond:

;(function($) {
  $(function(){
    var image = $('#hackme-image');
    var hackedUrl = image.data('src');
    var failedUrl ='/xss-breakfast.jpg';
    image
      .on('error', function(){
        image.attr('src', failedUrl);})
      .attr('src', hackedUrl);});})(jQuery);

Meer informatie nodig over het XSS prevention model?

Een paar uur later leek het erop dat dit type bescherming niet voldoende was.

Een van de deelnemers voegde de image URL in: http://superlogout.com/ Dit resulteerde in het uitloggen in veelgebruikte diensten zoals gmail en Facebook.

Een andere deelnemer voegde JavaScript toe aan een SVG-afbeelding:

<svgwidth="580"height="400"xmlns="<a href="http://www.w3.org/2000/svg">http://www.w3.org/2000/svg</a>">
 <g><title>background</title><rectfill="#fff"id="canvas_background"height="402"width="582"y="-1"x="-1"/><gdisplay="none"overflow="visible"y="0"x="0"height="100%"width="100%"id="canvasGrid"><rectfill="url(#gridpattern)"stroke-width="0"y="0"x="0"height="100%"width="100%"/></g></g><g><title>Layer 1</title><textxml:space="preserve"text-anchor="start"font-family="Helvetica, Arial, sans-serif"font-size="24"id="svg_1"y="201"x="232.5"stroke-width="0"stroke="#000"fill="#000000">HACKED</text></g><scripttype="text/javascript">
      alert('This site is vulnerable to XSS attacks!');
   </script></svg>

Het JavaScript wordt uitgevoerd wanneer een deelnemer de website bezoekt. Dit betekent dat we ons moeten beschermen tegen dit soort aanvallen en onze eenvoudige htmlspecialchars uitvoerfiltering moeten verbeteren. We hebben dit gedaan door te valideren of de gebruiker een geldige URL heeft toegevoegd. De extensie van het bestand werd gevalideerd door een whitelist van toegestane extensies:

Meer informatie over het valideren van geüploade bestanden.

De beveiliging die we hebben toegevoegd zag er uiteindelijk zo uit:

function xssProtect($url){
    $invalidUrl ='/xss-breakfast.jpg';
    $allowedExt =['jpg','jpeg','gif','png','bmp','tiff'];
    $url = htmlspecialchars($url);if(filter_var($url, FILTER_VALIDATE_URL,~FILTER_FLAG_SCHEME_REQUIRED &~FILTER_FLAG_HOST_REQUIRED)=== false){return $invalidUrl;}
    $parsed = parse_url($url, PHP_URL_PATH);if(!$parsed){return $invalidUrl;}
    $file = basename($parsed);
    $fileParts = pathinfo($file);
    $extension = isset($fileParts['extension'])? strtolower($fileParts['extension']):'';if(!in_array($extension, $allowedExt)){return $invalidUrl;}return $url;}

Natuurlijk is dit type bescherming niet voldoende en heeft het een aantal gebreken:

Het is mogelijk om bijvoorbeeld SVG-inhoud te gebruiken met de bestandsextensie JPG. Normaal gesproken beschermt uw browser u tegen dit soort aanvallen en het JavaScript zorgt ervoor dat het demotiverende anti-XSS beeld wordt weergegeven. Als u een zeer oude browser gebruikt, is het mogelijk dat dit type aanvallen kan worden uitgevoerd. Dit is dus iets waar we ons niet op hebben gericht. De enige manier om dit probleem te omzeilen is door het bestand te downloaden en de inhoud van het bestand te bekijken met een bibliotheek zoals imagemagick. Omdat dit veel werk is en veel lokale opslag vereist, hebben we besloten om ons niet op dit probleem te richten.

Het is niet mogelijk om eindpunten toe te voegen die geen voorvoegsel van een afbeelding bevatten. Dit betekent dat korte URL's niet mogelijk zijn.

Door dit type van beveiliging toe te voegen, zijn we erin geslaagd om nieuwe deelnemers te demotiveren in het vinden van extra XSS gaten. Je zou kunnen denken dat onze problemen op dit moment allemaal zijn opgelost, maar nee hoor... de volgende golf van problemen was er. Aangezien we het laatste beeld aan het laden zijn op basis van ID-sortering DESC, was er iemand die een record invoegde in de laatst mogelijke ID van het mysql INT type. Mysql zal altijd proberen om 1 toe te voegen aan de laatst ingevoegde ID, wat resulteert in een integer overflow.

Dit is een probleem dat niet zou moeten gebeuren in een normale toepassing, dus we hebben dit probleem tijdelijk gepatcht door het veld een mysql BIGINT type te maken. Natuurlijk redde deze patch de applicatie maar voor precies 2 minuten, dus we moesten snel denken en met een bullet proof oplossing komen:

CREATE TRIGGER images_cleandata
BEFORE INSERT ON images
FOR EACH ROW
BEGIN
 
  SET NEW.id =NULL;
  SET NEW.creation_date = CURRENT_TIMESTAMP;
 
END$$

Na het maken van deze trigger moesten we de id kolom verwijderen en opnieuw toevoegen om de auto increment values van de tabel te resetten. Wanneer een gebruiker een nieuw record met een hoge id invoegt, wordt het door de trigger gereset naar NULL en de AUTO_INCREMENT opties worden vanaf dat punt ingeschakeld. Het zorgde er ook voor dat de deelnemer niet kon knoeien met de aanmaakdatum.

Op dit punt begonnen de deelnemers agressiever te worden door het schrijven van cronjobs of geautomatiseerde scripts om de mysql server te spammen met commando's voor het invoegen. Deze hack was problematisch omdat we een cronjob schreven die ons elke keer dat er nieuwe records in de afbeeldingen tabel stonden mailt. Je kunt je voorstellen hoe opgeblazen mijn mailbox op dat moment was, dus ik besloot om deze mails maar één keer per uur te versturen.

De eerste keer dat we dit soort bots tegenkwamen, dachten we dat we konden voorkomen dat deze deelnemers de server spammen door de image url te vervangen door een demotiverende crons image.

CREATE TRIGGER images_cleandata
BEFORE INSERT ON images
FOR EACH ROW
BEGIN
 
  -- Try to avoid random query strings:
  set @baseUrl :=(SELECT SUBSTRING_INDEX(NEW.imageURL,'?',1));-- Search for duplicate records:
  SET @croncount :=(
    SELECT COUNT(id)
    FROM images
    WHERE (
      imageURL = NEW.imageURL
      OR imageURL LIKE CONCAT(@baseUrl,'?%')
      OR imageURL =@baseUrl
    )
    AND `name` = NEW.name
    AND email = NEW.email
    AND location = NEW.location
  );-- Overwrite anti cron / bot image
  IF @croncount >=10 THEN
    SET NEW.imageURL ='<a href="http://hackme.phpro.be/cron-nam.png">http://hackme.phpro.be/cron-nam.png</a>';
  END IF;-- Set defaults:
  SET NEW.id =NULL;
  SET NEW.creation_date = CURRENT_TIMESTAMP;
 
END$$

Zoals u kunt zien, zoekt de cron nu naar afbeeldings-URL's die 10 keer in de database zijn voorgekomen. Als de afbeelding meer dan 10 keer is ingevoegd, wordt de demotiverende cron afbeelding weergegeven.

Op een later moment moesten we ook de baseUrl check toevoegen, omdat de bots slimmer werden en waar willekeurige hash werd toegevoegd in het query gedeelte van de URL. Deze fix zorgde ervoor dat sommige bots stopten, maar sommige andere bots merkten het gewoon niet op, dus we moesten uitzoeken van welke IP ze de server spammen. We hebben dit gedaan door een nieuw host veld toe te voegen aan de tabel met afbeeldingen en hebben dit veld ook gevuld door de trigger te wijzigen:

CREATE TRIGGER images_cleandata
BEFORE INSERT ON images
FOR EACH ROW
BEGIN
  -- Look for host:
  set @host :=(SELECT SUBSTRING_INDEX(USER(),'@',-1));--... snap ...-- Set defaults:
  SET NEW.host =@host;
END$$

In eerste instantie hebben we gebruik gemaakt van het host veld uit de `informatie_schema.processes` tabel. Normaal gesproken zou dit moeten werken, maar aangezien de code binnen een trigger wordt uitgevoerd, is de huidige host altijd localhost:randomport. Na wat rondkijken merkten we dat we de ingebouwde `USER()` functie konden gebruiken die de naam van de mysql gebruiker en de naam van de eigenlijke host weergeeft. Bijvoorbeeld: hackMe@myhost.

Nu we de host van de deelnemer hebben en op de hoogte zijn van spamming bots, is het eenvoudig om de ip te bannen met behulp van iptables.

We hebben dit proces niet geautomatiseerd om er zeker van te zijn dat geen enkele deelnemer wordt verbannen voor een misdaad die ze niet hebben begaan.

iptables -A INPUT -s yourhost -p tcp --destination-port 9998-j DROP

Nadat we deze fix hadden toegepast, werden de bots weer slimmer en voegden ze pas een nieuwe afbeelding toe als de afbeelding op de website veranderde sinds de laatste keer dat ze deze controleerden. Omdat ze constant tussen 2 of 3 afbeeldingen doorliepen, was het eenvoudig om te bepalen of het een bot was die de afbeeldingen invoegde of een echte gebruiker. Als we erachter kwamen dat het een bot was, sloten we de bot uit en verwijderde we de ingevoegde record, zodat de laatste echte afbeelding weer weergegeven werd.

Zoals u zich kunt voorstellen, was het een lange weg om deze zeer eenvoudige toepassing volledig te beschermen. De lessen die we hebben geleerd van dit project? Neem veiligheid nooit als vanzelfsprekend!

Echte hackers zullen altijd een manier vinden om uw toepassing te vernietigen. Het draait allemaal om monitoring, de tegenmaatregelen die je neemt en de hoeveelheid tijd die je nodig hebt om deze beveiligingen te implementeren!