Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - astor

Pages: 1 ... 84 85 [86] 87 88 ... 208
1276
Security / Re: Law Enforcement on SR??? PLEASE READ
« on: May 21, 2013, 09:11 pm »
That is confirmed malware. I just spoke to someone who visited that site, actually ran the Java, and now multiple anti-virus programs detect malware on his computer where there was none before.

Now to determine whether it's LE or some random asshole who wants to install keyloggers to steal account credentials, or possibly enumerate the IP addresses of vendors and blackmail them.

1277
Are these messages going to only UK vendors, or only people in the UK? That would be an important fact.

1278
Security / Re: Law Enforcement on SR??? PLEASE READ
« on: May 21, 2013, 08:39 pm »
Now's a perfect time to boot up a disposable VM with a Tor gateway and figure out what this javaupdate.exe does...

The sad part is, there are people visiting that site over clearnet right now...

1279
Security / Re: Law Enforcement on SR??? PLEASE READ
« on: May 21, 2013, 08:29 pm »
The site doesn't show up in a Google search. This an attack that I've predicted in the many times I've said not to visit links posted on this forum over clearnet. The attacker knows that only people on SR know about his site, so anyone who visits over clearnet has linked their IP address (and possibly their identity) to the fact that they use SR.

The Java app is probably supposed to phone home to expose the IP addresses of Tor users.

1280
Security / Re: Schneier: The Internet is a Surveillance State
« on: May 21, 2013, 03:57 pm »
Related article by Schneier.

http://www.guardian.co.uk/technology/2013/may/16/internet-of-things-privacy-google


Will giving the internet eyes and ears mean the end of privacy?

Corporations and governments are turning the internet into a colossal, always-on surveillance tool. Once passive objects are able to report what's happening, where is the power balance?


The internet has turned into a massive surveillance tool. We're constantly monitored on the internet by hundreds of companies -- both familiar and unfamiliar. Everything we do there is recorded, collected, and collated – sometimes by corporations wanting to sell us stuff and sometimes by governments wanting to keep an eye on us.

Ephemeral conversation is over. Wholesale surveillance is the norm. Maintaining privacy from these powerful entities is basically impossible, and any illusion of privacy we maintain is based either on ignorance or on our unwillingness to accept what's really going on.

It's about to get worse, though. Companies such as Google may know more about your personal interests than your spouse, but so far it's been limited by the fact that these companies only see computer data. And even though your computer habits are increasingly being linked to your offline behaviour, it's still only behaviour that involves computers.

The Internet of Things refers to a world where much more than our computers and cell phones is internet-enabled. Soon there will be internet-connected modules on our cars and home appliances. Internet-enabled medical devices will collect real-time health data about us. There'll be internet-connected tags on our clothing. In its extreme, everything can be connected to the internet. It's really just a matter of time, as these self-powered wireless-enabled computers become smaller and cheaper.

Lots has been written about the "Internet of Things" and how it will change society for the better. It's true that it will make a lot of wonderful things possible, but the "Internet of Things" will also allow for an even greater amount of surveillance than there is today. The Internet of Things gives the governments and corporations that follow our every move something they don't yet have: eyes and ears.

Soon everything we do, both online and offline, will be recorded and stored forever. The only question remaining is who will have access to all of this information, and under what rules.

We're seeing an initial glimmer of this from how location sensors on your mobile phone are being used to track you. Of course your cell provider needs to know where you are; it can't route your phone calls to your phone otherwise. But most of us broadcast our location information to many other companies whose apps we've installed on our phone. Google Maps certainly, but also a surprising number of app vendors who collect that information. It can be used to determine where you live, where you work, and who you spend time with.

Another early adopter was Nike, whose Nike+ shoes communicate with your iPod or iPhone and track your exercising. More generally, medical devices are starting to be internet-enabled, collecting and reporting a variety of health data. Wiring appliances to the internet is one of the pillars of the smart electric grid. Yes, there are huge potential savings associated with the smart grid, but it will also allow power companies – and anyone they decide to sell the data to – to monitor how people move about their house and how they spend their time.

