Joomla är ett populärt open source (CMS) innehållshanteringssystem (öppen källkod) och används av 5.8% av alla sajter som använder någon form av CMS. Andra populära CMS:er är WordPress och Drupal.
Nu har version 3.8.12 av Joomla släppts som innehåller följande tre säkerhetsfixar:
Low Priority – Core – Hardening the InputFilter for phar stubs (affecting Joomla 1.5.0 through 3.8.11) More information »
Low Priority – Core – Stored XSS vulnerability in the frontend profile (affecting Joomla 1.5.0 through 3.8.11) More information »
Low Priority – Core – ACL Violation in custom fields (affecting Joomla 3.7.0 through 3.8.11) More information »
Som du ser ovan så är ingen av dessa sårbarheter allvarliga men rekommendationen är ändå att uppgradera snarast. Standard så uppgraderas inte Joomla automatiskt utan du måste logga in och trycka på en knapp för att uppgraderas.
Detta är en historia om hur min säkerhetsloggning som bl.a. bygger på OSSEC identifierade ett intrång på en av mina webbservrar.
OSSEC är öppen källkod och går under licensen GNU GPLv2 och utvecklades från början av Daniel Cid och företaget Third Brigade som sedermera blev uppköpta av Trend Micro. Dock så lovade Trend Micro att fortsätta hålla OSSEC som öppen källkod, vilket det fortfarande är.
OSSEC är en mjukvara som går under kategorin HIDS (host-based intrusion detection system) och har bl.a. funktioner för att analysera loggfiler efter suspekta mönster, detektera rootkits och utföra aktiva åtgärder såsom att blockera i brandvägg.
Det går att installera OSSEC som fristående installationer på varje server och sedan skicka vidare larm med hjälp av rsyslog, syslog-ng eller filebeat (föredetta logstash-forwarder) eller använda OSSEC:s inbyggda funktionalitet för att skicka loggar krypterat. Det finns även Windows-klienter till OSSEC.
Jag har konfigurerat OSSEC som en tripwire-funktionalitet, dvs att OSSEC kontrollerar checksummor på viktiga filer. Eftersom många webbattacker går ut på att modifiera webbsidor så har jag även lagt in så att OSSEC-larmar på förändringar i filer som ligger under webbkataloger. Standard så kontrollerar OSSEC enbart integritet på ett antal viktiga systemfiler, därför är det viktigt att lägga till ytterligare filer som du vill hålla koll på.
Jag brukar lägga till ungefär följande rad i /var/ossec/etc/ossec.conf filen:
Och även följande rad om du vill larma på nya filer:
<alert_new_files>yes</alert_new_files>
Skulle du få många nya larm om temporära filer som skapas i någon katalog så kan du alltid lägga ignore på den katalogen enligt följande:
<ignore>/var/www/katalognamn</ignore>
Men observera dock vilken katalog du ignorerar så inte det går att utnyttja av en angripare.
Vidare bör du ställa ner intervallet då övriga filer kontrolleras som är standard på 22h. Du gör det med följande rad i ossec.conf:
<frequency>14400</frequency>
Även så måste du ändra följande fil: /var/ossec/rules/local_rules.xml och lägga till följande rad för att få larm om nya filer:
<rule id=”554″ level=”7″ overwrite=”yes”>
<category>ossec</category>
<decoded_as>syscheck_new_entry</decoded_as>
<description>File added to the system.</description>
<group>syscheck</group>
</rule>
Det är för att regeln med id 554 standard är satt som level=”0″ vilket betyder att du inte får några larm.
Intrånget
Det larm som dök upp från OSSEC som fick mig att höja på ögonbrynen är följande:
Den som är observant på ovan larm ser att includ_once() är en felstavning av PHP-funktionen include_once(). Givetvis så kontrollerade jag filen manuellt och upptäckte då att någon hade manuellt modifierat footer.php. Detta är ett vanligt förekommande förfarande när det gäller hackade WordPress-installationer.
Efter vidare undersökning så identifierade jag Filesman-phpbakdörren men även en till bakdörr. Denna bakdörr la jag in min egen bakdörr i så att den loggade alla försök att utnyttja bakdörren samt att lösenordet till bakdörren loggades. Om du är intresserad av bakdörrar till php så kan du kolla in min samling på Github Gist här.
Du kan med fördel även importera larm från OSSEC till Splunk eller ELK-stacken (Elasticsearch, Logstash och Kibana).
En ny version av WordPress har just släpps som åtgärdar ett antal olika säkerhetsbrister. WordPress är ett av världens vanligaste CMS och har cirka 60 miljoner installationer.
För några timmar sedan så släpptes version 4.7.1 som åtgärdar följande säkerhetsproblem:
Remote code execution (RCE) in PHPMailer – Verkar inte gå att utnyttja i WordPress men som säkerhetsåtgärd så uppdateras den version av phpmailer som skickas med i WordPress.
The REST API exposed user data for all users who had authored a post of a public post type. WordPress 4.7.1 limits this to only post types which have specified that they should be shown within the REST API. Reported by Krogsgard and Chris Jean.
Cross-site scripting (XSS) via the plugin name or version header on update-core.php. Reported by Dominik Schilling of the WordPress Security Team.
Cross-site request forgery (CSRF) bypass via uploading a Flash file. Reported by Abdullah Hussam.
Cross-site scripting (XSS) via theme name fallback. Reported by Mehmet Ince.
Post via email checks mail.example.com if default settings aren’t changed. Reported by John Blackbourn of the WordPress Security Team.
A cross-site request forgery (CSRF) was discovered in the accessibility mode of widget editing. Reported by Ronnie Skansing.
Weak cryptographic security for multisite activation key. Reported by Jack.
För de flesta så uppdateras WordPress automatiskt men det är alltid bra att dubbelkolla så du har senaste versionen installerad.
Dawid Golunski från Legal Hackers har upptäckt en ny allvarlig säkerhetsbrist i det populära biblioteket PHPMailer som används av miljontals mjukvaror såsom WordPress, Drupal, 1CRM, SugarCRM, Yii och Joomla.
Samtliga versioner innan 5.2.18 är sårbara för denna RCE (remote code execution). I dagsläget har Dawid ej släppt några detaljer om denna brist men troligtvis så rör det sig bara om timmar innan sårbarheten börjar att utnyttjas på internet.
En förmildrande faktor är att du måste ha ett kontaktformulär som använder sig av biblioteket. Samt så får angriparen samma behörigheter som användaren som webbservern körs som.
Denna sårbarhet har fått CVE-2016-10033, läs mer här.
Uppdatering: Tittar jag närmare på den commit som åtgärdar säkerhetsproblemet så ser den ut så här:
if (!empty($this->Sender) and $this->validateAddress($this->Sender)) {
$params = sprintf('-f%s', escapeshellarg($this->Sender));
}
Dvs escapeshellarg()-funktionen läggs till. Troligtvis för att avsändaremail -f skickas med ut till sendmail i commandline och gör det då möjligt att köra kommandon.
Uppdatering 2: Nu har Legal Hackers släppt en proof-of-concept exploit samt förklaring till sårbarheten. Och det är precis som vi anade ovan att extra data kan skickas vidare, dock inte helt enkelt som förklarat ovan:
Genom att skicka följande som avsändarepost:
”Attacker \” -Param2 -Param3″@test.com
Och detta skickas vidare till PHPMailer (och även mail()) så exekveras sendmail lokalt med följande argument:
Amerikanska myndigheten FBI har gått ut och varnat för att den Islamiska staten (ISIS) eller sympatisörer till ISIS använder en ny sårbarhet i WordPress för att genomföra intrång.
Sårbarheten som ISIS använder sig av är relativt ny och återfinnes i pluginet WP Super Cache. Pluginet är mycket populärt och används av över en miljon webbsajter samt har laddats hem över 130 000 gånger bara förra veckan.
Dock så är sårbarheten en XSS där en användare eller administratör av WordPress-sajten besöka en länk som skickas via E-post exempelvis.
Ovan är en skärmdump tagen av Sucuri som påvisar hur $details[ ‘key’ ] används felaktigt utan kontroll för att byta ut information.
Säkerhetstips
Det finns många bra tips för att se till att WordPress är säkert, men främsta tipset är att hålla Er installation uppdaterad. Just denna sårbarhet är åtgärdad i senaste versionen som är 1.4.4. Se även till att aktivt testa säkerheten i WordPress, läs exempelvis här hur du kan göra eller med Detectify.
Nate Lawson som bloggar på http://rdist.root.org/ har uppmärksammat att WordPress.com inte använder SSL session resumption vilket gör att de måste räkna om nycklarna (2048-bit RSA decryption) för varje liten bit som går över linjen.
WordPress version 2.5.1 släpps till följd av att en kryptobugg i Cookie-hanteringen gör det möjligt beräkna den HMAC som används för säkerställa att rätt användare är inloggad:
The authentication mechanism assumes that an attacker cannot calculate the HMAC. However, this assumption is broken because the two inputs used to calculate the HMAC (username and expiration) are not clearly delineated.
Undrar du vad HMAC är? Förklaring enligt Wikipedia:
In cryptography, a keyed-Hash Message Authentication Code (HMAC or KHMAC), is a type of message authentication code (MAC) calculated using a specific algorithm involving a cryptographic hash function in combination with a secret key. As with any MAC, it may be used to simultaneously verify both the data integrity and the authenticity of a message. Any iterative cryptographic hash function, such as MD5 or SHA-1, may be used in the calculation of an HMAC; the resulting MAC algorithm is termed HMAC-MD5 or HMAC-SHA-1 accordingly. The cryptographic strength of the HMAC depends upon the cryptographic strength of the underlying hash function, on the size and quality of the key and the size of the hash output length in bits.
