Hot Downloads

Welcome, Guest
Username: Password: Remember me
  • Page:
  • 1
  • 2

TOPIC: Reverse Trojans

Reverse Trojans 12 years 10 months ago #2285

  • Cheetah
  • Cheetah's Avatar
  • Offline
  • Frequent Member
  • Posts: 72
  • Karma: 0
Please refer our discussion on the site errors forum

Hi,

Kindly see my ascii art below. (Kindly copy in notepad)
[code:1]
Segment One Segment 2
________________________________________________________ _______
| | | |
| | | |
<Internet>---_-<Firewall with NAT>
<Application Proxy/with Antivirus>
<Clients>
| |
|_______________________________|
Can be a system with 2 NIC
[/code:1]

If you desing a similar setup, I dont think the reverse back door can do any good. Remember there is an application proxy in between.

I agree the case will be different, if the attacker manages to get one installed on the application proxy system, which rarely is the case.


Site team, any thoughts. Please share.

Regards
cheetah.
Kind Regards,
<b>Cheetah</b>
<i>The outcome of devotion is, quality!</i>
The administrator has disabled public write access.

Re: Reverse Trojans 12 years 10 months ago #2286

  • Cheetah
  • Cheetah's Avatar
  • Offline
  • Frequent Member
  • Posts: 72
  • Karma: 0
As mentioned please copy the above in notepad, as the formating is not correctly displayed on the forum.
Kind Regards,
<b>Cheetah</b>
<i>The outcome of devotion is, quality!</i>
The administrator has disabled public write access.

Re: Reverse Trojans 12 years 10 months ago #2291

  • sahirh
  • sahirh's Avatar
  • Offline
  • Honored Member
  • Posts: 1700
  • Karma: 0
First, I've viewed your diagram in notepad but I'm not sure I saw it correctly, still it seems like a pretty standard network design. I edited your post and added the code tags, you can format it properly using those.

However, a reverse connect trojan will work fine here if there is outbound access allowed from the clients even through the app proxy. Consider, if the app proxy is an HTTP proxy, you can proxy the request the way I had already described using the reverse www trojan. Furthermore, the first thing I would do here would be check if the http proxy supports the CONNECT method to allow people to view SSL secure sites.. if it did it would be game-over.. the CONNECT method tells the proxy not to examine the traffic (because its encrypted), and can be used to tunnel straight through the firewall to a host and port of my choosing.

Of course the trojan would have to be modified somewhat to deal with the 'custom' scenario. I have tunneled a connection out of a similar setup, with an http proxy and an inline IDS, the firewall was performing NAT and stateful inspection. The point remains, if you can get traffic in and out of your network, 9 times out of 10, I can find a way to mangle my malicious traffic to fit into the parameters you have set.

I'm sure you block incoming pings (ICMP echo request), but do you allow all your systems to ping the outside world ? Seems harmless right ? Well the ICMP echo request contains data (usually just the alphabet).. modify a trojan to pass commands and responses in the ICMP packet, this has been done before. I recall having a rather interesting discussion on similar covert channels with another member somewhere in this forum.. if you search around you will find it.

Understand this -- there is no such thing as a secure network, just as there is no such thing as a secure home. If someone wanted to break into your house and was motivated enough to spend enough time and resources to do it, he would be able to. It brings me to the oft repeated statement -- the only truely secure machine is a machine that is unplugged.

You are viewing the issue with the mindset of an administrator trying to control what is coming in and going out. There are so many ways out of this sort of setup. What if the trojan emails out the responses in encrypted format, and I email in the commands I want executed ? Will you disable email for your users ? Because the Content filter can't understand whats in encrypted emails.

It boils down to one simple fact -- 30 or so years ago when most of these protocols were designed, they werent designed with security in mind. Any subsequent security measures that have been added are afterthoughts (such as SYN cookies, initial sequence number generation etc) look at SMTP.. can you think of a more insecure protocol ? No real validation or authentication... the proof lies in your inbox with 300+ spam messages.

We haven't even considered session hijacking here.. that in itself would be another way into the network. There are thousands of possible attack vectors that can be applied to a theoretical situation . Some of the fanciest schemes may not work, but there will be some really easy ways in and out.

All that said, I have a paper here called "Placing Backdoors Through Firewalls" which is by the same people who wrote the Reverse WWW trojan (thc.org). You can find this paper on their site. Give it a read, they build on a few of the ideas I've given here, as well as give some really interesting ideas of their own.

A quick google for 'bypassing firewalls' will show you that this is not a topic that can be done justice in a forum. It is almost an art, and I had to trivialise it for the sake of the article. I am however willing to elaborate on the issue (as the length of this post amply demonstrates ;))