Drones are the another "thing" moving onto the internet. As their price continues to drop and their capabilities increase, they will become a very powerful surveillance tool. Their cameras are powerful enough to see faces clearly, and there are enough tagged photographs on the internet to identify many of us. We're not yet up to a real-time Google Earth equivalent, but it's not more than a few years away. And drones are just a specific application of CCTV cameras, which have been monitoring us for years, and will increasingly be networked.

Google's internet-enabled glasses – Google Glass – are another major step down this path of surveillance. Their ability to record both audio and video will bring ubiquitous surveillance to the next level. Once they're common, you might never know when you're being recorded in both audio and video. You might as well assume that everything you do and say will be recorded and saved forever.

In the near term, at least, the sheer volume of data will limit the sorts of conclusions that can be drawn. The invasiveness of these technologies depends on asking the right questions. For example, if a private investigator is watching you in the physical world, she or he might observe odd behaviour and investigate further based on that. Such serendipitous observations are harder to achieve when you're filtering databases based on pre-programmed queries. In other words, it's easier to ask questions about what you purchased and where you were than to ask what you did with your purchases and why you went where you did. These analytical limitations also mean that companies like Google and Facebook will benefit more from the Internet of Things than individuals – not only because they have access to more data, but also because they have more sophisticated query technology. And as technology continues to improve, the ability to automatically analyse this massive data stream will improve.

In the longer term, the Internet of Things means ubiquitous surveillance. If an object "knows" you have purchased it, and communicates via either Wi-Fi or the mobile network, then whoever or whatever it is communicating with will know where you are. Your car will know who is in it, who is driving, and what traffic laws that driver is following or ignoring. No need to show ID; your identity will already be known. Store clerks could know your name, address, and income level as soon as you walk through the door. Billboards will tailor ads to you, and record how you respond to them. Fast food restaurants will know what you usually order, and exactly how to entice you to order more. Lots of companies will know whom you spend your days – and nights – with. Facebook will know about any new relationship status before you bother to change it on your profile. And all of this information will all be saved, correlated, and studied. Even now, it feels a lot like science fiction.

Will you know any of this? Will your friends? It depends. Lots of these devices have, and will have, privacy settings. But these settings are remarkable not in how much privacy they afford, but in how much they deny. Access will likely be similar to your browsing habits, your files stored on Dropbox, your searches on Google, and your text messages from your phone. All of your data is saved by those companies – and many others – correlated, and then bought and sold without your knowledge or consent. You'd think that your privacy settings would keep random strangers from learning everything about you, but it only keeps random strangers who don't pay for the privilege – or don't work for the government and have the ability to demand the data. Power is what matters here: you'll be able to keep the powerless from invading your privacy, but you'll have no ability to prevent the powerful from doing it again and again.

1281
Security / Re: Deleting Encrypted Documents
« on: May 21, 2013, 03:13 pm »
If an adversary can decrypt your encrypted volume, then you're already screwed, and if you're operating under the assumption that your encrypted volume can/will be decrypted, it's pointless to use an encrypted volume. Then you're no better off than people who try to shred individual files.

1282
TorBrowser is pretty well protected, even with NoScript disabled. You can read the details of what they try to protect against here:

https://www.torproject.org/projects/torbrowser/design/

Increasingly, it's not just JavaScript. HTML5 and CSS3 bring lots of great new features to the web, but some of them threaten your anonymity. As time goes on, this will only get worse. So it's not enough to block JavaScript anymore. That's why TorBrowser is more than a torified Firefox, it gets lots of patches to protect you against all kinds of leaks, and it's important to use TorBrowser rather trying to torify other browsers.

1283
Newbie discussion / Re: Newbie PGP Club
« on: May 21, 2013, 04:05 am »
yes think i did  it

the exact terminal command is

gpg -a -e -r Radium plain

my problem was missing the -a. without it it saves the plain message in a file plain.gpg which you can't just copy and paste
the -a saves the plain message in a plain.asc file, below is the output!

Yep. You can also put the word

armor

