Das Joom­la! Se­cu­ri­ty Team

SCREENGUIDE - - Inneres - TEXT: Da­vid Jar­din

Wie hält ein klei­nes Team ein gro­ßes CMS si­cher?

Die gro­ßen Con­tent-Ma­nage­ment-Sys­te­me brin­gen al­le Vor­aus­set­zun­gen mit, die man für ein Worst-Ca­seSze­na­rio in Sa­chen IT-Si­cher­heit braucht: ei­ne kom­ple­xe Grund­soft­ware, ei­ne Viel­zahl von Er­wei­te­run­gen, öf­fent­lich er­reich­ba­re Web­ser­ver und Nut­zer, die kein Be­wusst­sein für die Ri­si­ken ha­ben. Was wie ein Alb­traum klingt, ist das täg­li­che Brot des Joom­la! Se­cu­ri­ty Teams.

Je nach be­frag­ter Sta­tis­tik hat das PHP-ba­sier­te Con­tent-Ma­nage­ment-Sys­tem Joom­la ei­nen Markt­an­teil von knapp über drei Pro­zent an dem, was wir „das In­ter­net” nen­nen [goo.gl/LNc17e]. Bei ca. 1,3 Mil­li­ar­den Web­sites welt­weit lau­fen al­so mehr als 40 Mil­lio­nen In­ter­net­sei­ten auf Ba­sis die­ses Open-Sour­ce-Sys­tems. Für die Ent­wick­ler und die Com­mu­ni­ty ist das ei­ne rie­si­ge Er­folgs­ge­schich­te, für Si­cher­heits­for­scher, aber auch für An­grei­fer wird Joom­la, ge­nau­so wie die an­de­ren gro­ßen CMS, da­mit zum dank­ba­ren Ziel, bei dem es sich lohnt, et­was ge­nau­er hin zu­schau­en. Um die Ar­beit des Se­cu­ri­ty Teams zu ver­ste­hen, ist es wich­tig, die Mo­ti­va­ti­on un­se­rer Part­ner (oft­mals Si­cher­heits­for­scher) bzw. Ge­gen­spie­ler (der ge­mei­ne Ha­cker von ne­ben­an) zu ken­nen. Da­bei gibt es zwei grund­sätz­li­che An­rei­ze. An­er­ken­nung: Vie­le Hob­by-Si­cher­heits­for­scher, aber auch pro­fes­sio­nel­le Se­cu­ri­ty-Fir­men schmü­cken sich ger­ne mit Si­cher­heits­lü­cken, die sie in be­kann­ten Sys­te­men ge­fun­den ha­ben. Da­bei gilt: Je be­kann­ter das Sys­tem, des­to grö­ßer die An­er­ken­nung. Ei­ne Sub­form von „An­er­ken­nung” sind die so­ge­nann­ten De­fa­ce­ments, bei de­nen An­grei­fer ver­su­chen, z.B. ihr Lo­go auf mög­lichst vie­len Web­sites zu plat­zie­ren und so bei „Hack­wett­be­wer­ben” zu ge­win­nen. Die­se Wett­be­wer­be funk­tio­nie­ren in Form von On­li­ne-Platt­for­men, bei de­nen sich ein An­grei­fer (meist so­ge­nann­te „Script Kid­dies”, de­ren Se­cu­ri­ty-Wis­sen aus YoutubeTu­to­ri­als stammt) vor­ab re­gis­triert, ei­ne „Tracking­num­mer” er­hält und die­se Num­mer im Qu­ell­code von er­folg­reich an­ge­grif­fe­nen Sei­ten hin­ter­le­gen muss. Die ent­spre­chen­de On­li­ne-Platt­form ver­bucht dann ei­nen er­folg­rei­chen An­griff im Kon­to des Ha­ckers, wor­auf­hin die­ser in der glo­ba­len Rang­lis­te auf­steigt. Geld: Der schnö­de Mam­mon ist lei­der auch ein An­reiz. Für „die Gu­ten” gibt es bei vie­len Her­stel­lern so­ge­nann­ten Bug-Boun­ties, bei de­nen der Her­stel­ler für ge­mel­de­te Si­cher­heits­lü­cken ei­ne Be­loh­nung zahlt. Für die bö­sen Jungs hin­ge­gen sind ge­hack­te Web­sites ei­ne lu­kra­ti­ve Ein­nah­me­quel­le, da man die In­fra­struk­tur hin­ter der Web­site, al­so den je­wei­li­gen Web­ser­ver, her­vor­ra­gend für kri­mi­nel­le Ma­chen­schaf­ten ver­mie­ten kann. Von DDoSAtta­cken über das Hos­ting von Phis­hing Sites bis hin zu Spam sind der Fan­ta­sie hier kei­ne Gren­zen ge­setzt (sie­he In­fo­kas­ten).

