Re: [tor-talk] Hidden service security w. Apache/Win32

2012-02-20 Thread Martin Hubbard
This is why it's wise to access Tor through reputable multi-hop VPNs that 
operate in privacy-friendly places. If it really matters, you can tunnel VPNs 
through other VPNs.

- Original Message -
From: Ralf-Philipp Weinmann
Sent: 02/20/12 10:06 AM
To: Ondrej Mikle
Subject: Re: [tor-talk] Hidden service security w. Apache/Win32

 On 2012-02-19 19:58 CET, Ondrej Mikle wrote:  Addendum for truly 
uberparanoid installation:   [various best practices]   With the 
uberparanoid installation, the greatest risk is a return-to-libc-style  attack 
on Tor where attacker instructs Tor to make circuit to a node controlled  by 
attacker, thus revealing IP. So this is the part where you should realize how 
futile all of that pain of setting up policies is… -RPW 
___ tor-talk mailing list 
tor-talk@lists.torproject.org 
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk


Re: [tor-talk] Hidden service security w. Apache/Win32

2012-02-20 Thread Fred Toben
 Is the time sync spoofing even applicable to hidden services?
 How can the MS time server tampering with the exit nodes be applicable to
 hidden services?

 It has nothing to do directly with Apache or the hidden service.

 For correct operation Tor needs the correct time and date. Windows will
 request the time from Microsoft servers, and I am not sure, if this
 request is save (authenticated) - if not, an evil exit node can spoof the
 reply.

 And when Tor isn't properly working, also your hidden service is in danger.

I think you misunderstand my setup.

VM 1 serves the Apache installation, and VM 2 runs the Tor hidden service.

Therefore as far I understand Only VM 2 must have its clock correctly set.

VM 1 on the other hand serves the Apache installation, and there is no
reason why the date, time and timezone of respectively VM 1 and VM 2 has
to correspond.

The connection between VM 1 (Apache) and VM 2 (Tor listening on the
internal hidden service port)is socks 5, and there is no outbound internet
connection permitting any timesync or Microsoft service to break out of VM
1.

An attacker attempting to correlate the time of my server (through a HTTP
request) with my Tor machine will only retrieve the date, time, and
timezone of the (virtualized and locked down) Apache  installation.


___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk


Re: [tor-talk] Hidden service security w. Apache/Win32

2012-02-20 Thread Ralf-Philipp Weinmann

On Feb 20, 2012, at 8:57 PM, Ondrej Mikle wrote:

 On 02/20/2012 05:06 PM, Ralf-Philipp Weinmann wrote:
 On 2012-02-19 19:58 CET, Ondrej Mikle wrote:
 
 Addendum for truly uberparanoid installation:
 
 [various best practices]
 
 With the uberparanoid installation, the greatest risk is a 
 return-to-libc-style
 attack on Tor where attacker instructs Tor to make circuit to a node 
 controlled
 by attacker, thus revealing IP.
 
 So this is the part where you should realize how futile all of that pain of 
 setting up policies is…
 
 I disagree. Even without RBAC, grsecurity makes ROP-style attacks damn hard.

n.b.: I wasn't commenting on the memory corruption mitigations offered by 
grsec, those are damn fine. Rather, what I was commenting on was the fact that 
RBAC is mostly worthless for the threat you are trying to address (disclosing 
the IP address server running the hidden service) unless you've really screwed 
up somewhere else.

 Many tricks I've seen in defeating ASLR and other anti-ROP mitigations 
 required
 some side-channel knowledge. Which is where the policy can do good job at
 stopping the attacker to gain such side-channel information.

Yes, you'll need to bake yourself an info leak to deal with grsec.

 Since with gentoo you compile everything with your own settings of
 compiler/linker and whatnot, that alone makes it hard for attacker to search 
 for
 gadgets (pieces of code that can be used for ROP).

I'm familiar with the technique, and agree that custom compiler/linker settings 
on the box you're attacking can be a PITA to deal with. Depending on the skills 
of the adversary, they might buy you a couple of months.

 
 Is the additional RBAC policy worth it? Depends on your threat model. I've 
 had a
 server running with grsecurity RBAC enabled for experimentation several years
 ago. The policies took a few days to write, but that's far from unfeasible.

RBAC, SELinux and App Armor (yes, I've added more clunky ways to band-aid buggy 
code to prevent it from spilling the lifeblood of your box) are useful for some 
things. I just really doubt they will buy you additional protection in the 
threat model we're talking about.

