Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Secure-Shell
[Top] [All Lists]

Re: Dynamic forward security

Subject: Re: Dynamic forward security
Date: Thu, 10 Apr 2008 11:11:02 +0300 (IDT)
On Tue, 8 Apr 2008, Johan Anderssen wrote:
Now, my question is, if the remote end with ssh should be
compromised, is theoretically any way to go over the open ssh
connection to access the client side of the computer, by using a
buffer overflow or bug in ssh to execute code or access the local
network.

If you assume that there is a buffer overflow or any other exploitable
bug in your ssh client, then it can be used to attack you.

Can sshd initiate connections the opposite way in such a
configuration or is it only ssh that initiates all connections to
the sshd endpoint?

If you forward from local port to remote then (if there are no bugs in
ssh) it is possible only to initiate connections from local to remote,
but packets are sent both ways.

Since this tunnel can be open for quite some time, it could be a
possible way back into the client system, or am i just too paranoid?

If an attacker controls remote system he can modify packets that are
sent back to your local host and thus may exploit bugs in your local
applications (e.g., web browser or mail client). Btw, it does not
really matter how long the channel stays open since automated attacks
can be executed in a fraction of a second.

-- 
Regards,
ASK

<Prev in Thread] Current Thread [Next in Thread>