Der Job für ein Se­cu­ri­ty Team ist so­mit klar: Es gilt, zum Ers­ten die Si­cher­heits­lü­cken, die z.B. von Si­cher­heits­for­schern per Mail ge­mel­det wer­den, zu sich­ten, zu prü­fen und, falls es sich um ei­nen le­gi­ti­men Re­port han­delt, schnellst­mög­lich ei­nen Patch zu ver­öf­fent­li­chen. Die Mel­der von sol­chen Si­cher­heits­lü­cken ge­ben da­bei vor­ab in der Re­gel kei­ne In­for­ma­tio­nen zu den ge­fun­de­nen Lü­cken her­aus, wo­mit nur der Mel­der selbst und das Se­cu­ri­ty Team die De­tails ken­nen. Die­ser Fall der so­ge­nann­ten Re­s­pon­si­ble Dis­clo­sure ist zu­min­dest bei Joom­la der Re­gel­fall und be­trifft über 95 % al­ler Mel­dun­gen. Pro­ble­ma­ti­scher wird es, wenn sich Si­cher­heits­for­scher nicht an die­ses er­prob­te Ver­fah­ren hal­ten und De­tails über Lü­cken be­reits vor­ab be­kannt ge­ben. Dies pas­siert ins­be­son­de­re, wenn die ge­fun­de­ne Lü­cke in ein­schlä­gi­gen In­ter­net­por­ta­len an den Meist­bie­ten­den ver­kauft wer­den soll, um dann für kri­mi­nel­le Ma­chen­schaf­ten al­ler Art ein­ge­setzt zu wer­den. Die­se Art der Ver­öf­fent­li­chung, die oh­ne Vor­lauf für die Se­cu­ri­ty Teams er­folgt, wird auch „Ze­ro-Day” ge­nannt. Der zwei­te Job für Se­cu­ri­ty Teams ist eher pro­ak­ti­ver Na­tur: durch das Über­wa­chen von „Ho­ney­pots” (spe­zi­ell prä­pa­rier­ten „An­lock­sei­ten”, sie­he In­fo­kas­ten), das Sich­ten der Sup­port­fo­ren und den Kon­takt mit Nut­zern und ins­be­son­de­re Hos­tern prü­fen wir stän­dig, ob ei­ne uns un­be­kann­te neue Lü­cke aus­ge­nutzt wird – und falls ja, gilt es, schnellst­mög­lich zu re­agie­ren.

DER MY­THOS VON DER SI­CHE­REN SOFT­WARE

