| |
| |
|
| - page 1 - |
|
 | allô Profaner..
Hat la fois quelqu'un Lust trop testen, si [...]  sous XP generell gefixt ist?
- Einen Service trop programieren ist pour pas absolument nötig, normales Programme avec RUN AS (aussi avec PrivAktivate possible) comme Admin starten et cela Angreiferprogramm dans einem Account avec eingeschränkten Rechten effectuer.
- dans cela Hauptprogramm une Minuteur insérer (doit naturellement un la fenêtre avons).
- Im Angreiferprogramm une Procédure écrivons, qui une Messagebox ausgibt, qui Proc mais pas effectuer laisser.
- avec ProcAddr qui Adresse qui Procédure ermitteln.
- avec Poster un message (ou bien peut-être SendMessage) WM_TIMER avec qui Adresse qui Procédure vom Angreiferprogramm à cela Hauptprogramm senden.
Klapp cela???
 |
|
| |
| |
| |
|
|
| |
| |
| - page 2 - |
|
| pourquoi cela pas ging, c'est moi glaube je maintenant bien sûr:
[quote-part:16fcb7769f=Frank Abbing]allô,
qui Adresse peux eigentlich aucun virtuelle Adresse son, weil vous direct angesprungen volonté peux. je peux qui Prozedure aussi direct dans meinen Code setzten et starten.
[/quote-part:16fcb7769f]
Im eigenen Prozess ne...aucune Problem - mais im fremden? qui Code, den on effectuer veux, est sich oui im eigenen Prozessbereich et chacun Prozess verfügt sur seinen eigenen virtuellen Speicherbereich...
[quote-part:16fcb7769f=Frank Abbing]
je vermute plutôt, dass Windows testet, si qui grenier, qui fonctionnement volonté soll, zum Programme est. alors de Programme belegt wurde.
[/quote-part:16fcb7769f]
je veux espérer, qui wir pas aneinander vorbeireden:
là un Prozessor oui zur Zeit aussi seulement toujours une Prozess effectuer peux, pourrait je mir sogar présenter, qui qui sich qui auszuführende Code physikalisch trop qui Zeit, à qui il eigentlich dem Prozessor comme Programmcode zum Effectuer zur Disposition stehen sollte, dans RAM-Gefilden est, dans dener il comme auszuführender Code gar rien utilise.
il faut alors den auszuführenden Code seulement einmal dans den Speicherbereich des anzugreifenden Prozesses apporter.
et maintenant venez qui Debugger ins Spiel - gemeint sommes ici APIs zum Debuggen de Programmen qui une DLL dans den Speicherbereich eines fremden Prozesses injecter peut, pas un Programme.
Zum injecter einer DLL gibt es plusieurs Opportunités - qui Autor scheint ici une Possibilité trouvé trop avons, qui seulement unzureichend sur Privilegien et Zugriffsrechte abgesichert ist. je suis mir im Augenblick mais assez sûrement, cela zumindestens qui anzugreifende Prozess sur bestimmte Sicherheitsmängel disposer doit, qui cela injecter zulassen.
[quote-part:16fcb7769f=Frank Abbing]
il y a wohl une Vielzahl à Opportunités, anderen Task une Adresse mitzuteilen.
[/quote-part:16fcb7769f]
oui, sous anderem Subclassing. |
|
| |
| |
| |
|
|
| | So - je crois, mir ist bien sûr geworden, comment il gemacht hat. Werde cela im prochain l'an la fois testen... |
|
| |
| |
| |
|
|
| cela eigentliche Problem ist, qui chacun Prozess seinen eigenen virtuellen Speicherbereich hat. veux je alors, cela un fremder Prozess meinen Voir le texte source ausführt, doit cette Voir le texte source sich im grenier des Prozesses befinden, qui ihn effectuer soll. mais comment bekomme je Voir le texte source dans une fremden Prozess? c'est eigentlich cela kleinere Problem:
chaque Contrôle, chez dem je irgendwie Ihnhalte mittels einer Message senden peux, bietet eigentlich cet Possibilité - am einfachsten allez cela avec einem Multiedit (cela naturellement auparavant déjà im Prozess vorhanden son doit).
Mittels WM_SETTEXT läßt sich moins un Multiedit oui Text senden, qui ensuite im Éditer sichtbar et editierbar ist - mais pourquoi seulement Text, pourquoi aucun DLL avec Voir le texte source? Sende je une DLL (naturellement pas de qui Festplatte, mais aus dem grenier meines Prozesses heraus) à cela Multiedit des fremden Prozesses, est sich qui DLL ensuite im Speicherbereich des femden Prozesses et peux eh bien aussi mittels WM_TIMER angesprochen volonté (jusqu'alors seulement Trockenschwimmen, là je ne...aucune MASM peux, devrait mais marcher).
Mittels EM_GETHANDLE läßt sich ensuite cela Handle des Textes (qui DLL) im Éditer ermitteln - et eh bien venez cela eigentliche Problem, il me faut pas cela Handle, mais qui Adresse.
Mittels folgendem Voir le texte source voulons wir uns maintenant la fois quelque chose näher à Adresse kümmern - sous 2000/XP naturellement:
KompilierenMarqueSéparationWindowstyle 31
Windowtitle "Multiedit"
Window 0,0-640,440
Def @GlobalSize(1) !"KERNEL32","GlobalSize"
Def @GlobalLock(1) !"KERNEL32","GlobalLock"
DEF @CopyMemory(3) !"kernel32","RtlMoveMemory"
Def @GlobalReAlloc(3) !"KERNEL32","GlobalReAlloc"
Def @SetParent(2) !"USER32","SetParent"
Declare edit&,Text$,ADDR&,Handle&,Text#
Dim Text#,256
LET EDIT&=@Createmultiedit(%HWND,"Test ",20,130,200,200)
LET Text$="ABCD"
LET Handle&=@sendmessage(edit&,$BD,0,0)
Print "Handle des Edits: "+@str$(Edit&)
Settext Edit&,@STR$(Handle&)
Let Addr&=@val(@Input$("Adresse des Edits:","Addresse",""))
Let Addr&=@GlobalLock(Handle&)
@CopyMemory(Addr&,@ADDR(Text$),32)
@CopyMemory(text#,Addr&,32)
Print "Adresse: "+@str$(Addr&)
Print "Breichshandle: "+@str$(Handle&)
Print "Kopierter Text: "+@String$(Text#,0)
PrINT "Bereichgröße: "+@str$(@GlobalSize(Handle&))+" Bytes"
Dispose text#
While 0=0
Waitinput
Wend
là Profan quelque chose verschwenderisch avec Heaps umgeht, sollte on den Voir le texte source avec Profan2Cpp compilieren.
Beim mir sieht cela ganze ensuite dans etwa so aus:
BILD 1
Im Éditer steht ici cela Handle des Textes.
eh bien starten wir [...] , choisir den Testprozess avec dem Multiedit aus et laisser uns dessen Heaps listen.
BILD 2
eh bien 1faire wir la fois so comme wäre cela Handle des Textes (chez mir 44630028) une Adresse et laisser uns cela Doubleword à cet Adresse de [...] einmal auslesen.
BILD 3
BILD 4
Heraus venez chez mir: X1=38184920
maintenant 1faire wir wiederum so, comme wäre 38184920 et regarder sous den Heaps pour, si wir irgendwo cet Adresse trouver et laisser uns den le contenu des Heapblocks comme String représenter:
BILD 5
comment on voit, avons wir qui Adresse des Textes im Éditer trouvé! cet Adresse peux comme Offset pour qui Funktion pris volonté, qui wir mittels WM_TIMER später im fremden Prozess ansprechen voulons. en supplément doit qui Adresse qui auszuführenden Funktion ab dem Nullpunkt qui DLL addiert volonté - cela zeigt [...] (Hoffentlich) pas mal à => fertig ist qui Adresse pour WM_TIMER!
comme Administrator alles ne...aucune Problem - mais zum Lecture de Prozesspeicher besoin je PROCESS_VM_READ et PROCESS_VM_OPERATION - et comme User avec eingeschränkten Rechten habe je cet Rechte définitif pas!
...mais sous welchen Voraussetzungen ändert sich qui Adresse überhaupt??? la fois schaun:
je starte den Prozess erneut => gleiche Adresse! qui Adresse scheint alors qui prochain freiliegende Adresse trop son et wird pas zufällig gewählt.
je gebe plus que 32 marque dans cela Éditer un => neue Adresse - ist oui bien sûr, si plus zusammenhängender grenier gebraucht wird et cette à cette Stelle pas zur Disposition steht, doit sich aussi qui Adresse changement.
mais aussi alles quoi auparavant dans den Heap geschrieben wird (et sich ändert) peux cet Adresse beeinflussen. dans unserem le cas liegt qui Adresse im ersten Heap, dem Standardheap des Prozesses. regarder wir la fois pour, quoi sonst encore alles avant cette Adresse steht. ici la fois un paire Auszüge:
G : W I N N T S y s t e m 3 2 W I N M M . D L L => nom de vom Prozess geladener DLL
F:EIGENESTasks and TokenMultiedit_cppMultiedit.exe => Gestarteter Prozess avec Parametern
E G I S T R Y U S E R S - 1 - 5 - 2 1 - 8 6 1 5 6 7 5 0 1 - 1 0 6 0 2 8 4 2 9 8 - 1 9 5 7 9 9 4 4 8 8 - 1 0 0 0 => User String-SID
aussi Umgebungsvariablen eines Prozesses habe je déjà dans Heaps trouvé.
comment on ici bereits erkennt, ist qui Adresse alors Systemabhängig, avec cela ist es alors pas possible, une vernünftige Anwendung trop écrivons, qui aus einem normalen Useraccount jeden calculateur sans weiteres knackt sans ihn auparavant zig(mille)male zum Absturz trop apporter. cela pourrait qui Grund son, pourquoi Microsoft sur den Artikel, qui Ausgangspunkt cette Postings était, pas grandiose reagiert hat - qui Grundaussage cet Artikels était mais une autre, nämlich qui es insgesammt un Sicherheitsrisiko ist, Messages ungefragt à autre Programme senden trop dürfen; et dem stimme je maintenant la fois entier heftig trop...
et qui sich maintenant fragt, pourquoi je ici so viel blödsinn hingeschrieben habe:
j'ai ici plan la fois nebenbei une Possibilité zur DLL-injection aufgezeigt, qui naturellement aussi avec anderen Controls comme einem Multiedit funktioniert  . |
 |
| |
| |
| |
|
|
| je dois cela, quoi je ici im letzten Posting de mir gegeben habe, wohl quelque chose revidieren.
Folgende Überlegung:
qui Text des Edits landet toujours im ersten Heap. qui Startadresse des ersten Heaps (aussi ici quasi cela Handle), pourrait sur dem gleichen Betriebsystem (et cela aussi sur unterschiedlichen Rechnern) toujours à qui gleichen Stelle liegen.
j'ai chez mir sous Windows2000 la fois avec WM_TIMER quelque chose herumexperimentiert...
Zeigt paramètre quatre sur une pas auslesbaren Bereich, entsteht bien sûr une Zugriffsverletzung. Zeigt paramètre quatre mais sur auslesbare Bereiche qui keinen ausführbaren Voir le texte source enthalten, passiert scheinbar ne...aucune schwerwiegender faute.
Theorethisch devrait es alors possible son, qui Startadresse (cela Handle) des ersten Heaps comme Ausgangspunkt trop prendre et so longtemps beim Senden qui Message un Byte dazuzurechnen, jusqu'à WM_TIMER den Voir le texte source ausführt.. qui Startadresse des Heaps pourrait on de einem anderen calculateur beziehen, sur dem qui gleiche Anwendung fonctionne. Selbst avec XProfan pourrait le reste dans annehmbarer Geschwindigkeit trop régulariser son.
je suis zur Zeit à anderen Sachen tour et konnte ca malheureusement encore pas plus testen, là je ici mais genug lauffähigen Voir le texte source habe, werde je qui Chatter Attack dans prochaine Zeit la fois nachbauen. Es wird rien grandiose spektakuläres volonté et qui DLL qui fonctionnement wird, wird qui Test-DLL avec qui Messagebox son, qui mir Frank autrefois freundlicherweise programmiert hat - je möchjte quand même mais la fois informer, si je so un Programme ici überhaupt posten darf? |
|
| |
| |
| |
|
|
Frank
Abbing | Na, qui Frage allez wohl plutôt à iF.
Mich jedenfalls serait dein Test intéresser. |
|
| |
| |
| |
|
|
 | |
| |
| |
| |
|
|
| Mmmh - pour einiger Euphorie verliere je im Augenblick la fois wieder cela Vertrauen dans den Warheitsgehalt qui Aussagen des Artikels. qui kleinste Hürde (- qui je im Augenblick encore pas überwunden habe - ), wäre cela insérer de Nullbytes dans un Éditer sans cela droite PROCESS_VM_WRITE trop haben; là steht mais encore wesentlich plus im Wege...
Einmal à Frank: comment grand sommes qui Chancen, qui on avec cette Methode wirklich une aktuellen calculateur knacken peux? exposition dir en supplément fois le Prozesse avec TNT à, qui sur deinem calculateur im System-Account courir - car à ca va ici. vois du irgendwo une solchen Service, qui un Éditer ou bien un Multiedit besitzt???
si du dir mon anderen Artikel einmal aufmerksam durchliest et selbst avec TNT quelque chose herumexperimentierst, wirst du wohl très vite feststellen, qui alle anderen la fenêtre pour solche Aktionen pas trop gebrauchen sommes (suis alors ne...aucune Böser Bube ). quoi mich à diesem Artikel intéressé, ist qui Possibilité qui DLL-injection comme Administrator dans une Prozess, qui ne...aucune Service ist - mais selbst là vois je im Augenblick Probleme,, pour qui es encore aucun Solution gibt... |
|
| |
| |
| |
|
|
| [quote-part:91bd3aedf7=Frank Abbing]Na, qui Frage allez wohl plutôt à iF.
Mich jedenfalls serait dein Test intéresser.[/quote-part:91bd3aedf7]
Mmh... - Voir le texte source werde je vorerst trop DLL-Injektionen encore pas aus qui main donner. Zumindestens cela, quoi TNT pouvoir pourrait pour euch beide mais aussi sans Probleme sans Voir le texte source nachzuvollziehen son, directe Fragen à mon Mailadresse beantworte je également volontiers.
Salut
AH |
|
| |
| |
| |
|
|
| | Zum Abschluß comme manifestation quoi là wirklich so alles possible gewesen ist, nochmals quoi trop diesem Thema. là je qui kleine Anwendung, qui je diesbezüglich geschrieben habe, pas so volontiers sous qui gens apporter voudrais, alors dans forme einer Animation: |
|
| |
| |
| |
|
|
| | Drum ist oui zum Glück aussi un altes Windows ;) |
|
| |
| |
| |
|
|
| 
Fakt ist, cela es sur Jahre hinweg (aussi sous XP) possible gewesen ist, pour une normalen Mitarbeiter jeden Firmenrechner auszuhebeln (et cela sous XP encore besser comme sous Windows2000).
Fakt ist aussi, cela sich am Grundprinzip de Windows rien geändert hat. si encore irgendwo im OS weitere undokumentierte Messages avec gleichem Potential invisible sommes, ist également pas sûrement. EM_SETWORDBREAKPROC et autre Messages wurden meines Wissens pour encore pas einmal gefixt.
Fakt ist aussi, cela sur vielen, (aussi kommerziell genutzten) Rechnern encore veraltete Servicepacks courir - siehe meinen Test im Internetcaffee.
Shatter ist alors une Geschichte, qui on très oui c'est ca im Auge behalten sollte - justement si es um neuere Betriebsysteme allez. Besonders brisant finde je qui Geschichte, cela es pas einmal nötig ist Voir le texte source dans fremde Anwendungen sur une Message einzuschleuse - qui Possibilité Voir le texte source anzuspringen reicht toujours aus! |
|
| |
| |
| |
|
| |
| |
| - page 3 - |
|
|
| je hab là sogar encore quoi oublier qc .
en supplément venez encore, cela oui peut-être. pas seulement cela Starten fremder Source périlleux son peux - c'est z.B. aussi possible, sans irgendwelche Rechte sur Messages den grenier fremder Prozesse auszulesen. |
|
| |
| |
| |
|
(851)
Deutsch
English
Français
Español
Italia