Its a fun debate ain't it :) hopefully some more members will join in !

Cheers,
Sahir Hidayatullah.
Firewall.cx Staff - Associate Editor & Security Advisor
tftfotw.blogspot.com
The administrator has disabled public write access.

Re: Reverse Trojans 12 years 10 months ago #2294

  • sahirh
  • sahirh's Avatar
  • Offline
  • Honored Member
  • Posts: 1700
  • Karma: 0
I cannot describe it much better than this :
Exploitation of data streams authorized by a network access control system for an arbitrary data transfer :

Authorizations of data transit between interconnected networks via one or several network access control systems are defined and implemented with respect to a security policy. An exemplary one regarding network access control bases itself on the following assumption: blocking all data streams that were not explicitly defined. In other words : "We block everything, and then we allow specific and precise access" !

The most frequent network access control schemes rely on the use, combined or not, of tools performing some sort of filtering at several layers of the OSI model (networking devices : layers 2 and 3, routers : layer 3, firewall : layers 3, 4 and sometimes 5). Other tools can be associated with these devices whose interactions with networking streams are located at the OSI model higher layers: mandatory servers (proxy), anti-virus, Intrusion Detection Systems, content filtering tools, Anomaly Detection Systems, etc.

Nevertheless, regardless of using these network access control schemes, it is possible at the present time, via several evasion methods, to use streams authorized by the security policy to transit arbitrary data whose traffic is not allowed thought of. These evasion means allow the opening of communication channels (covert channel, subliminal channels) giving access to external services from within the internal network or access to internal resources from the external network.

The corner stone of these evasion techniques relies on the lack of verification of the intrinsic value of transiting data. The different implementations of access control schemes depend upon a sort of "protocol abstraction" that makes that a data transfer relying on the several layers of the OSI model can only be used to carry data originating from underlying protocols.

Though it is possible to detect certain abnormal streams traversing a network access control system, one can take for granted that the use of certain communication channels is undetectable at the present time.

entreelibre.com/cctt/index_en.html
Sahir Hidayatullah.
Firewall.cx Staff - Associate Editor & Security Advisor
tftfotw.blogspot.com
The administrator has disabled public write access.

Re: Reverse Trojans 12 years 10 months ago #2297

  • Cheetah
  • Cheetah's Avatar
  • Offline
  • Frequent Member
  • Posts: 72
  • Karma: 0
Hi

I have made it short to fit in page, let me check how its now.

Seg 1
_____________
| |
<Int>---<FW>
<AppProxy/Antivirus>---<Clients>
|_______________|
Seg 2

I think now its more visible. Yes! its just a standard design. Note I have purposely omited a DMZ for DNS, email, httpd because my topic was only on the reverse trojans.

:) I was not aware that the reverse trojans can connect though the proxy and tunell traffic through it. Thanks for the link and details.

But for the SPAM, not even a single one reaches me. Thanks to Brightmail & eManager.

Thanks & Regards
Cheetah
Kind Regards,
<b>Cheetah</b>
<i>The outcome of devotion is, quality!</i>
The administrator has disabled public write access.

Re: Reverse Trojans 12 years 10 months ago #2298

  • Cheetah
  • Cheetah's Avatar
  • Offline
  • Frequent Member
  • Posts: 72
  • Karma: 0
Ah!! the Diagram does no justice while viewing.

Okay <Int>---<FW>
<AppProxy/Antivirus>---<Clients>

To put it simple, the firewall (with NAT) and app proxy(behind NAT) is in one segment while the clients are in different segment. As you told, a standard design.

No DMZ, NIDS or anything else discussed. Just relevant for reverese trojan alone.

Regards
Cheetah
Kind Regards,
<b>Cheetah</b>
<i>The outcome of devotion is, quality!</i>
The administrator has disabled public write access.
  • Page:
  • 1
  • 2
Time to create page: 0.084 seconds

CCENT/CCNA

Cisco Routers

  • SSL WebVPN
  • Securing Routers
  • Policy Based Routing
  • Router on-a-Stick

VPN Security

  • Understand DMVPN
  • GRE/IPSec Configuration
  • Site-to-Site IPSec VPN
  • IPSec Modes

Cisco Help

  • VPN Client Windows 8
  • VPN Client Windows 7
  • CCP Display Problem
  • Cisco Support App.

Windows 2012

  • New Features
  • Licensing
  • Hyper-V / VDI
  • Install Hyper-V

Linux

  • File Permissions
  • Webmin
  • Groups - Users
  • Samba Setup