Die Ar­beit geht uns da­bei nie­mals aus, denn: Je­de Soft­ware hat Si­cher­heits­lü­cken, ganz egal wie gut das Ent­wick­ler­team ist, wel­che Spra­che ver­wen­det wird oder wie vie­le prü­fen­de Au­gen vor­her auf den Code ge­wor­fen wur­den. Code wird von Men­schen ge­schrie­ben – und Men­schen ma­chen Feh­ler. Im Be­reich der We­b­ap­pli­ka­tio­nen be­glei­ten uns da­bei schon seit Jah­ren die im­mer glei­chen An­griffs­ty­pen. Das OWASP-Pro­jekt, ein ge­mein­nüt­zi­ger Zu­sam­men­schluss von Ent­wick­lern und For­schern zur Ver­bes­se­rung der Si­cher­heit von We­b­ap­pli­ka­tio­nen, er­stellt re­gel­mä­ßig ein TOP-10-Ran­king der am häu­figs­ten vor­han­de­nen Lü­cken – dar­un­ter SQL In­jec­tions, Cross-Site-Scrip­t­ing, feh­ler­haf­te Rech­te­prü­fun­gen etc. [goo.gl/G46aiW]. Für Joom­la trifft die­se Lis­te eben­falls voll und ganz zu, wo­bei das Sys­tem in der ak­tu­el­len Ver­si­on lei­der noch ei­ni­ge ar­chi­tek­to­ni­sche Alt­las­ten mit sich her­um­trägt, die es Ent­wick­lern teils un­nö­tig schwer ma­chen, si­che­re Soft­ware zu schrei­ben. So gibt es im ak­tu­el­len Ver­si­ons­zweig 3.x z.B. kei­ne Mög­lich­keit, auf die so­ge­nann­ten Pre­pa­red-State­ments zu­rück­zu­grei­fen, die un­be­fug­te Da­ten­bank­zu­grif­fe (SQL-In­jec­tions) ver­hin­dern könn­ten. Da­durch ist es Auf­ga­be des Ent­wick­lers, et­wai­ge Nut­zer­ein­ga­ben vor der Über­ga­be an die Da­ten­bank zu be­rei­ni­gen – und das kann auch der bes­te Ent­wick­ler schon mal ver­ges­sen. Er­schwe­rend kommt hin­zu, dass die gro­ßen Open-Sour­ce-Sys­te­me ein rie­si­ges Öko­sys­tem mit ei­ner Viel­zahl von Er­wei­te­run­gen um sich her­um auf­ge­baut ha­ben. Sehr vie­le die­ser Er­wei­te­run­gen wer­den da­bei von ein­zel­nen Ent­wick­lern pro­gram­miert, ein sim­pler Code-Re­view oder gar ein fun­dier­ter Se­cu­ri­ty-Au­dit fin­den nicht statt – und so wun­dert es auch nicht, dass ge­schätzt et­wa die Hälf­te der er­folg­rei­chen An­grif­fe über ver­wund­ba­re Drit­ter­wei­te­run­gen aus­ge­führt wird.

ZU­VER­LÄS­SI­GE AR­BEIT OH­NE PLANBARE RES­SOUR­CEN – UN­SER SPANNUNGSFELD

Bei Joom­la! ist das JSST (Joom­la! Se­cu­ri­ty Stri­ke Team) für die Si­cher­heit des Sys­tems zu­stän­dig. Das Team be­steht ak­tu­ell aus neun Mit­glie­dern, wo­bei es sich durch­weg um er­fah­re­ne PHP-Ent­wick­ler han­delt, die durch ih­re Ar­beit im Team ein ge­schul­tes Au­ge für ty­pi­sche Si­cher­heits­pro­ble­me ha­ben. Al­le Team-Mit­glie­der

ha­ben ei­nen „nor­ma­len” Job im Joom­la-Um­feld (z.B. als Agen­turMit­ar­bei­ter oder Ex­ten­si­on-Ent­wick­ler) und ar­bei­ten im JSST eh­ren­amt­lich in ih­rer Frei­zeit. Wir ha­ben so­mit nur re­la­tiv we­nig ver­füg­ba­re Res­sour­cen in Form von Ar­beits­zeit, müs­sen aber ei­ne stän­di­ge Ver­füg­bar­keit und ex­trem kur­ze Re­ak­ti­ons­zei­ten ge­währ­leis­ten. Aus die­sem Grund hat das Joom­la-Pro­jekt zwei se­pa­ra­te Teams im Be­reich Se­cu­ri­ty: das JSST be­treut den Joom­la Co­re selbst so­wie die joom­la.org-Web­sites. Ein se­pa­ra­tes Team be­treut die men­gen­mä­ßig deut­lich grö­ße­re An­zahl von Si­cher­heits­mel­dun­gen zu Ex­ten­si­ons, spricht mit den Ent­wick­lern und bie­tet dort Hil­fe an. War­um zwei ver­schie­de­ne Teams, an­statt die Ar­beits­kraft an ei­ner Stel­le zu bün­deln? Nun, ins­be­son­de­re bei dem Team, das den Joom­la-Co­re be­treut, wer­den Lü­cken, wie be­reits er­wähnt, ver­trau­lich ge­mel­det und müs­sen dann um je­den Preis ge­heim ge­hal­ten und im Hin­ter­grund be­ar­bei­tet wer­den. Je klei­ner al­so das Team ist, das Zu­gang zu den In­for­ma­tio­nen hat, des­to bes­ser für die Si­cher­heit. Ei­ne an­de­re, für un­se­re Ar­beit re­le­van­te Res­sour­ce ist da­bei das The­ma Geld. Wie ein­gangs be­reits er­wähnt ge­win­nen so­ge­nann­te Bug-Boun­ties, bei de­nen ei­ne Be­loh­nung für ge­mel­de­te Lü­cken ge­zahlt wird, zu­neh­mend an Po­pu­la­ri­tät. Für un­ser Pro­jekt hin­ge­gen wer­den die Nach­tei­le der Boun­ties spür­bar: oh­ne gro­ßen Her­stel­ler (Au­to­mat­tic bei Word­Press, Ac­quia bei Dru­pal) oder ei­ne fi­nanz­kräf­ti­ge Foun­da­ti­on im Hin­ter­grund kön­nen wir uns ein sol­ches An­reiz­pro­gramm fi­nan­zi­ell schlicht nicht leis­ten, wo­durch wir für Si­cher­heits­for­scher un­at­trak­ti­ver wer­den. Be­sorg­nis­er­re­gen­der sind je­doch die Fäl­le, in de­nen Mel­der über ei­ne ge­fun­de­ne Si­cher­heits­lü­cke be­rich­ten, De­tails je­doch nur ge­gen Zah­lung raus­ge­ben wol­len – ein Mecha­nis­mus, der seit der Ein­füh­rung der Bug-Boun­ties zu­ge­nom­men hat.

VOM RE­PORT ZUM PATCH

Geht ei­ne neue Mel­dung ein, wird die­se an­hand der in­tern do­ku­men­tier­ten „Stan­dard Ope­ra­ting Pro­ce­du­res” be­ar­bei­tet, ein aus­for­mu­lier­ter Pro­zess, der si­cher­stellt, dass kei­ne wich­ti­gen Schrit­te ver­ges­sen wer­den. Der ers­te Schritt ist da­bei lei­der nur in den we­nigs­ten Fäl­len das Ent­schlüs­seln der De­tails zur Lü­cke, denn ob­wohl der PGP-Key des Teams öf­fent­lich ein­seh­bar ist und der In­halt oft ei­ne ge­wis­se Bri­sanz hat, wer­den nur er­schre­ckend we­nig Mel­dun­gen ver­schlüs­selt über­sen­det. Der nächs­te Schritt ist die so­ge­nann­te Tria­ge der Mel­dung: Ist der Re­port plau­si­bel? Kann die Lü­cke mit den ge­lie­fer­ten In­for­ma­tio­nen nach­voll­zo­gen wer­den? Und die wich­tigs­te Fra­ge: Wie gra­vie­rend ist die Lü­cke? Die­se ers­te Ein­schät­zung über­nimmt oft­mals das Te­am­mit­glied, in des­sen Zeit­zo­ne gera­de „Ar­beits­zeit” ist. Hier ist es prak­tisch, dass die Mit­glie­der des JSST über drei Kon­ti­nen­te ver­teilt sit­zen und per Chat und Ti­cket-Sys­tem kom­mu­ni­zie­ren; es ist qua­si im­mer je­mand wach und ver­füg­bar. Je nach­dem, wie schwer die Lü­cke ist, er­gibt sich das wei­te­re Vor­ge­hen. Wenn es sich zum Bei­spiel um ei­ne SQL-In­jec­tion han­delt, recht­fer­tigt dies ein ei­ge­nes Emer­gen­cy-Re­lease au­ßer­halb des nor­ma­len Ver­si­ons­rhyth­mus. Falls es uns ver­tret­bar er­scheint, war­ten wir da­bei mit dem Re­lease ca. 72 St­un­den und sen­si­bi­li­sie­ren die Nut­zer mit ei­ner Vor­ab-An­kün­di­gung des Pat­ches. In der Re­gel ist der zu­ge­hö­ri­ge Patch da­bei längst fer­tig, und die Re­lease-Pa­ke­te ste­hen be­reit, da­mit, falls die Lü­cke doch vor­ab be­kannt wer­den wür­de, so­fort ein Up­date zur Ver­fü­gung steht.

We­ni­ger kri­ti­sche Lü­cken, al­so z.B. Lü­cken, die ei­nen le­sen­den Zu­griff auf ei­gent­lich ge­sperr­te CMS-Ar­ti­kel er­lau­ben, wer­den im Rah­men der nor­ma­len Patch-Zy­klen be­ho­ben, wo­bei die ent­spre­chen­den Lü­cken mit dem zu­stän­di­gen Re­lease-Le­ad und, hier wird es kom­pli­zier­ter, teils auch mit den Über­set­zungs­teams ko­or­di­niert wer­den müs­sen. Die Ent­schei­dung, ob ei­ne Lü­cke mehr oder we­ni­ger kri­tisch ist, ist manch­mal nicht ganz ein­fach – hier hilft uns un­se­re Se­cu­ri­ty-Po­li­cy, in der, so­weit mög­lich, har­te Kri­te­ri­en für die Ein­stu­fung fest­ge­legt sind [goo.gl/bboz­kn]. Ein Son­der­fall sind die be­reits an­ge­spro­che­nen Ze­ro-Day-Ex­ploits, der Alb­traum ei­nes je­den Se­cu­ri­ty Teams: Wenn die Lü­cke be­reits be­kannt ist, be­vor ein Patch zur Ver­fü­gung steht, ha­ben Nut­zer kei­ne Mög­lich­keit, sich zu schüt­zen. Hier gilt es, so schnell wie ir­gend mög­lich die ent­spre­chen­de Lü­cke zu re­kon­stru­ie­ren und ei­nen Patch zur Ver­fü­gung zu stel­len. Ein po­pu­lä­res Bei­spiel ist CVE-20151206, ei­ne Re­mo­te-Code-Exe­cu­ti­on-Lü­cke in Joom­la, die durch ei­nen PHP-Bug ver­ur­sacht wur­de [goo.gl/93ACsz]. Hier ver­gin­gen vom ers­ten Re­port ei­nes ver­däch­ti­gen Log­files durch ei­nen Hos­ter bis zum Patch we­ni­ger als 14 St­un­den.

DIE NUT­ZER: DAS SCHWÄCHS­TE GLIED IN DER KET­TE