on a separate line in ~/.gnupg/gpg.conf, and it will ASCII armor the text for you (put it in a .asc file) without having to type the -a each time.

Command line gpg is very forgiving. It will ask you for any info that you don't give it in the command. So the minimum you need to type to encrypt a message is:

gpg -e

It will ask for the recipients, and as long as you type some (unique) part of the name, address or key ID, it will select the right one. You can keep entering recipients until you leave the recipient field blank, then it will give you a cursor where you can type your message, and hit ctrl+d when you're done. It will encrypt the message right in the terminal. No need to create text files every time you write a message. I only do that for really long messages.

Likewise, when decrypting messages sent to me, usually don't paste them into a text file. I type

gpg -d

hit enter, and paste the message directly into the terminal, then hit ctrl+d.

It's actually faster than a GUI PGP program, at least if you spend most of your time with a terminal open anyway. ;)

1284
Security / Trawling, Mapping, and Attacking Tor Hidden Services
« on: May 21, 2013, 01:38 am »
This person positioned himself as one of Silk Road's HSDirs. The highlights of his research:

1. SR gets 60,000 descriptor requests per day, which might be equivalent to "visits" per day
2. There are at least 40,000 onion domains on the network
3. It is surprisingly easy to DOS a hidden service by positioning yourself as all 6 of its HSDirs

http://donncha.is/2013/05/trawling-tor-hidden-services/

================


Tor hidden services have got more media attention lately as a result of some notorious sites like the Silk Road marketplace, an online black market. On a basic level, Tor hidden services allow you to make TCP services available while keeping your server’s physical location hidden via the Tor anonymity network.

TL;DR

* Tor hidden service directories (HSDir’s) receive a subset of hidden service look-ups from users, allowing them to map relative popularity/usage of hidden service.
* An adversary with minimal resources can carry out complete DoS attacks of Tor hidden services by running malicious Tor hidden service directories and positioning them in a particular part of the router list.
* Many look-ups for Tor hidden services go to the incorrect hidden service directories which negatively affects the initial time to access the site.
* Hidden services such as are popular, sites such as the Silk Road marketplace receive more than 60,000 unique user sessions a day.

Introduction

For users to access a hidden service they must first retrieve a hidden service descriptor. This is a short signed message created by the hidden service approximately every hour contain a list of introduction nodes and some other identifying data such as the descriptor id (desc id). The desc ID is based on a hash of some hidden service information and it changes every 24 hours. This calculation is outlined later in the post. The hidden service then publishes its updated descriptor to a set of 6 responsible hidden service directories (HSDir’s) every hour. These responsible HSDir’s are regular node on the Tor network which have up-time longer than 24 hours and which have received the HSDir flag from the directory authorities. The set of responsible HSDir’s is based on their position of the current descriptor id in a list of all current HSDir’s ordered by their node fingerprint. This is an implementation of a simple DHT (Distributed Hash Table).

A client who would like to retrieve the full HS descriptor will calculate the time based descriptor id and will request it from the responsible HSDir’s directly.

Once the client has a copy of the hidden service descriptor they can attempt to connect to one the introduction point and create a complete 7 hop circuit to the hidden service.

This is a very brief explanation which the Tor Project has outlined much more clearly on their hidden service protocol page but it should provide enough information to understand the following information.

The Problems

* Any one can set up a Tor node (HSDir) and begin logging all hidden service descriptors published to their node. They will also receive all client requests allowing them to observe the number of look-ups for particular hidden services.
* The list of responsible HSDir’s for a hidden service is based on the calculated descriptor ID and an ordered list of HSDir fingerprints. As the descriptor ID’s are predictable, and the node fingerprint is controlled by an adversary. The can position themselves to be the responsible directories for a targeted hidden service and subsequently perform a DoS attack by not returning the hidden service descriptor to clients. There is nothing the hidden service can do about this attack. They must rely on the Tor Project authority directories to remove the malicious HSDir’s from the consensus.

Information Gathering from the DHT

