Re: Traces left by Torpark, and other security discussion (was Re: TorPark)

[Arrakistor <arrakistor@xxxxxxxxx>]

Hello Steven,

I will check out the claims about the registry. I performed a diff on
it from running and after and found only the SSL seed value changed.
Perhaps there are some other changes. I will check those out for sure.
Regarding the rest of the registry keys, if they are indeed persistant
and constant, I will add code to remove them.

I am wondering if all of that is moot, since we are not actively
destroying the data. I can also fix the swap at reboot issue, but that
may require changing a reg value permanently. I will certainly look at
that.

In the mean time, the whole website is being redone and should be up
in a week. I will post the updates then, and some of the other fixes
we talked about.

And it is true, we are avoiding scripts from torpark.nfshost.com, or
at least that was the plan, as it was going to be running an update
server. In actuality, we are moving the update server to a different
address. The result there is that we may allow scripts to run, but I
am sure we will be automatically adding an SSL certificate acceptance
to the client so the user doesn't get annoying popups when the client
tries to update. The releases will be signed, and the updater will
automatically use SHA1.

Regarding the swap, that really isn't my specialty, so you are right,
the claim is overstated. I will try to figure out a solution. I spoke
with a few developers about creating ram drives, but this requires
system drivers and administrator access. It may be that we cannot do
anything about it, or more to the point it may be moot because Tor
creates many network signatures. I would sure be interested in
everyone's input.

The whole thing is going to be rewritten into python within the next
few months, so that the open-source community can be more involved in
Torpark development. Let's face it, NSIS is a great scripting
language, but is platform dependent and very limited.


Sunday, November 26, 2006, 7:07:00 PM, you wrote:

> On Mon, Nov 13, 2006 at 03:17:31PM -0600, Arrakistor wrote:
>> Until  an  official  doc  is  produced  for  helping users compile and
>> understand the choice that were made, the answer to all your questions
>> is here: http://www.torrify.com/forum/viewtopic.php?p=1800

> I was also interested in the answer to these questions, so I tried out
> Torpark under Virtual PC[1] and with Process Monitor[2] running to see
> what really happened. In some cases it doesn't quite match your
> documentation. This was a fairly cursory examination, and it certainly
> isn't complete so please correct me if any of my points are incorrect.

> In [3] Arrakistor wrote:
>> It does not use the swap file on the host drive unless there is not
>> enough physical memory, for which then windows resorts to swap. 

> This isn't quite how modern operating systems work. As the hard disk
> is so slow compared to main memory, operating systems will
> aggressively page unused data to swap, and use main memory for disk
> cache.

> To test this I ran Torpark with a fairly generous amount of RAM
> (512MB). Although RAM never ran out, there was significant swap file
> usage (even idle, it used 149MB swap). On reboot, the pagefile.sys
> file contained 2367 mentions of "Torpark". These were mainly
> filenames, but also contained user data. For example:
>  "E:\Torpark
> 1.5.0.7\App\tor\data\cached-status\7EA6EAD6FD83083C538F44038BBFA077587DD755"
>  "ushCircuit 1.1 - Flush the tor circuit on port 9051 (Torpark): Installing"
>  
>> That is a windows issue I cannot yet control, but I will definitely
>> look into dealing with it.

> This is indeed a tricky problem to deal with, but in the mean time,
> perhaps you should clarify the <meta description> on the Torpark
> homepage.  
>  "[Torpark] leaves no track, is small, portable, and costs nothing."

> Leaving traces behind may be unavoidable, but making users think that
> it does not could lead to them facing problems. Some more examples are
> continued later.

>> Use NoScript to intercept Java, Javascript, and Flash. 

> In prefs.js, I noticed the following line:
> user_pref("capability.policy.maonoscript.sites", "... mozillazine.org
> noscript.net torpark.nfshost.com ...");

> If I understand it correctly, this exempts your site from the
> Javascript blocking. Is there any particular reason for this? I'm
> certainly not suggesting any malicious intent, but DNS does get
> spoofed, domain names do get hijacked, court orders do get passed and
> XSS vulnerabilities do get found.

> If there is no convincing reason for exempting certain sites from
> Javascript blocking, prudent defence in depth principles would dictate
> that they not be exempted. This also applies to the noscript and
> Mozilla sites.

>> It does not currently add any lines to the registry.

> It creates at least 3 ones which are persistent after reboot, but
> there might be more that I missed.

> Process monitor shows Torpark, Flushcircuit and Firefox trying to
> create a large number of entries in the registry, but many already
> exist, created presumably by Internet Explorer or Windows itself. For
> example:
>  RegSetValue
> HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2\{eba32d83-4625-11da-89de-806d6172696f}\BaseClass
>  RegSetValue
> HKCU\Software\Microsoft\Windows\CurrentVersion\Internet
> Settings\ZoneMap\UNCAsIntranet
>  RegSetValue
> HKCR\TypeLib\{1EA4DBF0-3C3B-11CF-810C-00AA00389B71}\1.1\0\win32\(Default)

> Flushcircuit also creates several keys like this one, but they do not
> survive a reboot:
>  RegSetValue    HKLM\SYSTEM\ControlSet001\Control\Session
> Manager\PendingFileRenameOperations
>  
> One registry key that Firefox creates that is new, and survives a reboot is:
>  RegSetValue
> HKCU\Software\Microsoft\Windows\ShellNoRoam\MUICache\E:\Torpark
> 1.5.0.7\Data\torpark\profile\extensions\{65f3d609-18c1-4f62-bcef-1973b6abeab4}\flushcircuit.exe

> There are similar ones for Firefox itself and Torpark.

>> It only touches the drive where it is run from, and the RAM of the
> machine it is running on
>          
> It creates a number of files, on the hard disk, which remain after
> reboot.

> Some temporary files from Nullsoft installer are left:
>  Documents and Settings/<username>/Local Settings/Temp/nst4.tmp
>  Documents and Settings/<username>/Local Settings/Temp/nszB.tmp

> Also there are these files used by the Windows task scheduler to
> optimise future application loading times[4]:
>  WINDOWS/Prefetch: FIREFOX.EXE-07686B34.pf
>  WINDOWS/Prefetch: FLUSHCIRCUIT.EXE-129F88FF.pf
>  WINDOWS/Prefetch: TORCIRCUITSTATUS.EXE-2E679AC0.pf
>  WINDOWS/Prefetch: TOR.EXE-29FB7B10.pf
>  WINDOWS/Prefetch: TORPARK.EXE-18DD2E51.pf
>  WINDOWS/Prefetch: TOR_RESOLVE.EXE-2BA063E1.pf

> The Nullsoft installer also creates this file in the system directory:
>  WINDOWS/system32: gdiplus.dll

> Although Torpark includes its own profile, Firefox still creates one
> here:
>  Documents and Settings\<username>\Application Data\Mozilla\Firefox
> This only contains pluginreg.dat.

> A large number of files are also modified, but I haven't gone through
> these to find out which are by Torpark and not parts of Windows.

> This is only a start, but I hope this information will be of some help
> towards producing a comprehensive and accurate analysis of Torpark and
> its components.

> Thanks,
> Steven.

> [1] http://www.microsoft.com/windows/virtualpc/default.mspx
> [2]
> http://www.microsoft.com/technet/sysinternals/ProcessesAndThreads/processmonitor.mspx
> [3] http://www.torrify.com/forum/viewtopic.php?p=1800
> [4] http://msdn.microsoft.com/msdnmag/issues/01/12/XPKernel/