Aanvallers hacken servers van Apache
Eerder deze maand hebben aanvallers zich toegang verschaft tot een aantal servers van Apache.org.
Eerder deze maand hebben aanvallers zich toegang verschaft tot een aantal servers van Apache.org.
Aanvallers hacken servers van Apache
Eerder deze maand hebben aanvallers zich toegang verschaft tot een aantal servers van Apache.org.
De Apache Foundation doet uitgebreid verslag van de hack op het blog van het Apache Infrastructure Team. De aanvallers hebben een Atlassian JIRA issue tracker server gehackt met een combinatie van cross site scripting en brute force.
Na een dag had die aanval succes en kregen de aanvallers admin toegang tot een JIRA account. Daar konden ze de waarschuwingen uitzetten en paden voor het uploaden van attachments veranderen.
Achterdeur
Ze maakten kopieën van /home directory’s van verschillende gebruikers en voegden JavaServer Pages (JSP) files toe waardoor ze achteringangen kregen tot het systeem. Vervolgens verzamelden ze meer wachtwoordcombinaties door het verzenden van reset mails. Met die wachtwoorden kregen ze vervolgens ook nog volledige sudo-toegang tot brutus.apache.org, de machine waarop JIRA, Confluence en Bugzilla van Apache worden gehost.
Van daaruit kregen ze vervolgens ook nog toegang tot minotaur.apache.org, en ook daar konden ze hun rechten uitbreiden. Toen ze wachtwoorden gingen resetten werden ze echter opgemerkt, waarna de beheerders de diensten neerhaalden. Vervolgens werd ook Atlassian nog direct aangevallen.
Niet de eerste keer
Het Apache team laat ook nog weten wat erger heeft voorkomen, zoals het gebruik van one time passwords. Maar ook wat er mis is gegaan. Zo had nooit hetzelfde wachtwoord gebruikt mogen worden voor het JIRA account en voor het sudo-account op brutus.apache.org.
Alle gebruikers van JIRA, Bugzilla en Confluence worden gewaarschuwd dat hun wachtwoorden op straat kunnen liggen, en dat ze veranderd moeten worden.
Nog geen jaar geleden werd minotaur ook al gehackt. Apache wordt geprezen voor de professionele manier waarop ze de aanvallen aanpakken en voor de openhartigheid waarop ze over de succesvolle aanvallen belichten.
Bron: Techworld.nl
Zoek de verschillen.
Zoek eens op jira.atlassian.com naar termen zoals SSL, Kerberos, LDAP, AD, en lees de instructies hoe je dat configureert en de bugs die daar bij gevonden worden. Dan snap je wel wat ik bedoel.
Het kan ook zijn dat persoonlijke ervaring met deze producten mijn voorkeur heeft versterkt...
laten we het maar houden op: Citation needed.
Ik heb sterk de indruk dat je beeld een beetje verkleurd is door je persoonlijke voorkeur en je grotere ervaring met dat voorkeursproduct.
Dat zeg ik helemaal niet, AD is maar één manier. Het gaat er om dat de beheerder van zo'n systeem eenvoudig moet kunnen configureren welke authenticatie de web applicatie gebruikt en dat de implementatie daarvan dan ook echt goed is.
Je configureert voor een ASP.NET web applicatie over het algemeen een MembershipProvider, die kan AD gebruiken maar ook ADAM, LDAP, een SQL Database, OpenID of wat dan ook. Authenticatie is op die manier ontkoppeld van de applicatie, de beheerder bepaalt wat hij wil gebruiken en de programmeur programmeert tegen de Membership Interface.
Als je de gebruikers graag in een database wilt dan volg je bijvoorbeeld deze instructies en zou de inbraak zoals hier heeft plaatsgevonden ook veel moeilijker zijn: geen database accounts in config bestandjes, je hebt password encryptie en een lockout policy en alles wordt standaard aangereikt zo dat het veilig is en goed werkt. Zonder veel moeite.
In Linux/Apache omgevingen bestaan ook dat soort mechanismen, maar die zijn in mijn ervaring gewoon kwalitatief minder goed, ze zijn veel moeilijker te implementeren en er ontstaan vaak functionele problemen in de web applicatie als je de omgeving echt veilig gaat configureren. Veel open source webapplicaties worden nauwelijks getest in veilige configuraties (ssl, kerberos, AD etc).
Hoe kom je daar toch bij? denk je nu werkelijk dat elke webapplicatie op IIS gebruik maakt van AD?
Als je van te voren exact weet wie je gebruikers zijn, dan is een inrichting via AD een goede oplossing. Maar bij open systemen waarbij een (in principe) ongelimiteerd aantal gebruikers lid kan worden snap je toch ook wel dat AD teveel van het goede is?
Volgens mij is AD perfect in bedrijfsomgevingen, omdat je daar kan uitgaan van kennis van je begruikersgroep, maar op het grote boze internet valt dat voordeel weg. Ik denk zelfs dat Apache daar iets beter is omdat het flexibeler is.
Inderdaad. In de bron staat exact het tegenover gestelde dan in de vertaling. Iemand even op engels-les sturen?
Gemakzucht dient inderdaad de mens, dat is precies het probleem: de mogelijkheden die jij aandraagt zijn onder Linux/Apache niet gebruikelijk en default, want ze vragen Windows of een ander extern systeem. De Apache gebaseerde web applicaties die ik ken hebben hun eigen authenticatie ingebouwd en slaan passwordgegevens op in een eigen database. Als je zo'n applicatie werkend wilt krijgen tegen AD en er een proxy/firewall voor wilt plaatsen is het mijn ervaring dat dat veel praktische problemen oplevert: antwoorden zijn nauwelijks te vinden want niemand uit de community past dat toe.
Ook moeten er vaak passwords in config bestandjes gezet worden, die dan zomaar ergens bij die applicatie staat. Eén kleine programmeerfout of configuratiefout van de beheerder en de zaak ligt helemaal open.
Ik zeg niet dat het onmogelijk is om veilige webapplicaties te maken en configureren, maar je moet er als beheerder en developer van Apache/Linux web applicaties meer moeite voor doen dan onder Windows/IIS.
Je kan Apache onder linux ook via PAM en winbind/kerberos een AD authentication doen. Er zijn veel mogelijkheden, ook zonder AD.
Dat web applicaties voor het Microsoft platform veel minder gevoelig zouden zijn voor het soort aanvallen, is dus een beetje onzin.
Gemakzucht dient de mens nietwaar?
Ik heb het idee dat met jouw oplossingsrichting door een Administrator voor elke gebruiker, die zich aanmeld op de website als geïnteresseerde, een AD account moet worden gemaakt. Dat zou een optie kunnen zijn, maar het lijkt mij wat overkill.
En heel eerlijk gezegd, denk ik dat er genoeg applicaties zijn die daar niet aan beginnen. Die gebruiken een standaard user om de database te benaderen en zetten de gebruikers gewoon in een bestand.
Dus ze hadden beter kunnen zwijgen, totdat het bewijs overduidelijk zou zijn geworden, waarna er nog meer claims zouden komen?
Nee, ik denk toch echt dat dit de beste weg is.
Het probleem is dat dit blijkbaar verschillende dingen zijn en de applicatie zijn eigen authenticatie doet (met alle bugs van dien). Als je voor beide soorten AD accounts gebruikt zou hebben had ook de webapplicatie de beveiligings mechanismen daarvan meegekregen.
En als ze Windows Integrated Authentication gebruikt hadden dan waren er geen passwords in clear text naar de webapplication gegaan en was de aanval eerder doodgelopen.
Ik vind het ook goed dat ze dat doen. Maar vraag me ook af of ze zich niet erg kwetsbaar maken voor rechtszaken: als ze zo openlijk toegeven dat ze het verkloot hebben dan kan iedere malloot op wiens facebook (met datzelfde password) opeens rare foto's zijn verschenen of wiens online bankrekening geplunderd is hen nu aansprakelijk stellen en schade claimen. Ze hebben hun nalatigheid nu al toegegeven.
Als ik het blog goed lees gebeurt dat bij Apache net zo goed. Alleen probeerden ze niet in te loggen op een account, maar op een webapplicatie. Het hangt dan maar net af van de programmeur en de settings of een bruteforce gaat werken.
Apache, JIRA en Confluence (van Atlassian) kunnen ook op Windows draaien. Linux of Apache zijn hier het probleem niet, maar de software van Atlassian zit m.i. niet erg veilig in elkaar. Met die applicaties is volgens mij echt wel wat meer aan de hand. Bij Atlassian zelf zijn ook een aantal servers gehackt en is o.a. een unencrypted user/password database buit gemaakt.
Ik zal hier niet zeggen dat Linux onveilig is, maar durf best te stellen dat goed gemaakte web applicaties voor het Microsoft platform veel minder gevoelig zijn voor het soort aanvallen zoals die hier hebben plaatsgevonden. Dat een bruteforce aanval succesvol is geeft al te denken: als je op een Windows AD account een keer te vaak met een verkeerd wachtwoord in probeert te loggen wordt dat account automatisch gelockt. Gebruik van Integrated Windows Authentication maakt dat de web applicatie nooit gebruikers passwords ontvangt in clear text, wat o.a. het probleem van de aangepaste login pagina voorkomt. Integrated Security maakt ook dat je niet het password voor bv de database in een config file hoeft vast te leggen doordat dat de security context van de web applicatie transparant gebruikt wordt als database login.
Sander, is dit jou vertaling van dit: ?
het is cracken, of kraken of inbreken. Hacken heeft niets met deze aanval te maken.
Waarschijnlijk omdat de hier gebruikte methode volledig losstaat van het os. Voor een fout in een applicatie en een niet goed afgevangen bruteforce zou elk platform in principe even kwetsbaar zijn.
Ik wilde eigenlijk roepen:
zie je wel dat linux OOK onveilig is
maar ik ben goed opgevoed door mijn ouders (en ook erg bang voor de minduivel).
Ik zit eigenlijk te wachten op de eerste mongool die komt roepen "zie je wel dat linux onveilig is?" Verrassend dat ie nog niet is langsgekomen.
Het zal de persoon in kwestie wel niet zo boeien, dat hele stemgebeuren. Kan ik best begrip voor opbrengen. Het is en blijft een verdomd handige manier om snel te kunnen zien wat je wel of niet gelezen hebt :-)
Ik kan het natuurlijk mis hebben, voor hetzelfde geld (en dat is dus nooit duurder) is het gewoon een derderangs mongool eersteklas.
De grote min-kukel heeft deze topic ook weer bezocht zo te zien. =P Welk plezier zo iemand toch beleeft aan het minnen van alle reacties?
Uit het blog:
JIRA leek gevoelig te zijn voor cross site scripting, maar als ik het blog goed begrijp heeft Atlassian direct gereageerd.
Als je JIRA gebruikt zou ik daar dus even goed op letten.
Dat verdient enige toelichting. Uit de context neem ik aan dat het hier niet over lokale installaties gaat, maar alleen de op de Apache.org gehoste installaties. Met andere woorden: er is (in dit specifieke geval) geen sprake van een exploit in de produkten Jira, Bugzilla en Confluence. Kan iemand dit bevestigen?
Fouten kunnen gebeuren.
Maar Apache laat wel zien op welke manier je zoiets naar buiten hoort te brengen. Gewoon openheid van zaken geven en het niet meer fout proberen te doen. Geen dingen achterhouden of proberen eruit te lullen.
Jammer dat het is gebeurd. Lering uit trekken en verder gaan met het maken van mooie serversoftware *O*
Reageer
Preview