Hidden services must publish their descriptors to allow clients to reach them. These descriptor id’s are deterministic but over time any HSDir should have an equal chance of receiving the descriptor for any particular hidden service as part of the DHT. As the descriptor is replicated across 6 HSDir’s, any single responsible HSDir should receive up to 1/6 of all client look-ups for that hidden service providing a good means of estimating hidden service popularity.

This data can be made more accurate by running more Tor HSDir’s which have identity digest‘s in the responsible range, to the point where all the responsible HSDir’s are controlled by the observer.

There are currently about 1400 nodes with the ‘HSDir’ flag running. For the past 2 months I have run 4 Tor nodes and logged all hidden service requests that they have received. Each hidden service publishes to 6 HSDir’s every day, and will publish to 360 or approximately 25% of HSDir’s in a 2 month period. As I am running 4 nodes I statistically should have received a copy of every hidden service that was online for those 60 days. While the distribution will not be perfect, my data should contain a representative set of hidden service activity. Here are some stats from those 4 nodes:

* Received 1.3 million requests for 3815 unique hidden services my nodes were responsible for.
* Got 16.03 million requests for descriptors my nodes were not currently responsible for.
* Received published descriptors for 40,500 unique hidden services
* Received requests from clients for 25,600 unique descriptor id’s.

Even these basic stats point out a number of issues with the way hidden services currently function. 16.03 million or 92.5% of all descriptor requests my nodes received were for hidden services I did not currently have descriptors for. This could be a result of the clients having an out-of-date network consensus and not choosing the correct HSDir’s as responsible. It could also be a result of an out of sync time which causes the clients to look for the wrong/old descriptor id’s. Either way, a significant amount of time is being wasted on descriptor look-up which slows down the time when first accessing a hidden service.
Some More Stats..

The following table contains data on requests my nodes received for some well known Tor based marketplaces. There are also requests for related phishing sites. I have confirmed that some users were directed to these phishing pages from links on the “The Hidden Wiki” (.onion). The number of requests is what my nodes observed. Descriptor look-ups from clients will be divided at random between the 6 responsible HSDir’s and clients will keep trying the remaining HSDir’s until the descriptor is found or all HSDir’s have been checked. As a result the total number of requests received by the following sites per day may be up to 6 times more than the figures below, but these still offer a relative guide to popularity.
   

Onion Address Descriptor ID Requests
----------------------------------------------------------------
silkroadvb5piz3r cjzls3i2mbj4hjnquqmuvznihues4xh4 16387
silkroadvb5piz3r m6yz6gqrmu35twduuiixzr2mqtxdo3er 10891
5onwnspjvuk7cwvk 6t44eim223ypmb2ueokcsfco5vzvryfm 1413
silkroadvb5piz3r hadco5o7rmh2vcamg7mdzqklprqffyyh 558
silkroadxmx45vk4 6tyqo2bf7xclfbmrtrxwm7mgb3z4s5ui 197
atlantisrky4es5q hdj7wkuaigt7iicqf77gyzbo7zyvq7wf 165
atlantisrky4es5q m6y4s2utv4kxgdczv7t3gbmoloezblzf 161
atlantisrky4es5q 6r3z4tlr2vvl5z34v5lcuaqckgjvtr7s 129
silkroadxmx45vk4 m6eczdbpjse3jdfw54cv4nxcc6s34eku 107
sheep5u64fi457aw ci7dpz6emlh2pxpshovnxjbyjqnp3luo 59
silkrovafuce2ur2 6r6w7ncln5mo4hdwq6yh7f2hf3hlag2u 14
sheep5u64fi457aw rzq5pd4ehayz4yker7dhmvpubm4we7om 9
silkroadopn752dl cja5ppzzmkrzvr2pgp2c2z6mtuc7m7yk 4
silkroadr5cd6wbz m4n2afulpiln4n42l7wlg36wy6okkqrh 3
silkroadfqmteec4 cjcyh7mm6lzzuqka3vlq67upyt5zwd7b 2


It seems a lot of people, especially scammer’s running phishing sites on Tor hidden services don’t know a lot about web security which leads to sites like this.

Please users, if you enter your credentials on a phishing page, and it doesn’t log you into the site. Don’t try again!

