E-learn Weblog of Willem van Valkenburg

Gistermiddag was er een technische sessie over Hoe veilig zijn onze (web)applicaties? georganiseerd door de security manager. Als eerste was de security manager aan het woord met een overzicht wat er op dit moment al gebeurd binnen de TU en dat is best veel. Maar er zijn ook aan aantal zaken die we nog niet (goed) doen, zoals testen analyseren van logfiles, netwerkverkeer en applicaties. De belangrijkste is echter bij het maken van de applicatie al heel goed letten op security en dit ook uitgebreid testen.

Belangrijk bij het in kaart brengen van de beveiling is de classificatie van de verschillende applicaties. Hoe belangrijk of vertrouwelijk is de informatie? Een applicatie waar docenten cijfers mee invoeren, is toch vrij belangrijk dat dit niet door een ander kan worden gedaan of dat de cijfers kunnen worden aangepast.

Vervolgens gingen Jeroen van Dongen en Jan Folkert Behtelehm van LBVD Consultancy in de meest voorkomende kwetsbaarheden en de maatregelen die je hiertegen kan nemen.

De meest voorkomende kwetsbaarheden zijn:

• buffer overflow
• file inclusion
• cross-site scripting
• sql injection
• script injection
• zwakke authenticatie

Van al deze kwetsbaarheden lieten zij ook voorbeelden zien met zelfs een live demo. Algemene conclusie van hun was dat de TU de zaken redelijk op orde heeft, maar er nog wel verbeteringen mogelijk zijn.

Buffer overflow
Dit is eigenlijk al een hele oude kwetsbaarheid, maar die komt nog steeds voor. Vooral in besturingssystemen. De belangrijkste oplossing hiervoor is om de input altijd goed te checken. Als er maar 16bit ruimte is, wordt alleen de eerste 16 bit toegelaten. De moderne talen (java, python) hebben hier geen last van. Eventuele vangnetten hiervoor zijn:

• non-executable memory
• address space randomization
• IDS/IPS
• Filtering van het uitgaand verkeer

File inclusion
De belangrijkste oplossing is om ook hier goed de input te controleren, zodat je via een bepaalde url opeens /etc/password-file op je scherm kan krijgen. Welke programmeertaal je hier gebruikt, is hier ook van belang. Eventuele vangnetten:

• chrooted jail /virtualisatie
• correcte rechten structuren
• url filter(IIS) of mod_security (Apache)
• IDS/IPS

Cross-site scripting
je creert hierbij de illussie dat je op een 'veilige' site zit. Hiermee kan je bijvoorbeeld iemands sessie overnemen, zijn username/wachtwoord verkrijgen of zelf credit-card gegevens. De belangrijkste maatregel hiertegen is het controleren van de input!

SQL/Script injection
Hierbij wordt de invoer op de site niet goed gecontroleerd, waardoor je sql-queries kan uitvoeren. Een bekende hiervan is dat je in een password-veld ' or '1' = '1 invuld. Deze statement is altijd waar, dus ben je automatisch ingelogd. De belangrijkste remedie is om de inpunt weer goed te controleren. Vergeet niet dat een koppeling met een extern systeem ook een input kan zijn. Een andere oplossing is een database access laag met automatische quoting. Dit is alleen zinvol als je een nieuwe applicatie ontwikkeld. De vangnetten hierbij zijn:

• correcte rechten structuur (gebruikte database user kan alleen bij de tabellen waar hij bij moet kunnen en geef alleen leesrechten als dat voldoende is)
• url filter(IIS) of mod_security (Apache) (controleren op de url. Als je altijd op een site alleen /?id=<getal> hebt, dan kan je hier ook op controleren)
• IDS/IPS

Zwakke authenticatie
We zitten tegenwoordig tegen de grenzen aan wat gebruikers nog accepteren om als password te gebruiken. De vraag is nu dus of passwords wel toereikend zijn. Harde authenticatie, waarbij je met een token of mobiel nog een extra code moet invoeren, zijn voor sommige applicaties wel gewenst. Dit is natuurlijk afhankelijk van de classificatie van de applicatie. Belangrijk hierbij zijn:

• goede password policy
• lock-out policy (maximaal aantal keren dat een ip-adres kan inloggen per tijdseenheid)
• uitgifte nieuwe passwords.
  Hoe vaak zie je niet dat er als standaard password Welcome01 wordt gebruikt. Dit wachtwoord voldoet aan de password policy van minimaal 8 tekens, minimaal 1 hoofdletter en een cijfer.
• wachtwoord 'vergeten'
  hoe is de procedure als iemand zijn wachtwoord is vergeten? Bij ons moet een student dan fysiek langskomen en zich legitimeren, wordt dat wel door iedereen zo nageleefd?

Vangnetten hierbij zijn:

• verkleinen van de zichtbaarheid -> firewall
• repareer uw huizen -> tijdig patchen van systemen/applicaties
• controleer aan de poort
  • url filter(IIS) of mod_security (Apache)
  • IPS
• beperk de schade
  • rigoreuze segmentatie en filtering
  • ook filtering van uitgaand verkeer
  • tijdige detectie (analyseren van logs)

LBVD liet ook een voorbeeld zien van een bruteforce attack op basis van tot gisteren publiek beschikbare bron en een verzamelijk standaard wachtwoorden. Uit de bron hebben ze zo'n 2600 usernames weten te vinden en deze combineerd met een verzamelijk wachtwoorden zijn ze deze gaan proberen. Binnen een paar minuten hadden van drie gebruikers het wachtwoord gevonden.

Er zijn dus duidelijk nog verbeterpunten te vinden in de beveiling. Hoewel hier helemaal niet gekeken is naar social engeering om een username en wachtwoord van een gebruiker te verkrijgen.