Convince Me...

Discussion in 'Trojan Defence Suite' started by Undecided, Aug 29, 2004.

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

    Undecided Guest

    Ok, so I'm impressed with some aspects of TDS's trojan-finding techniques (having compared it with Tr**anH**ter, its most-visible serious competitor, and a few other so-called commercial apps which would best be described as 'student homework' or 'unfinished projects').

    But I've noticed a few problems with TDS, that kinda make me wonder...


    The SMTP client engine.... is it bust? Or is it just not implemented to RFC-standards? It won't seem to send a message to a valid local user, when it is running on the same box as the SMTP server for my domain! TDS seems to take exception to a second 220- response line, and reset the TCP socket - despite this being perfectly legal, and quite common, too.

    It means I can't submit the 3 'false positives' which have turned up on my Full Scan that I did today:

    First, it claims that Kiwi Syslog 7.00.0003 (Syslogd_Service.exe) is a 'live trojan in process memory'. Hmmm... don't think so - unless something's got well and truly screwed up. See

    Second, it claims that an app which I wrote MYSELF, in Visual Basic, last week, is 'Positively Identified <ADV>' as a 'Possible WebDownloader'. Yeah, right. LOL - it's a program I wrote which enables me to read Kiwi Syslog files, parse them according to the weird syntax for my firewall/router, and stuff the output into an Access database, that's all. It's not generally available (so I KNOW it's not a trojan) - but I'm curious as to what item might possibly have caused TDS to reach for the alarm button here? AFAIK, aside from a bit of code which I borrowed to create a decent File:Open XP style dialog box (to replace the shabby inbuilt VB ones), the code is all definitely clean. I know - I WROTE it! LOL. I will double-treble check the bit I borrowed, though, just in case.

    Third, it complains that perl5.8.4.exe is a 'suspicious filename' because it has 'dual extensions'. I'm guessing this is simply because of the three dots in the filename - but come on, this is PERL, for goodness sake. Even though I appreciate this is a 'False Positive', surely you could trap for that error with your 'sophisticated scanning techniques' and stop an alert like this? How many people end up deleting their Perl implementation out of paranoia, before they realise they've just bust their website? :)

    Ok, so maybe I'm being a teeeny bit harsh - after all, how many 'stupid noobs' are going to be Syslogging, writing their own apps, and running a Perl implementation anyway? Fair point - but for those of us that ARE, I'd like to know that TDS isn't going to be as much hassle as it is a saviour. To me, too many false-positives are almost as costly as just doing my anti-trojan checks by hand, as I used to (till I got bored today and decided to see what was 'out there' in terms of products available to assist).

    I gotta say I was also NOT impressed to read about the update Radius problems that have been happening - whether ISP-cache-related (which you can't do anything about), or MS FTP-upload related (which you CAN!). I can't believe something as crucial as a sig-file update isn't MD5 checksummed or at the very least verified on the server as being intact before being renamed or moved to the distribution address.

    On the up-side, though, I also have to say that if Derek from the is here on this forum, and using TDS, it can't be all bad, surely. I rate Derek highly (though he probably doesn't know that - lol).

    So - I'm all ears... is this REALLY the best app available for Trojan spotting? Am I just being unlucky and revealing the bad bits on my first day? Or is it a sucky ol' pile of half-baked, poorly-implemented mumbo-nonsense and paranoia-warez, like so many of the rest of these AT 'tools'?
  2. Gavin - DiamondCS

    Gavin - DiamondCS Former DCS Moderator

    Feb 10, 2002
    Perth, Western Australia

    Kiwi Syslog is a known false alarm with memory space heuristics, this will be corrected in the next version and you can ignore it

    Possible webdownloader catches masses of new adware downloaders, we originally implemented this detection because there were a lot of trojan webdownloaders being created. In the end it has worked out well catching tons of new adware downloaders often before anything else detects them. As with any heuristic, it can have false alarms and since you know the file is clean just ignore this one too

    Finally, dual extensions can be ignored when you know the file isn't trying to hide its real extension. A classic example (dont laugh, it caught lots of people out) was sending a file called MYPIC.JPG.exe.. I think you know how to analyse alarms of this type now :) If its anything like that, trying to hide its real extension, send it for analysis. If its a file like the one you have then you can ignore the detection.

    Due to a database upload corruption issue we have put in place steps to ensure it cant happen again - no matter what. ALL databases are downloaded and verified from the update servers before being made available to the public.
  3. xmp

    xmp Guest

    If you are referring to the built-in mailing program, that's tricky. SMTP servers have all sorts of restrictions. Some ban residential IP addresses from sending mail. Most only allow incoming mail that's going to an address in that domain. Several ISP's block outbound port 25, so you can't connect to external mail servers (besides your ISP's server).

    You can look up the error number in the SMTP RFC or on google. Also you can telnet to the mail server (port 25) and type commands manually to figure out the problem:

    mail from:<>
    rcpt to:<>
    test message
  4. dvk01

    dvk01 Global Moderator

    Oct 9, 2003
    Loughton, Essex. UK
    In my eyes TDS is primarily intended for a more advanced user as it contains so may bells & whistles apart from the basic scan & fix part

    If you ahve seen any of my suggestions regarding using TDS on any of the forums I deal with I ALWAYS tell victims to scan with TDS and then post the results of the scan so we can filter out any false positives or add any extras to be fixed

    I find that TDS used along with a HJT log when the logs are analysed by a knowledgeable person go a long way to curing the majority of problems that we encounter

    with many of the latest worms/viruses/trojans using dual or even triple filenames, it is wise to include their detection

    The main reason I like TDS is that it gives YOU the means and methods to fix any infilitration and doesn't blindly fix everything like many antiviruses including FP and innicent files

    YOU are always given the choice with TDS to fix or ignore
  5. Detox

    Detox Retired Moderator

    Feb 9, 2002
    Texas, USA
    I really like that part also - I can ignore my RAdmin since it is used between me and a few other very good friends to use each others computers from across the world in order to host games and such.

    I am also very fond of the fact that it finds every file with multiple extensions - although so far it has only found various application patch .exes with version numbers at the end.
  6. Warming

    Warming Guest

    OK - first, thanks for the replies, guys. Considered and helpful, all of them.

    I guess I was a teensy bit 'uptight', having had a bit of a runaround with other apps of a similar nature, and getting mightily sick of the whole 'Medicine Show' quick-fix-4-noobs circus that has sprung up in this world of Windows anti-trojan, anti-spyware, anti-hijack game.

    It's happening to me on another front too - WiFi - and some of my clients are getting taken for suckers (half of them simply cos they don't RTFM, but that's always gonna be the same, isn't it?). I guess I'm very wary of 'revered apps' that purport to fix all, thru past (and present) experience.

    Anyway... Some matters arising, if I may:

    Re the Syslog thing - fine... I did realise that it was kosher, but was more 'eyebrow-raising' that it was detected at all. If it's going to be 'undetected' in future versions, that's cool. But will that version be upgradeable to, from the current one, if I buy it now? I will check the FAQ, if I can find it... but in case you have a reason why I should hang on and buy later, please save me the journey...

    Re my own app, again, I know it's clean, and obviously won't delete it... but (and here's the rub), assuming I finish it, I MAY be releasing the app as an alpha sometime in the next couple of weeks. It's just a widget that reads Kiwi Syslog's output files, and parses the firewall & system log data contained in the messages (they are a peculiar one-off format for the Intertex IX66 ADSL router). It would be a little inconvenient if any of the users saw it come up in TDS as a 'dodgy app', so I was wondering what I need to do to ensure that it DOESN'T get fingered by this. I don't DO any webdownloading in the app, so I'm wondering if it's a VB/COM component that I'm referencing in the app which I could drop out anyway? I'm using the filesystem object (part of SCRRUN) - my guess, it's that one (which would, alas, be a bitch to remove, cos it's what I do my disk reads and writes with. I could go back to old-fashioned 'OPEN', GET#, PUT# statements, but ugh... I thought those days were behind me - LOL). :D

    Re the double-extension thing, yeah, again, I get the deal now. I take Derek's comments on board, and when I think about it, I'm in total agreement too. I'd rather it told me than not, and I'd rather hold the cards when it comes to deciding what to delete. I'll know better how to respond to TDS's reports on things, from here. Thanks.

    Re the database thing - cool. I'll take you at your word. Maybe I'd say, as a noob here, the sticky post isn't perhaps the best advert for your product. It kinda put me on the back foot during my 'eval' phase of the product. Sure, open and honest, and all accounted for in the end - but also a signal of 'it can go badly wrong at times'. I know this happens to everyone, but maybe it's time to drop that thread's priority now? A month or more has passed since then...surely everyone affected will be updated by now?

    Finally, the SMTP thing still plagues me. To clarify things for XMP (and thanks for the info, btw), the SMTP server is MINE! It's running on the same machine as TDS (in fact, it's WHY I'm evaluating TDS!) I've looked at the SMTP sessions in the realtime logs, and can see what's happening. It's NOT my SMTP that's dropping the conn - it's TDS. There are no blocks in place which would prevent (or any IP address corresponding to that machine's NICs) from sending mail in the account I told it to use. It gets as far as this:
    Mon 2004-08-30 23:20:49: Session 1922; child 1; thread 704
    Mon 2004-08-30 23:20:48: Accepting SMTP connection from [ : 2006]
    Mon 2004-08-30 23:20:48: --> ESMTP <version withheld> Mon, 30 Aug 2004 23:20:48 +0100
    Mon 2004-08-30 23:20:48: --> 220-All transactions and IP addresses logged.
    Mon 2004-08-30 23:20:48: --> 220 Unauthorised relay prohibited
    Mon 2004-08-30 23:20:48: <-- HELO mypc.localnet
    Mon 2004-08-30 23:20:48: --> 250 Hello mypc.localnet, pleased to meet you
    Mon 2004-08-30 23:20:49: Winsock Error 10054 Connection was reset by the other side!
    Mon 2004-08-30 23:20:49: SMTP session abnormally terminated (Bytes in/out: 19/215)
    To me, that looks like TDS decided to pull the plug, not the SMTP server. Any guesses? TDS responds at the same time with:
    23:20:48 [SMTP] Failed - HELO error: 220-All transactions and IP addresses logged. 
    23:20:49 [SMTP Error] Email to failed.
    Hence my original question as to whether TDS knows how to handle a multi-line Server-side 220 Hello response? I have just checked that my server is dealing with them as per the SMTP RFC latest SMTP RFC (see sec 4.2.1, page 43, para 2 onwards) - I'm just wondering whether TDS does, too? I'm curious, cos if it's got a problem with the HELO error 220, why did it carry on and identify itself, and THEN decide to hang up? And why did it hang up without a 'QUIT' anyway? In SMTP terms, that's either a bug, or rude - either way, it sorta went against the grain, if TDS is a program which is meant to be 'blue-chip', if you know what I mean. I guess knowing that TDS does at least know how to implement everyday internet standards properly, is another 'item of confidence' I need, when making a decision on purchasing. Not saying it doesn't, but I am asking... ;)

    Sorry bout the long post - but I thought it was better to get all my concerns out in one hit, then put them aside when dealt with. We're almost there - thanks again for all your time and responses.

  7. dvk01

    dvk01 Global Moderator

    Oct 9, 2003
    Loughton, Essex. UK
    from what I can see in the log you post and reading here"220 Unauthorized relay prohibited"&spell=1

    it's not TDS at fault but the smtp server

    is it a post cast server by any chance as they only allow sending direct from the client not other applications on the computer

    either set tds to use your ISP mail server or check the postcast settings to allow other applications to send mail
  8. Sorry, Derek, it's NOT the SMTP server.

    It's MDaemon, and it works fine. Specifically, it works fine with other local processes (which DO understand multi-line SMTP reponses properly) and regularly sends mail to local accounts (or remote addresses) using a local login. I use it for a variety of other processes, such as sending Syslog alerts, Spam totals, etc - all using the same local account.

    As I have said before, it is NOT the SMTP engine cutting off the connection. TDS 'drops' the connection of its own volition. The SMTP engine reports its 'surprise' at the connection being terminated without a 'QUIT' instruction, and the trace-log shows that the connection is reset from the peer side (ie TDS) not the server side. Mdaemon is implemented to the proper SMTP RFC - TDS obviously isn't, therefore I'm dubious of its implementation of other standards too, as a result.

    In case the TDS authors aren't sure of how to implement multi-line SMTP server responses, and couldn't find the bit I was on about in the RFC, here it is in detail:

    I've also double-checked. The '220' response is absolutely the standard response for an initial connection which (so far) is clean and going to be accepted. The text after the space or dash is supposed to be ignored by the SMTP client.

    If the mailserver was going to reject or drop the connection on the basis of its IP address, it would not have responded with a 220 at that point, it would've responded with a 221.

    If the mailserver was planning to drop the connection on the basis of relaying, or locality of the sending/recipient account, it would've responded (at the point at which those accounts were mentioned in either the RCPT TO or MAIL FROM data from the client) with one of the various 550 or 5xx based error messages.

    Sorry - but from what I can see, it's simply a duff MTA client in TDS. Alas, forwarding it on to my ISP so that they can forward back to me, whilst feasible, is pointless and likely to delay receipt of what would be an urgent message.

    I'd rather it just worked properly. Perhaps I'll try it again when it does.

    Thanks again for your help and suggestions though.
  9. tuatara

    tuatara Registered Member

    Apr 7, 2004
    Hi , i found this:

    I've tested TDS-3 with a lot diff. SMTP servers (SendMail, Qmail, Postfix, Exim, SuSE etc.) Never had a problem.

    Used local and external SMTP servers as well.

    What happens if you telnet directly to port 25 ? be sure to use the same
    name/ip is in your TDS configuration.
    And see what you have configured in your other applications as smtp-server
    ( or localhost or mypc.localnet )
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.