I also observed a large number of requests to the command and control servers of the “Skynet” Tor based botnet which got attention after an AMA with the botnet owner on Reddit. Contact him @skynetbnet on Twitter for more info.


Onion Address Descriptor ID Requests
----------------------------------------------------------------
gpt2u5hhaqvmnwhr m5t2jamzi4fht3hicqadzd3rkl57lyjj 9792
x3wyzqg6cfbqrwht m5doen5pidde5wshaormqh6l2c4bljd5 7162
gpt2u5hhaqvmnwhr hdjeqyqaq344rbb6vxndliobueh3v2u5 6641
4bx2tfgsctov65ch 6twxygfbtb2haivmixjqx5ag35dg72tk 6485
owbm3sjqdnndmydf hd2j5xswo5ddvxpa2rahkg24vwhqo77y 6471
niazgxzlrbpevgvq m63z25bfydkc6nfko4b4kz44u3jsh67k 6334
6ceyqong6nxy7hwp m6czfa7ra6qvrfvbmg6zlsimi4braizy 2691
6tkpktox73usm5vq 6ruzifokbb6ez2qbnion7deylz4jjmq3 1827
uzvyltfdj37rhqfy 6tvqgoeu4piyu3x6dsyerhhhnko6iumy 1735
6m7m4bsdbzsflego m5zclz4icakymh2d6fbdkpq2t3n7efql 1681
6ceyqong6nxy7hwp hds46ckhghbg5gvfwnsgwvhvdildn2e5 1605
jr6t4gi4k2vpry5c m5zfpvht47zgiujyjkf5en2vu6g7ndzm 1579
xvauhzlpkirnzghg 6ugswkgt5pdmhlyzjgj5bhtnclophhwa 1556
jr6t4gi4k2vpry5c m5576obc535dffll4qwq6xh37u4dz7y2 1422
ceif2rmdoput3wjh 6s544wf5d6kuyhtiqq7wo37oisi6n5ce 1397
f2ylgv2jochpzm4c cjore7wxv2x46qrlcvmiyctm4szckpo3 1380
uy5t7cus7dptkchs 6ttlcxahq4obesp5gze4rkjjinivgoyl 1370
7wuwk3aybq5z73m7 6urq4w6to5fmjf3hyqitzlcscxszzbrd 1199
742yhnr32ntzhx3f t5z3anxrp3e5w5z2s5kqfftuxlw4v6ng 1178
7wuwk3aybq5z73m7 m4ejch7su2xm6zrzu5gn3cgrjsg43f6y 235
6m7m4bsdbzsflego 7lsph6grzr76j27fx4r7ir3ipbexidkt 134
6tkpktox73usm5vq hday5dik3mzlwkpvemrorfmirfdnepnp 102
6ceyqong6nxy7hwp lzgpbrgh6ims4fgru6ojdsea7hbruh6s 25
x3wyzqg6cfbqrwht ciq4shgjmutzgmz2t346rvkwtzuobfqe 24
owbm3sjqdnndmydf ciebkgj3gbl4egtwqvwssc6kvtt4x6t5 15
4bx2tfgsctov65ch 6rnq6z57hvjrf4a5yktfd7qavuvlvqjb 6


Many of the “Skynet” onion addresses above and other popular addresses are running Bitcoin mining proxies. They generally responded with a basic authentication request for “bitcoin-mining-proxy”. The other services may be Tor based bitcoin mining pools or part of Skynet and/or other botnets. It should be straight forward to find these sites by scanning the service id’s from the raw data on Github.
DoS Attacks on Tor Hidden Services

Tor hidden service desc_id‘s are calculated deterministically and if there is no ‘descriptor cookie’ set in the hidden service Tor config anyone can determine the desc id‘s for any hidden service at any point in time.This is a requirement for the current hidden service protocol as clients must calculate the current descriptor id to request hidden service descriptors from the HSDir’s. The descriptor ID’s are calculated as follows:

descriptor-id = H(permanent-id | H(time-period | descriptor-cookie | replica))