Cheers,
-RPW
___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk


Re: [tor-talk] Hidden service security w. Apache/Win32

2012-02-20 Thread Ondrej Mikle
On 02/20/2012 05:06 PM, Ralf-Philipp Weinmann wrote:
 On 2012-02-19 19:58 CET, Ondrej Mikle wrote:
 
 Addendum for truly uberparanoid installation:

 [various best practices]

 With the uberparanoid installation, the greatest risk is a 
 return-to-libc-style
 attack on Tor where attacker instructs Tor to make circuit to a node 
 controlled
 by attacker, thus revealing IP.
 
 So this is the part where you should realize how futile all of that pain of 
 setting up policies is…

I disagree. Even without RBAC, grsecurity makes ROP-style attacks damn hard.
Many tricks I've seen in defeating ASLR and other anti-ROP mitigations required
some side-channel knowledge. Which is where the policy can do good job at
stopping the attacker to gain such side-channel information.

Since with gentoo you compile everything with your own settings of
compiler/linker and whatnot, that alone makes it hard for attacker to search for
gadgets (pieces of code that can be used for ROP).

Is the additional RBAC policy worth it? Depends on your threat model. I've had a
server running with grsecurity RBAC enabled for experimentation several years
ago. The policies took a few days to write, but that's far from unfeasible.

Ondrej
___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk


Re: [tor-talk] Hidden service security w. Apache/Win32

2012-02-19 Thread Karl Hakmller
On Sun, 19 Feb 2012 12:50:47 -
Fred Toben red...@tormail.net wrote:

 Hello Everybody
 
 I am in the process of setting up a hidden service with Apache 2.2
 under Windows.
 
 I run Apache (Win32) in a virtual machine and Tor in a separate
 virtual machine under VMware Workstation.
 
 VM 1 runs Apache and VM 2 runs Tor.
 
 VM 1 is connected to VM 2 through an internal host only network and no
 connection to Apache is possible except through the host only network.
 
 Apache runs under a limited user account and I have locked down  all
 potentially unsafe modules (PHP, autoindex etc) and I have tested
 that the hidden service is connectable from the outside with
 its .onion address.
 
 So far I haven't found any public info about the possible downsides of
 running a hidden service under Windows.
 
 Is running the instances of Tor and Apache in separate locked down
 virtual environments more secure than having Apache and Tor listening
 within the same machine?
 
 Or is Windows an absolute no when considering running a secure hidden
 service?
 
 Another question is whether my setup (VM1=application, VM2=Tor)
 ameliorates the problems with proxified applications.
 
 On the Torproject site I read that proxifying applications is often
 dangerous because the applications might leak the machine's real IP
 address.
 
 But if the proxified aplication runs within a virtual machine, and
 only connects to an instance of Tor running within another VM, what
 info could leak through the application other than the IP of the VM?
 
 
 ___
 tor-talk mailing list
 tor-talk@lists.torproject.org
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

An extremely interesting post.  I'm new to tor and am considering
setting up either a relay or a hidden service on an Ubuntu machine
running behind a single router on my home net but have hesitated to set
it up because of concerns about leakage.  I'll follow this thread with
great interest though I'm too much of a newbie here to contribute
anything substantive.

___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk


Re: [tor-talk] Hidden service security w. Apache/Win32

2012-02-19 Thread Gozu-san
It would be very dangerous to use Windows in any way for running hidden
services!  Run Linux and VirtualBox on your host machine.  Ubuntu is
probably best if you're new to Linux.  Have your host machine access the
Internet through a reputable multi-hop VPN service, and firewall it to
prevent leaks.  That way, even if something goes wrong with your Tor
setup, you're not leaking from your real IP address.  Run Tor on a
router VM, as a transparent proxy, and run Apache on a Linux VM.  LAMP
setup in Ubuntu is trivial.

If you need Windows, it would be best to use another machine.  If you
must use the same machine, run Windows as a VM.  In that case, you'll
want to use a gateway VM (e.g., pfSense) for your VPN connection
(firewalled to prevent leaks).  That way, Windows won't be advertising
the same IP address that Tor is using.

On 19/02/12 12:50, Fred Toben wrote:

 Hello Everybody
 
 I am in the process of setting up a hidden service with Apache
 2.2 under Windows.

SNIP

 Or is Windows an absolute no when considering running a secure
 hidden service?

SNIP
___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk