Re: Tunnelling via SSL anonymously to connect to remote host(s)

From: Jason (jason@sickofspam.com)
Date: 03/27/02 

From: Jason <jason@sickofspam.com>
Date: Tue, 26 Mar 2002 23:05:08 -0500

As an engineer working often with firewalls & IDS, I know your chore is heavy as paper trails are kept everywhere from ISP to
backbone to anonymizers to target networks. Here in the USA it's even worse because Canivore devices capture your traffic at
most ISP's. Our hypothetical character in this story might consider latching onto somebody's wireless network (sniff for IP's
and ride the route out). College campuses are also quite easy as IP's are often not tracked so closely, bandwidth is plentiful
and the firewall policy is loose (like the ladies). There are other ways but I'd hate to give away all the goodies...

Please keep us all informed as to the progress of our ficiticious hero.

Anonymous wrote:

> Problem Outline
> ---------------
> Imagine the following ficticious :-) scenario: You're a successful cosultant and you work your balls off for an
> international firm, but the SOB project manager does not sign your time sheets for the last few weeks before your contract
> finishes. After agreeing to overtime he suffers amnesia when it comes to signing the timesheets. Now the agency will not
> pay you unless you present SIGNED time sheets. You know you are in the right and you even have evidence to proove your
> version of the story, however you live in a country which is several thousand KMs from where you were doing your contract
> and you reckon that you would spend several thousand USD on legal/travel expenses in order to win the case (and you are not
> always guaranteed recouperation of expenses if you win!). So you decide to right of the $10000 or so they owe you and put
> it down to experience. The SOB project Mgr gets a raise and promotion because his budget is $10k lighter and as a result of
> the consultant's hard work (working 90hrs/wk) the project was in on time. You then talk to some other consultants and they
> tell you similar stories where the same *** has done a trick on them, whereby he does not sign the final month's
> timesheets when he knows that the contractors are flying back to Euorpe/US etc. He knows that a Jewish court will favour a
> local Jew over a foreigner and that its too much hastle for people to fly back to Israel to take him/Oracle to court.
>
> So this consultant decides that the SOB project Mgr, lets call him ASHER RUBEN (TEL AVIV/ORACLE ISRAEL) needs to suffer some
> inconvenience for the considerable damages he has caused him and many other consultants. Being a unix and sysbase
> specialist the consultant has all the skills to ensure that this SOB thinks twice before he screws another consultant.
> Sometimes the law just lets you down and you have to get your own justice and stop unscrupulous assholes like ASHER RUBEN
> from defrauding individuals. The problem however is that these days there is so much forensic evidence left behind if one
> hacks into a computer system and the legal system comes down on hackers like a tone of bricks that even if you have to
> skills to hack into a system, you cannot do it without leading them to your door!
>
> Questions
> ---------UNDER A PURELY FICTICIOUS SCENARIO AND FOR EDUCATIONAL PURPOSES ONLY
>
> a) How can one telnet into the final system and run port-scanning tools wihout the source IP address being the one you have
> used to dial-up your ISP or if you are behind a corporate n/w to your desk?
>
> b) Conventionally hackers login to an intermidiate server so the target thinks you come from xyz corp. However xyz corp has
> logs that you came from there. So is there a way of perhaps using technologies like stunnel (or some other TCP wrapper
> technique)and Shell accounts on intermidiate servers to somehow setup your own proxy so that the trail stops there? I know
> telnet is not using SSL but say tools such as SecureCRT, SSH etc will still forward your IP address, even if your ISP cannot
> snoop on you and you avoid your ISP's logs.
>
> Ok, the above are just ideas I am throwing around. I need help from an expert hacker on how to stop the trail getting back
> to my IP address. How can I stop the trail dead at some intermediate server in my chain to the target system. There must
> be a way as there's an awful lot of hacking going on undetected :-) Of course any comments are purely for educational
> purposes!
>
> Trust me this is for a just cause as there are plenty of lying, cheating hypocryts like RUBEN out there facing a contractor.
> You try and do an excellent job and these unscrupulous bastards hide behind their corporations and of course fucking
> computer agencies are wankers who will always take the side of the client as they know that they simply view contractors as
> a FIFO and replace you with another warm body, even if he is unsuitable for the job. To any contractors, a warning. If you
> are offered a contract with ORACLE ISRAEL, run like wind, they are lying, cheating bastards and this is the view of many
> contractors I have spoken to! Another ORACLE site to watch out for is ORACLE GERMANY (beware of project Managers: Peter van
> den Berg who sometimes works out of the Netherlands office, and Gunnar Bower) Both these guys will smile at you and give you
> a look as if butter would not melt in their mouth, yet they are total two-faced bastards and once screwed me out of several
> thousand EUROS.