The replica is an integer, currently either 0 or 1 which will generate two separate descriptor ID’s, distributing the descriptor to two sets of 3 consecutive nodes in the DHT. The permanent-id is derived from the service public key. The hash function is SHA1.

time-period = (current-time + permanent-id-byte * 86400 / 256) / 86400

The time-period changes every 24 hours. The first byte of the permanent_id is added to make sure the hidden services do not all try to update their descriptors at the same time.

identity-digest = H(server-identity-key)

The identity-digest is the SHA1 hash of the public key generated from the secret_id_key file in Tor’s keys directory. Normally it should never change for a node as it is used for to determine the router’s long-term fingerprint, but the key is completely user controlled.

A HSDir is responsible if it is one of the three HSDir’s after the calculated desc id in a descending lists of all nodes in the Tor consensus with the HSDir flag, sorted by their identity digest.  The HS descriptor is published to two replica‘s (two set’s of 3 HSDir’s at different points of the router list) based on the two descriptor id’s generated as a result of the ’0′ or ’1′ replica value in the descriptor id hash calculation.

I have implemented a script calculating the descriptor ID’s for a particular hidden service at an arbitrary time and it is available on my Github account. I have also created a modified version of ‘Shallot‘ which can be used to generate keys with an identity key in a specified range. The is more usage information on its Github page.

The Attack

The code listed above could be used to generate identity keys and identity digests for an adversary’s HSDir nodes so that they’ll be selected as 6 of the HSDir’s for a targeted hidden service. These adversary controlled hidden service directories could simple return no data (404 Response) to a client requesting the targeted hidden service’s descriptor and in turn prevent them from finding introduction nodes. As there are no other sources for this hidden service descriptor it would be impossible for a user to set up a circuit a complete circuit to the hidden service and there would be a complete denial of service until the descriptor id changes.

For an adversary to continue this attack over a longer time-frame, they would need to set up their nodes for the upcoming desc id’s of the targeted hidden service more than 24 hours in advance to make sure they will have received the HSDir flag.

An adversary would need to run 12-18 nodes to keep up a complete, persistent DoS on the targeted hidden service. Six nodes would be the “responsible HSDir’s” and the other nodes would be running with identity digests in the range of the upcoming desc id’s, to gain the HSDir flags after 24 hours of up-time. An adversary can cut the resources needed by running two Tor instances/nodes per IPv4 IP or by running the Tor nodes on compromised servers on high, unprivileged ports.

These attacks a quite a real, practical threat against the availability of Tor hidden services. For whatever reason (extortion, censorship etc.) adversary can perform complete DoS attacks with minimal resources and there are no actions hidden service owner can do to mitigate, besides switching to descriptor cookie based authentication or multiple private address. The Tor project can try deal with these attacks by removing known malicious HSDir’s from the network consensus but I don’t see a straight forward way to identify these malicious nodes.

Unfortunately there are no easy solutions to this problem at the moment. I can foresee adversaries employing these attacks in the wild against popular hidden services.

Conclusions

Tor hidden services were originally implemented as some a simple feature on top of the Tor network and unfortunately they haven’t received the attention and love the deserve for such a popular feature. There are discussions under way to re-implement hidden services to alllow them to scale more efficiently. There are also people looking at reducing the ability of HSDir’s to sit and gather data on onion address and look-ups like I have done, by implementing a PIR protocol. A good summary of work that needs to be done is available in a blog post on the Tor Project’s website. I’d urge any developers with an interest to join the tor-dev mailing list and see if there is something  you can contribute! A lot of work is needed.

Anyone interested in learning more about the issues with the current Tor hidden service implementation please check out the presentation “Trawling for Tor Hidden Services: Detection, Measurement, Deanonymization” at the IEEE S&P conference this Monday by Alex Biryukov, Ivan Pustogarov and RalfPhilipp Weinmann will probably provide a much more in-depth, formal investigation and I too look forward to reading it. We have been researching similar areas so I’m very interested in their approach and results.

All raw data and my modified Tor clients are available from my Github repo. This also contains scripts for calculating hidden service descriptors and generating OR private keys with fingerprints in a particular range. This data includes all descriptor requests and hidden service ID’s my nodes observed. Please check it out if you are interested in analyzing a random subset of services on the Tor network.

I’d like to thank @mikesligo for having a heated debate in the pub with me about hidden services and getting me interested in how they work. I’d also like to thank @CiaranmaK for reading a draft of this post and pointing out some corrections.

Thank you for reading my first blog post. I’ll have to work on presenting things better as the information in this post is a bit all over the place. Please let me know if you have any questions or feedback in the comments below.

1285
Newbie discussion / Re: Newbie PGP Club
« on: May 21, 2013, 12:52 am »
try to get my head around PGP. i have a public key, but what do i use to decrypt a message? where do i paste it?
Ubuntu user

There's no GUI PGP program for Unity/Gnome ever since they got rid of the text encryption plugin for Gedit. You can either install Kgpg (and like a hundred dependencies along with it), or learn command line GPG.

If you're on 32 bit Linux, you can use GPG4USB (check the link in my signature), but it doesn't work on 64 bit Linux without, once again, installing a crap ton of dependencies, namely the ia32-libs.

1286
Qubes looks promising, especially the way you can have an isolated Tor process and configure the networking on a per-AppVM basis to use it (see my "any OS over Tor" guide that I just posted, it's basically the same thing), also the way you can create disposable VMs for opening untrusted files... but it also looks really complicated to use and not newb friendly.

I remember when you first mentioned it a few weeks ago, but sort of forgot about it after that. I'm about to try it out, though.

1287
It is a good tutorial, but I think the super simple way to do this these days is to use Whonix. They make preconfigured VirtualBox images so all you have to do is File -> Import Appliance for each image, then start the Gateway and Workstation. All the hardware parameters are configured for you, and Whonix isolates Tor from the main OS, so you can download the potentially malicious files over Tor directly to the Workstation and not worry about disabling networking or shared folders (which can be a security threat in themselves). Everything can be done relatively safely with a default Whonix configuration.

And if you want disposable VMs, it's simpler and easier to delete and reimport the Workstation after each use, then to go through a full distro installation. I can import the Workstation in like a minute, so I can destroy and create fresh VMs all day with little annoyance or work involved.

Alternatively, you could boot Tails in a VM, which is a truly disposable VM, because nothing is ever installed or saved to disk, and you get a fresh VM each time you boot it with zero work, but it's slightly less safe than Whonix, since Tor runs in the same VM as the potentially malicious files.


An even cooler thing is that you can use the Whonix Gateway with any OS, so you could install Lubuntu or any distro, like in pine's tutorial, but change the networking to work with the Whonix Gateway. Once you have everything configured with all the apps that you might need, you export it as an appliance, so you you can destroy and recreate that VM with minimal effort, and you get the safety of the Whonix Gateway with the comfort and convenience of your own distro (the Workstation is kind of crappy, tbh).


1288
Security / Re: Deleting Encrypted Documents
« on: May 20, 2013, 04:58 am »
Are you worried that when you "delete" the files with your file manager, they will be moved to the trash, where they won't be encrypted?

In Windows XP you can right click on the Trash can and choose to delete immediately, so I'm sure you can do it on other versions of Windows.

Then delete the files and turn the Trash feature back on if you want.

1289
Security / Re: Research links thread
« on: May 20, 2013, 04:48 am »
The Whonix Documentation has some of the most extensive information on crypto and anonymization that I've seen.

Everyone should read it, even if they don't use Whonix:  http://sourceforge.net/p/whonix/wiki/Documentation/

There's also the Tor Wiki:  https://trac.torproject.org/projects/tor

1290
Security / Re: GPG HELP: Can't add public keys?
« on: May 20, 2013, 04:41 am »
It's hard to help if we don't know which PGP program you're using, but I'm assuming that you're using GPGTools for Mac, because dozens of people have described this exact problem with that program.

If that's the case, take a look at this thread: http://dkn255hz262ypmii.onion/index.php?topic=144403.0

Pages: 1 ... 84 85 [86] 87 88 ... 208