Execution Protection

Discussion in 'Trojan Defence Suite' started by sflag, Feb 18, 2002.

Thread Status:
Not open for further replies.
  1. sflag

    sflag Registered Member

    Joined:
    Feb 11, 2002
    Posts:
    10
     Hello  ,
     It would be interesting if a member of this Forum could explain & discuss this affirmation at "Mischel Security Forum" , on January 17th , regarding  ATs levels of protection :


     " It is a known fact that if someone really wants to create a trojan server file that is undetectable by file scanning anti-trojan applications (and file scanning is what is used when we talk about resident hooks or "execution protection") then he can and will do so... "

                            Regards  ,
                                            sflag

                     
     
  2. UNICRON

    UNICRON Technical Expert

    Joined:
    Feb 14, 2002
    Posts:
    1,935
    Location:
    Nanaimo BC Canada
    I'll say put up or shut up. If he is so sure, then he must have done so already. Prove it. I think you'll find that once the version 4s from DiamonCS are released, they are going to be pretty undefeatable.

    If not, then the trojan writer is an idiot for wasting his time doing that instead of making the big bucks
     
  3. UNICRON

    UNICRON Technical Expert

    Joined:
    Feb 14, 2002
    Posts:
    1,935
    Location:
    Nanaimo BC Canada
    I guess that sounded a bit harsh. I'll rephrase:

    If you are going to knock a particular product or products with "known facts" as part of a marketing scheme, then fine if that is how you wish to operate. But if you are going to discuss this in an open forum, then expect people to ask for proof (by example is great in this case). Simply stating something doesn't make it true. We'd all be at grc.com if we wanted that (snicker)

    So give us the known facts (shows what I know since I don't have them)

    Also I am not accusing the writer of the quote of being a trojan writer, but stating that any trojan writer is wasting his talent if he can defeat the "lowly" execute protection and hooking of TDS.
     
  4. DrSeltsam

    DrSeltsam Guest

    >I think you'll find that once the version 4s from
    >DiamonCS are released, they are going to be pretty
    >undefeatable.

    Nothind is undefeatable ;o). As far as i understand wayne tds-4 will use kernel level hooks. Ok, but this won't change the issue:

    "file scanning anti-trojan applications"

    This is right. What happens if a trojan wants to start? The system will ask TDS (if the kernel asks (TDS-4) or the the explorer (TDS-3) is unimportant) if the program is allowed to start. TDS will now scan the file with its file scanning engine and heuristics. To hide a trojan from a file scan isn't very difficult. Simply get a quite unknown exe compressor and thats it. This MIGHT be changed in TDS-4 if Wayne implement a powerfull unpacking engine.

    Adieu, Andreas
     
  5. UNICRON

    UNICRON Technical Expert

    Joined:
    Feb 14, 2002
    Posts:
    1,935
    Location:
    Nanaimo BC Canada
    hey Andreas, true nothing is undefeatable, but with time, I think we will start to see the techology difference between security experts and trojan writers spread a bit more. It stands to reason that large numbers of highly skilled security people will eventually  build tools that get harder and harder for people (who have to spend their free time hacking) to crack. For instance TDS-4 should make things alot harder on trojan writers, not impossible, but harder than TDS-3 was. Well if successfull, TDS-5 may be our one day, and be more difficult still. At the rate they are going, sooner or later they will probably "drop" the trojan writers who can no longer keep up. (TDS-3 has ADS detectors before much ADS malware ever hit the wild)

    If you throw enough time,money and talent at something, sooner or later....
     
  6. Checkout

    Checkout Security Rhinoceros

    Joined:
    Feb 11, 2002
    Posts:
    1,226
    Hey, can we cut the cheap jibes at GRC, please?  They don't get any funnier over time, and a lot of people here actually appreciate what he does.
     
  7. UNICRON

    UNICRON Technical Expert

    Joined:
    Feb 14, 2002
    Posts:
    1,935
    Location:
    Nanaimo BC Canada
    lol I am sorry, you are right that was uncalled for. But you know, sometimes you just can't resist.

    raw sockets destoy the earth yet? oops!
     
  8. Checkout

    Checkout Security Rhinoceros

    Joined:
    Feb 11, 2002
    Posts:
    1,226
    Just bear in mind that sarcasm and mockery do not convey an air of professionalism, and I doubt that DiamondCS would care to be seen as less than professional.

    You might consider reviewing some previous posts.
     
  9. Wayne - DiamondCS

    Wayne - DiamondCS Security Expert

    Joined:
    Jul 19, 2002
    Posts:
    1,533
    Location:
    Perth, Oz
    Andreas (aka DrSelstam), it's amazing how much time you spend denouncing TDS in an attempt to make ANTS look good -- it's not working, and surely such time (and it's a lot of time) would be better spent on developing your own software rather than criticising others? You're building features into ANTS now that have been in TDS for years and your database as Gavin has found out is somewhat lacking, I think you should seriously consider fixing the flaws in your own software before attempting to compare it to TDS.  And please, this is the DiamondCS forum, not the ANTS forum, please find somewhere else more appropriate and more tasteful to promote your software - the ANTS forum, perhaps?

    --

    sFlag, Magnus's statement is quite amazing.  TDS is the only anti-trojan system <b>capable of stopping a trojan from executing</b>, yet he claims he has something better? :)   (How is it possible to get any better than preventing the trojan from executing completely?)

    Quote: "What TrojanHunter _does_ have, TrojanHunter Guard, beats any "Execution Protection" mechanism by miles. It is a known fact that if someone really wants to create a trojan server file that is undetectable by file scanning anti-trojan applications (and file scanning is what is used when we talk about resident hooks or "execution protection") then he can and will do so. TrojanHunter Guard protects your system by scanning the actual unpacked version of every executable file in memory. This gives trojans no chance to hide. Period. The unpacked trojan in memory will always be detectable whilst the potentially modified file on disk could be missed, giving the user a false sense of security if an "execution protection" mechanism is used."

    Mute point. TDS <b>also</b> scans in the process memory area, and Magnus knows that, and TDS-2 was the first anti-trojan scanner capable of scanning in process memory. TDS also scans memory objects and mutexes in memory - TrojanHunter does not. So essentially he is saying his process memory scanner is better than TDS-3's  process memory scanner/mutex memory scanner/memory object scanner/execution protection. He's also saying that he's not interested in stopping trojans before they execute - waiting until after they've run is fine. I completely disagree - it only takes milliseconds for a trojan to delete critical files and steal passwords, so execution protection is a critical front line. Process memory scanning should never be considered a front-line attack.

    Don't worry, it doesn't make much sense to me either.

    Best regards,
    Wayne
     
  10. Checkout

    Checkout Security Rhinoceros

    Joined:
    Feb 11, 2002
    Posts:
    1,226
    Simply untrue.  My background is IBM mainframes but the same principle is true:  to run any process, two things must happen:
    • an executable process must be loaded into memory
    • control must be passed to it
    They are two separate events.  If TDS or any other AT can sit between them, no trojan can survive detection without dynamically unpacking itself in memory when control has been passed to it or loading another module (and such behaviour is detectable and iterative) once control has been passed to it.
     
  11. Paul Wilders

    Paul Wilders Administrator

    Joined:
    Jul 1, 2001
    Posts:
    12,472
    Location:
    The Netherlands
    Indeed, this is the DCS forum, and is for DCS products, comments and questions regarding TDS and WormGuard only.

    That said, Dr.Seltsam/Andreas Haak is free to post on other (non dedicated) forums on this board, just like anyone else.

    regards.

    paul
     
     
  12. Wayne - DiamondCS

    Wayne - DiamondCS Security Expert

    Joined:
    Jul 19, 2002
    Posts:
    1,533
    Location:
    Perth, Oz
    My sentiments exactly Paul and he's just as free to be here as anyone, but it's what he's posting here that is of concern - nothing more than advertising of his products and denouncing other competitive products at the same time - it's not in the spirit of this or any forum, and I believe Andreas can find more professional ways to go about selling his software. Surely if ANTS is even half as good as Andreas makes it out to be then his software will do the talking for him... well they're my thoughts.
     
  13. Paul Wilders

    Paul Wilders Administrator

    Joined:
    Jul 1, 2001
    Posts:
    12,472
    Location:
    The Netherlands
    Wayne,

    Indeed.

    I for one have no problems with Andreas promoting his software on other forums than the DCS forums - denouncing other products is not done. That said, starting up a thread to discuss the technical aspects from various products in a factual and mature way on non DCS dedicated forums seems okay to me; nothing wrong with a good technical discussion concerning any software.

    As for ANTS: no doubt you will have access to the upcoming freeware version. Could be the beginning from a new thread on a non DCS forum   ;)

    regards.

    paul
     
  14. DrSeltsam

    DrSeltsam Guest

    Und das Selbe in Englisch ;o)

    (and the same in englisch)

    >Andreas (aka DrSelstam), it's amazing how much time
    >you spend denouncing TDS in an attempt to make
    >ANTS look good --

    Hmmm - hab ich irgendwas verpasst?

    (Hum? Did i miss something?)

    >it's not working, and surely such time (and it's a lot of
    >time) would be better spent on developing your own
    >software rather than criticising others?

    Hmmm - kann da jemand Kritik nicht ab?

    (Somebody doesn't know criticism there?)

    Alles was ich gesagt habe ist das was da oben steht. Ich sagte, daß nichts unschlagbar ist und das - Kernel Hooks hin oder her - das Problem sich nicht ändert. Oder bist Du Kritik nicht gewohnt bzw. leicht paranoid?

    (All i said can be found above. I said nothing is inbeatable and - kernel hooks or not - the problem didn't change. Or can't you deal with criticism?)

    >software before attempting to compare it to TDS.  And
    >please, this is the DiamondCS forum, not the ANTS
    >forum, please find somewhere else more appropriate
    >and more tasteful to promote your software - the
    >ANTS forum, perhaps?

    Ich hab ANTS nicht mal erwähnt - nur so nebenbei bemerkt.

    (By the way - i don't mentioned ANTS.)

    >sFlag, Magnus's statement is quite amazing.  TDS is
    >the only anti-trojan system <b>capable of stopping a
    >trojan from executing</b>, yet he claims he has
    >something better? :)   (How is it possible to get any
    >better than preventing the trojan from executing
    >completely?)

    Ja - aber ohne gescheite Unpacking Engine bringt das wohl kaum was. Wie Magnus nämlich schon treffend erkannt hat:

    (Yes, but without a powerfull unpacking engine it brings nothing. As Magnus correctly said:)

    Nimm einen exe Packer oder Crypter und behandel damit die Datei ein wenig. Eine "Execution Protection" basiert nun mal auf der Idee den Zugriff auf eine Datei so lange zu blocken bis sie überprüft wurde. Da nichts geladen wurde usw. gibts wohl keine Möglichkeit einen Speicherscan durchzuführen. Ergo ist die einzige Möglichkeit Dateiscan. Und Du wirst mir sicherlich zustimmen, daß es einfach ist eine Datei mit einem Crypter wie z.B. yoda oder einem Packer wie Aspack vor TDS zu verstecken - ob es Dir passt oder nicht.

    (Get a exe packer or crypter and use it with the file. A Execution Protection based on the idea to block the access of a file until she is checked. Cause there won't be load anything there isn't a possibility to scan with ANY memory detection. And you surely will agree with me, if i say that is it quite easy to hide a trojan from TDS' File Scanning Engine using in a crypter like yoda.)

    Dafür ist - nebenbei bemerkt - JEDE Software anfällig.

    (By the way - this is a wound point of ANY software.)

    >Mute point. TDS <b>also</b> scans in the process
    >memory area, and Magnus knows that, and TDS-2 was
    >the first anti-trojan scanner capable of scanning in
    >process memory.

    Aber ein permanenter Scan ist mit TDS nicht möglich wie bei Magnus - oder irre ich mich?

    (But a permanent scan isn't possible like the trojanhunter has, isn't it?)

    >So
    >essentially he is saying his process memory scanner is
    >better than TDS-3's  process memory scanner/mutex
    >memory scanner/memory object scanner/execution
    >protection.

    Nein - das hat er nicht gesagt - das hast Du da rein interpretiert. Solange man dein TDS anbetet ist alles ok. Sobald man das nicht mehr macht, wird man sofort zugetextet.

    (Nope - he didn't say it - you interpreted in this way. As far you adore TDS all is fine. But if you don't you will be spammed with nonsense.)

    >I completely disagree - it only
    >takes milliseconds for a trojan to delete critical files
    >and steal passwords, so execution protection is a
    >critical front line. Process memory scanning should
    >never be considered a front-line attack.

    Hmmm - das Problem hat TDS dann aber auch. Es braucht nur Millisekunden und es ist außer gefecht. Und da die Execution Protection auf FileScans basiert ist sie einfach zu umgehen. Von daher wäre eine Mischung aus beidem ganz sinnvoll - meinst du nicht auch?

    (But than TDS has the same problem. It only takes milliseconds to kick it from memory. And cause the Execution Protection based on File Scanning Technology a execution protection is easy to circumvent. This is why a mix of both (permanent memory monitoring and execution protection) is usefull - don't you think so?)

    Adieu, Andreas
     
  15. Checkout

    Checkout Security Rhinoceros

    Joined:
    Feb 11, 2002
    Posts:
    1,226
    Andreas,

    I have had the privelege of spending many years in Germany, in my line of work.  I consider the English and the Germans closer than the English and the Americans, culturally and philosophically.  I have always been grateful of the personal, old-fashioned hospitality of the Germans, both in the north (Koeln) and the south (Stuttgart).

    I had only ever met one German discourteous and rude enough to insist on speaking German even though they were perfectly capable of speaking English, to my obvious disadvantage.

    It now seems I have met a second.  I am disgusted.
     
  16. Paul Wilders

    Paul Wilders Administrator

    Joined:
    Jul 1, 2001
    Posts:
    12,472
    Location:
    The Netherlands
    Andreas,

    Your latest post - see above - is in German Language; few are able to read it.  In order to keep this thread readable for all, please make to needed modifications, meaning: replace the German parts into English.

    Since your post regards TDS and overall issues, I will leave it up (provided to translate it; no use in leaving it up if hardly no one is able to read it).  I'll leave it up to Wayne how to handle it after translation.

    Seems fair to me; do hope you agree.

    regards.

    paul
     
  17. UNICRON

    UNICRON Technical Expert

    Joined:
    Feb 14, 2002
    Posts:
    1,935
    Location:
    Nanaimo BC Canada
    A sense of superiority however he can get it.
     
  18. Checkout

    Checkout Security Rhinoceros

    Joined:
    Feb 11, 2002
    Posts:
    1,226
    Don't gloat, Unicron.  It's unbecoming.
     
  19. UNICRON

    UNICRON Technical Expert

    Joined:
    Feb 14, 2002
    Posts:
    1,935
    Location:
    Nanaimo BC Canada
    boy, can't get an inch with you! heh, I'll have yo go post in the moderators forum just so you can't scold me after lol.

    PS that wasn't gloating, it was an obsevation.
     
  20. Paul Wilders

    Paul Wilders Administrator

    Joined:
    Jul 1, 2001
    Posts:
    12,472
    Location:
    The Netherlands
    I'm not allowing this thread turning into a flame war for whatever reasons - justified or not. Therefore, I kindly ask anyone, except Andreas and Wayne, to stop posting for the moment.

    This should be regarded by no means as an offense to anyone; I made my point in my previous post - now it's up to Andreas and Wayne.

    Thanks in advance.

    paul
     
  21. wizard

    wizard Registered Member

    Joined:
    Feb 9, 2002
    Posts:
    818
    Location:
    Europe - Germany - Duesseldorf
    The problems with this discussion is that both parties have some correct arguments. Every known method of detecting malware (in this case trojan) has some negativ aspects. For detecting trojans there are at the moment three basic concepts:

    - file scanning (or execution protection). The main advantage of this method is that a trojan can be stopped from executing and doing any damage on a user's system. This is how all anti virus solutions work. The bad site of file scanning is that it can be uneffective when a hacker (better called scriptkiddie) uses a runtime packer or crypter to hide the trojan. At least the trojan can still be detected when such a packed trojan has added to the signature database befor.

    - process memory scanning: The main advantage is that process memory can not be "cheated" with runtime packers or crypters. The bad site is that the trojan already infected the system and could attack for example the anti trojan software (e. g. kill the process).

    - "unpacking engine" this is an additional feature for file scanning. Some anti virus software uses this technologie already and it means that the av software tries to recognize the packer (or crypter) and unpacks it before scanning. Main advantage is that this really improves file scanning. The disadvantage is that every packer (e. g. KAV already knows more than 120) has to be analysed and a special unpacking routine must be written. But this is also not a perfect solution because there are crypters that are so complex that unpacking would not work (this is an information from Kaspersky).

    Conclusion: It will be the best for the user to have a scanner that combines the features of file scanning and process memory scanning.

    For further discussion. Is it possible to code a genric unpacking engine? This could work in a way that the scanner executes every file in a "save" memory location and than scan it.

    And at the end a short overview between the actual versions of TDS-3 and Ants:

    TDS-3 offers file scanning (execution protection) and process memory scanning on demand.

    Ants 2.1 offers only filescanning on demand.

    Before I end I like to explain to the interessted visitors what a runtime packer and a crypter is for better understanding. Everybody knows zip. It's a program that will reduce the sizes of files but those files can not be executed without zip. Runtime packers work nearly in the same way. They reduce the size of the file but the file can still be executed.

    A crypter is a program that should protect programs from being cracked or disassembled.  These crypters encrypt a file and put sometimes "special tricks" in it to make the analysis of the file and it's code very difficult.

    In both cases the structure of the file will be changed and therefor a file scanner would fail to detect it.

    wizard
     
  22. Gavin - DiamondCS

    Gavin - DiamondCS Former DCS Moderator

    Joined:
    Feb 10, 2002
    Posts:
    2,080
    Location:
    Perth, Western Australia
    As I summised in another thread, a generic unpacker which could handle _anything_ is at this time impossible for the best minds, it would likely remain this way due to the complexity.

    I have worked with many generic unpackers here in the DiamondCS labs, the process is traced during load, and even then sometimes the process runs as some packers use so many anti debugging tricks. Which is what we were talking about in the first place.. stopping this execution :)
     
  23. DrSeltsam

    DrSeltsam Guest

    >and even then sometimes the process runs as
    >some packers use so many anti debugging tricks.

    Hmmmm - its dangerous to run. But you might emulate it. There are several ways for generic unpacking :eek:). Emulation is slower than debugging and tracing, but its more secure.

    Adieu, Andreas
     
Thread Status:
Not open for further replies.