gmc: Der Modul Helfer

nospam@example.com (Daniel) — Sun, 21 Oct 2007 22:08:00 +0200

Alle die schonmal unter Gentoo die Modul-Namen in der Datei /etc/modules.autoload.d/kernel-2.6 eintragen mussten, wissen wie unangenehm diese Aufgabe sein kann, wenn es viele Module gibt die einzutragen sind.

Um sich hier die Arbeit zu erleichtern, habe ich ein kleines Shell-Script geschrieben, welches mit Hilfe der BASH oder der Korn Shell einem hier diese lästige Arbeit abnimmt:

root@gentoo:~ # vi /sbin/gmc

# !/bin/bash
# Copyright 2006-2007 RemoteShell-Security.com
# Distributed under the terms of the GNU General Public License v2
# title: gmc

mf=/etc/modules.autoload.d/kernel-2.6

#clear
rm -rf $mf
rm -rf /tmp/gmc 2>/dev/null

#file header:
echo '# /etc/modules.autoload.d/kernel-2.6:  kernel modules to load when system boots.'>${mf}

if [ $1 ]
 then
 kpath=$1
 find /lib/modules/${kpath}/ -type f -iname '*.o' -or -iname '*.ko' >/tmp/gmc
 while read var; do
 tn=${var##*/}
 echo ${tn%.ko} >>${mf}
 done < /tmp/gmc
else
echo "usage: gmc <name of current kernel version>"
fi

rm -rf /tmp/gmc 2>/dev/null

Die Benutzung des Scripts ist auch realtiv einfach. Das Script erwartet beim Aufruf nur als Parameter den Namen der Kernel Version aus welcher man die Module laden möchte.

Weiß man den Namen nicht auswendig, so schaut man einfach unter /lib/modules/ nach. Es sei noch darauf hingewiesen, das für Ausführung in der Regel Root-Rechte benötigt werden.

Java Applets und ihre Verwendung

nospam@example.com (Daniel) — Wed, 18 Apr 2007 18:14:00 +0200

Java Applets sind eine tolle Sache. Sie ermöglichen einem die aller unterschiedlichsten Applikationen direkt vom Webbrowser aus zu starten.

Doch dies hat auch Kehrseiten. Was würde passieren wenn die geöffnete Applikation sich versucht mit einem Host zu verbinden und diesem eine Remoteshell offeriert.
Oder gehen wir einen Schritt weiter, was würde passieren wenn lokaler Schadcode ausgeführt wird?
Natürlich haben die Entwickler von SUN vorgesorgt und erlauben Java Applets per default keine lokalen Anwendungen aufzurufen oder sonstige Befehle am System abzusetzen.
Dennoch benötigen einige Entwickler für Ihre Applikationen genau diese Fähigkeit. Daher gibt es die Möglichkeit mittels Zertifikat seine Applikation zu signieren und bei akzeptieren des Zertifikats, ist auch das Starten von lokalen Applikationen kein Problem mehr.
Nun wo liegt hier das Problem?
Ganz einfach.
Ein Angreifer könnte mit geschickten Social Engineering Techniken einen unerfahrenen User dazu bewegen diesem Zertifikat zuzustimmen und dann seinen Schadcode, im Hintergrund ohne das der Benutzer es mitbekommt, ausführen lassen.
Blacklotus (Thomas Schneider) und ich haben unter http://www.remoteshell-security.com/poc/javapoc.html ein kleines Proof-of-Concept geschrieben, welches unter Windows den Befehl dir im Wurzelverzeichnis ausführt und diese dem lokalen Host schickt.
Unter http://remoteshell-security.com/poc/jrspoc.html ist dann noch eine Remoteshell bzw. eine Reverse Shell als Java Applet die sich mit einem Ziel Socket verbindet.

Nachtrag:
Das die Sache nicht neu ist, habe ich mir schon gedacht, aber anscheinend ist die Sache schon seit langen bekannt:
http://www.bsi.de/fachthem/sinet/gefahr/aktiveinhalte/definitionen/appletsgefahren.htm

Remoteshell-Security Blog - Programmierung

gmc: Der Modul Helfer

Java Applets und ihre Verwendung