|
|
|
|
|
|
|
|
 |
 |
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [FW1] Conducent Spyware Beating on Telnet Server
Jon, You aren't the only one seeing this traffic. I spent the last week hunting down users with that software running. I found one signature port that it seems to use: TCP 17027. With that knowledge, I've set up a rule to tell me if anyone tries to make an outbound connection using that port. This has caught several systems so far. A couple of good places that discuss this program are: http://catless.ncl.ac.uk/Risks/20.65.html http://www.4menterprises.net/whos_watching_you_surf.htm http://cexx.org/tsadbot.htm Ken McKinlay) Extension 506 [email protected] -----Original Message----- From: Jon R. Allen [mailto:[email protected]] Sent: Monday, October 02, 2000 12:15 To: [email protected] Subject: [FW1] Conducent Spyware Beating on Telnet Server Curious if anyone else is seeing this. While reviewing my logfiles I notice hundreds of strange entries denied by rule 0. The sessions originate from internal users and are trying to telnet to servers out on the Internet and are being denied by rule 0 since we only let certain users use outbound telnet sessions. The curious thing is that the telnet session contains http directives - in other words, HTTP traffic is being tunneled in an outbound telnet session (that is rejected since we don't allow outbound telnet by default). Further investigation shows these destination servers have Exodus addresses and belong to an ad-targeting company called 'Conducent' (www.conducent.com). What appears to happen is an internal user installs some product that contains the Conducent spyware and it then tries to tunnel HTTP traffic out to servers on the internet. A sniffer traces shows this clearly. My big concern is every session hits the HTTP security server and bangs against it - driving up the CPU usage on the firewall. This is very rude behaviour. Also since these do not succeed, I am not really sure what is being sent out (that is scary - it could be sending out all your company secrets!). Anyway, attached are a couple of examples from my firewall log file that were denied. As you can see the sofware doesn't realize it reached the authentication server (asking for username) and just dumps it's one line HTTP payload - which the firewall logs as an invalid user: service source dest User telnet <int_addr> 216.35.217.175 POST http://contents.conducent.com:23/BeginSession?P... telnet <int_addr> 216.35.217.175 Content-Type: application/x-www-form-urlencoded telnet <int_addr> 216.35.217.175 Content-Length: 242 telnet <int_addr> 216.35.217.175 Cache-Control: no-cache telnet <int_addr> 216.35.217.175 transaction= telnet <int_addr> 216.35.217.175 AGAAFEAAAwMUQ4MjNEOUJCMD... telnet <int_addr> 216.35.217.175 MjQwMDAwMDAwMDA... I have seen about 10 different destination addresses - most of which come up eventually when resolving 'contents.conducent.com' -Jon ============================================================================ ==== To unsubscribe from this mailing list, please see the instructions at http://www.checkpoint.com/services/mailing.html ============================================================================ ==== ================================================================================ To unsubscribe from this mailing list, please see the instructions at http://www.checkpoint.com/services/mailing.html ================================================================================
|
||||||||||
 |
 |
 |
 |
 |
 |
 |
 |
 |
|