Nach der Ver­öf­fent­li­chung des Se­cu­ri­ty-Re­lea­ses ist das wei­te­re Vor­ge­hen für uns in der Theo­rie ganz sim­pel: Wir be­ob­ach­ten über den in Joom­la in­te­grier­ten Sys­tem­sta­tis­tik-Di­enst, der ein durch­ge­führ­tes Up­date an joom­la.org mel­det, wie die Nut­zer al­le flei­ßig bin­nen kür­zes­ter Zeit den Patch ein­spie­len, über­wa­chen un­se­re Ho­ney­pots, um die ver­schie­de­nen Va­ria­tio­nen des An­griffs nach­ver­fol­gen zu kön­nen, und freu­en uns, dass al­le Joom­la-Sei­ten wie­der si­cher sind. Lei­der zeigt es sich, dass die­se Theo­rie in der Pra­xis ei­nen gro­ßen Schwach­punkt hat: Nut­zer ak­tua­li­sie­ren ih­re Sei­ten ex­trem lang­sam! Um zu ver­ste­hen, was „lang­sam” in die­sem Kon­text be­deu­tet, muss man sich zwei Zah­len vor Au­gen füh­ren. So­bald ein Si­cher­heits-Patch für ei­nes der gro­ßen Sys­te­me ver­öf­fent­licht wird, star­ten An­grei­fer da­mit, den je­wei­li­gen Patch zu un­ter­su­chen und die dar­in ge­schlos­se­ne Lü­cke zu re­kon­stru­ie­ren – ist die Lü­cke dann ge­fun­den, star­ten die An­grif­fe. Span­nend ist da­bei, dass der Zei­t­raum zwi­schen „Ver­öf­fent­li­chung des Pat­ches” und „ers­ter au­to­ma­ti­sier­ter An­griff” für die be­kann­ten CMS in­zwi­schen auf ma­xi­mal acht St­un­den ge­sun­ken ist. Mit an­de­ren Wor­ten: Wer nicht bin­nen zehn St­un­den das Up­date ein­ge­spielt hat, wird mit ho­her Wahr­schein­lich­keit er­folg­reich an­ge­grif­fen wer­den. Die zwei­te re­le­van­te Zahl, die zu­gleich das Pro­blem ver­deut­licht, ist, dass wir mit den vor­lie­gen­den Zah­len da­von aus­ge­hen, dass nur et­wa 12 % der Nut­zer ih­re In­stal­la­tio­nen bin­nen der ers­ten 24 St­un­den ak­tua­li­sie­ren – auch wenn das Se­cu­ri­ty Team al­les rich­tig macht, bleibt al­so ei­ne ho­he An­zahl an Nut­zern ver­wund­bar, was un­se­re Ar­beit oft­mals frus­trie­rend macht.

WE­GE AUS DER MI­SE­RE

Um die­ses Pro­blem zu lö­sen, gibt es ei­ne prag­ma­ti­sche Lö­sung: Au­to­ma­ti­sche Up­dates! Die Kol­le­gen von Word­Press ha­ben ei­ne ent­spre­chen­de Funk­ti­on in­te­griert und nut­zen die­se mit gro­ßem Er­folg. Un­ter Si­cher­heits­as­pek­ten aber brin­gen au­to­ma­ti­sche Up­dates ei­ne neue Pro­ble­ma­tik mit sich: Was pas­siert, wenn es ei­nem An­grei­fer ge­lingt, den zen­tra­len Up­date-Ser­ver ei­nes CMS un­ter sei­ne Kon­trol­le zu brin­gen und ein in­fi­zier­tes Up­date aus­zu­rol­len? Die­ses Sze­na­rio ist kei­nes­falls abs­trakt, son­dern in der „klas­si­schen” Soft­ware viel­fach aus­ge­nutzt wor­den. Die tech­ni­schen Lö­sun­gen da­für (kryp­to­gra­fisch si­gnier­te Up­dates, Stich­wort „li­b_­so­di­um”) sind zwar in neue­ren PHP-Ver­sio­nen vor­han­den, da Joom­la je­doch auch noch äl­te­re PHP-Ver­sio­nen und teils exo­ti­sche Ser­ver­kon­fi­gu­ra­tio­nen un­ter­stüt­zen muss, sind die Ent­wick­ler hier bis­her noch zu­rück­hal­tend. Statt­des­sen ver­fol­gen wir ei­nen et­was an­de­ren An­satz: Im Rah­men des Pro­jekts SIWECOS, das von ei­nem Zu­sam­men­schluss aus dem eco Ver­band, der Ruhr-Uni Bochum, dem IT-Se­cu­ri­ty­Start-up hack­ma­nit und dem CMS Gar­den ge­tra­gen und vom Bun­des­wirt­schafts­mi­nis­te­ri­um ge­för­dert wird, in­for­mie­ren wir die gro­ßen und klei­nen Web­hos­ter über die ent­spre­chen­den Pat­ches, die be­ho­be­nen Lü­cken und ge­ben vor al­lem In­for­ma­tio­nen mit, ob und wenn ja, wie et­wai­ge An­grif­fe ge­zielt auf Ser­ver­ebe­ne her­aus­ge­fil­tert wer­den kön­nen [siwecos.de]. Für die Pro­vi­der er­gibt sich hier ein gro­ßes Ein­spar­po­ten­zi­al, da ge­hack­te Kun­den­web­sites viel Sup­port­auf­wand er­zeu­gen, und für uns als Se­cu­ri­ty Team bie­tet sich hier die Mög­lich­keit, an zen­tra­ler Stel­le ei­ne Schutz­bar­rie­re auf­zu­bau­en, die Nut­zer selbst dann schützt, wenn sie ih­re Sites nicht zeit­nah ak­tua­li­siert ha­ben. De­ren Web­sites sind dann zwar in der Theo­rie nach wie vor für die An­grif­fe an­fäl­lig, durch die ser­ver­sei­ti­ge Fil­te­rung kön­nen die­se Atta­cken aber nicht mehr bis zum CMS vor­drin­gen. Die­sen An­satz ha­ben wir da­bei in den letz­ten zwei Jah­ren er­folg­reich er­probt und bie­ten ihn nun in Zu­sam­men­ar­beit mit den Se­cu­ri­ty Teams von Word­Press, Dru­pal, TYPO3, Con­tao und Um­bra­co auf ei­ner ein­heit­li­chen Platt­form an [goo.gl/Ds­kT5S].

UN­SE­RE AR­BEIT: DIE QUADRATUR DES KREI­SES

Die Ar­beit ei­nes Se­cu­ri­ty Teams für ein Open-Sour­ce-Pro­jekt er­for­dert, dass Din­ge mit­ein­an­der in Ein­klang ge­bracht wer­den müs­sen, die ei­gent­lich un­ver­ein­bar sind: ein re­la­tiv klei­nes Team aus un­be­zahl­ten Eh­ren­amt­lern soll ei­ne stän­di­ge Ver­füg­bar­keit ge­währ­leis­ten, zu je­der Ta­ges- und Nacht­zeit fun­dier­te Ein­schät­zun­gen lie­fern und da­bei in je­der noch so zeit­lich kri­ti­schen Si­tua­ti­on ei­nen küh­len Kopf be­wah­ren. Neun Per­so­nen ar­bei­ten hoch­pro­fes­sio­nell an der Si­cher­heit von 40 Mil­lio­nen Web­sites und sto­ßen da­bei im­mer wie­der auf die man­geln­de Awa­ren­ess bei Nut­zern wie Ent­wick­lern. Für an­de­re ein Alb­traum, für mich hin­ge­gen ein Traum­job!

Abb. 1: Joom­la-Web­site mit er­folg­rei­chem De­fa­ce­ment durch ei­nen An­grei­fer

Abb. 2: Vor­ab-An­kün­di­gung ei­nes kri­ti­schen Joom­la-Up­dates auf joom­la.org

Abb. 3: Dis­kus­si­on zum Re­ver­se-En­gi­nee­ring ei­nes Joom­la-Pat­ches beim Ex­ploit-Frame­work Met­as­ploit.

Newspapers in German

Newspapers from Germany

© PressReader. All rights reserved.