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 - kmfkewm

Pages: 1 ... 156 157 [158] 159 160 ... 249
2356
Off topic / Re: Top 10 Reasons Drugs Are Illegal
« on: August 13, 2012, 06:43 am »
1. Retards want jobs

They have no skills and the only job they can get is guarding people in prison cells, busting people with drugs via snitches, and regurgitating bullshit government propaganda. If they could not make money regurgitating propaganda, guarding people in cages or threatening to send people to prison for life if they don't give up information, they would starve to death. I blame the liberals for being so fixated on jobs that they think Slave Master is an acceptable position.

2. Christians want you to love Jebus

Jebus is the human-zombie-ghost hybrid form of the all mighty Sky Wizard who created you and drugs and decided to make you like the drugs that he created, but he totally hates it when you take the drugs that he created and forced you to take through his omnipotence, and he was nailed to a cross by a bunch of Jews to save you from your drug using sin but if you take drugs you might anger him and you don't like it when Jebus gets angry. I blame the Republicans for thinking they can force Jebus on the people through law.

3. Psychopaths want money and power

Politicians want power, alcohol and tobacco and pharmaceutical and rehab and construction and a billion other industries want to make money and the slave trade is a booming industry and infinite source of slaves! I blame psychopaths.

4. The majority of people are so fucking retarded that they should be sent to special needs facilities

They think if you smoke weed your dick will fall off

2357
Security / Re: Double VPN connection?
« on: August 13, 2012, 06:25 am »
yes

2358
Security / Re: How do you make a .onion website?
« on: August 11, 2012, 08:24 pm »
Problem with that old tutorial is it's using very buggy virtual machine software that hasn't been security audited for use in privacy critical hosting which is kind of insane. OS devs have been stamping out bugs in the x86 arch for decades and find new one's every day. Now you want to place a layer of extremely buggy mess code on top of that already terrible x86 arch and hope to god that it won't start page faulting or overflows. What if your attacker can get a shell and simply runs a tracert command or opens up lynx to find out the IP. No breaking out of the VM needed.

Running everything behind a firewall that uses Carp w/ Pfsense and using NAT to hand out internal IPs to your hardware separated web server and backend db through the DMZ seems to me like a lot more secure set up, though it will cost money (You can rent OpenBSD firewalls and other racks for dirt cheap per month). Now your OS is running on audited hardware, the webserver/db is behind NAT so attacker can't find out what they are, and the firewall is preventing all sorts of potential attacks both outgoing and incoming, and more importantly it's a separate piece of hardware with redundancy to prevent it crashing and an attacker from pinging out to get the IP.

Bonus is there's no VPS hosting company shady console access so you don't end up Linode-pwned since you're using all dedicated machines.

Article makes no mention of Resin http://pdos.csail.mit.edu/resin/ which MIT students taking network security graduate classes still use today. Every year since they came out with Resin, they choose 10 popular PHP forum software distributions and attack them all using known attacks, and a few of their own invented attacks and Resin so far has stopped them all. Without Resin the new attacks and even the old attacks with slight variations were able to fully exploit the application.

Article also makes no mention of CryptDB, a prototype MIT database that performs encrypted queries on encrypted data. The database entries are encrypted using the users password as a key. If they aren't logged in, and the box is seized then nobody can retrieve the information. All you need to do is add a few schema annotations to certain sensitive fields and can lock down an entire forum. Throw in Resin and nobody is exploiting shit unless of course, you're running a severely buggy virtual machine underneath it all that is a ticking overflow bomb.

Also is a very bad idea to use Abuse/Immunity Hosting Russian hosting for a Tor hidden service, since Tor there is a big democracy activist flag and they will take interest in shutting you down. It's typically at least 2-3x the regular price to use them, as they're primarily clearnet hosting for malware and spammers.  I would just use any host recommended by Torservers.net in Germany or NL that they currently use so you blend in with the other Tor traffic.

If you just want to start your own tiny drug site then get a German VPS from torservers.net list of hosts and lock it down using the info from torservers.net relay setup guide, but don't edit the Torrc file for a relay, make it a hidden service. Build Nginx from source and look up how to edit out all the version information and headers, and other info that gives away IP address like in error pages. Compile it, run, good 2 go for any minor site. Fill the database with pregen bitcoin addresses and use Django so it automatically escapes all SQL. Finally throw in some sort of IDS depending what OS you are using. Nobody will care enough to shut you down. If they find the site, so what just clone a new one and use your PGP key to sign a msg on the front page letting ppl know you haven't been compromised. Can set this up in under an hour. My $0.02

Does it suggest to use virtualbox or FreeBSD jails, I can't remember? Apparently virtualbox from your comments though. Jails are pretty well audited for security and I would not have any problem to use jails for security critical things, Theo be damned. Virtualbox seems like it is not a good idea to use in many circumstances, including most that require security, however it has worked in the past to save hidden services from feds deanonymizing them. Layers and layers of security and there is pretty much always someone who has a better technique than the next guy, and someone with more skill than him. I suggest that you write an article. CryptDB looks interesting, have not looked much into it but I have been doing some research of encrypted keyword search and private information retrieval and have seen it mentioned. Have never heard of Resin before. The Russian cyber crime hosts are pretty good at not taking anything down, even highly illegal shit like botnet CNC to CP hosting. I would lean towards having that extra layer of resistance, particularly since hidden services are so easily deanonymized (actually I would probably lean towards hosting in some non-sketchy place and using Tor through Tor).

The conclusion I have come to regarding virtualbox is that it is much easier to pwn a guest VB OS than an OS running on real hardware, but it still does require the attacker to break out of the VM to get to the host (or your IP address if you have it configured correctly). How are they going to find the IP address without breaking out? Opening Lynx will not do shit for them if it is using host only routing with Tor on the host. Also you can have ASLR on the host so they will have a hard time to overflow out of the VM to the host, and you can have mandatory access controls locking the VM user down on the host, adding further protection. At the end of the day I lean against using virtualbox these days though. However I think it is kind of insane to run a server that is automatically deanonymized as soon as it is hacked, some level of isolation is required and using virtual machines is the easiest way to obtain this. For a client though, the risks of having the VM rooted outweigh the benefits of adding an additional layer between the attacker and your real IP address, they will just spy on your plaintexts and steal your address when you make an order. FreeBSD jails though do not have the weaknesses of VB in this respect.

Your best bet would be to run Tor on a dedicated machine and then have a machine running the web server that routes all of its traffic through the Tor machine and is itself assigned only an internal IP address. That is pretty much the platinum standard for how hidden services should be configured (and how ultra l33t clients should be configured). Throw Tor on an otherwise 'out of the box' OpenBSD machine and it should be pretty fucking hard for someone who roots the web server (or firefox) machine to get its real IP address.




2359
Security / Re: a (possibly) better way to configure hidden services
« on: August 11, 2012, 09:33 am »
I believe it took a matter of seconds in some cases, but it was definitely in the range of minutes and not hours.

2360
Security / Re: a (possibly) better way to configure hidden services
« on: August 11, 2012, 07:53 am »
This would also be very beneficial for clients, because if the feds can not locate the hidden service to put it under surveillance, they can not complete an end to end timing correlation attack against clients, even if they watch the clients sending and receiving traffic.

some potential things to consider:

1. The latency of the hidden service will be roughly doubled as the circuit from the hidden service is doubled

2. There may be some anonymity problems with reusing nodes between the two instances of Tor, although I suspect this is less serious a concern for hidden services

3. There may be a fingerprint left in client entry return traffic as the response time after sending traffic will be uncharacteristically high, although cover traffic going down the same circuit should muddy this, and it really beats having a hidden service that can be traced in a day and then watched passively to complete 50% of an end to end timing correlation attack.

2361
Security / Re: a (possibly) better way to configure hidden services
« on: August 11, 2012, 07:41 am »
They will prob easily get it from your insecure application or web server before having to brute force down some guard nodes and find where you are. You would need significant resources to do that, but any idiot running Havij can SQL dump and get root login.

Right, some hidden services have been identified through insecure applications, but I have yet to find one documented case of a HS being deanonymized through an attack on the Tor network, in the last 2 years. If I did my experiment, I definitely wouldn't run PHP or MySQL. Just a static HTML page. I'd have to look into which web server is the most secure. Probably a light weight one with few features (that can be exploited).

I guess nobody who has the skills to trace hidden services wants to do it. I have been thinking of implementing the trace to entry guards attack, it would take me all of an hour to make a program that would be able to identify any normally configured hidden services entry guards in a few minutes at the most. Getting around entry guards would be more of a challenge for me, since I can not just order their ISP to monitor traffic to and from them. I would give it a shot with a sustained CPU DOS against its entry guards and hope that it selects one of my entry guards while I can maintain the DOS, but that is less sure. One thing though is that I lack any real motivation to do this, I don't particularly want to attack any hidden service and I support Tor. If I knew that I would get $10,000+ for deanonymizing a hidden service, and I didn't have any ideological objection to doing do, I would be a lot more motivated to actually go to the trouble (and spend the money required...at least a few servers particularly if I wanted to try a sustained DOS against several entry guards) to do it.

I absolutely love lurking the security threads and reading up on all of this stuff but most of it goes right over my head. I'm fairly tech savvy but don't have much network experience. Any tips on where to start reading to gain an understanding of how all this works and at least understand what everyone is talking about :)

The attack against hidden services is pretty straightforward. Hidden services open new circuits (three nodes, entry -> middle -> final) for every client connection request. The entry guard is from a small selection of nodes (generally three), but the middle and final node are selected from the entire pool of Tor nodes. An attacker who wants to trace a hidden service can add a relay node to the network and then (even from the same relay node...) use a specially modified client that sends tons of new connection requests to the hidden service and sends it a specially modulated stream of packets (watermarked, via deliberately created inter-packet timing characteristics). After doing this it immediately tears down the circuit, rinses and repeats. Now it only needs to wait until it detects this watermarked stream passing through it as a relay, and then it can observe the node it forwards this data onto. Since it sent the stream, it knows that it is a relay on the path to the hidden service, it can also select to use another node under its control as a rendezvous node so it can identify the hidden services final node and know if it is it, and by viewing where the watermarked traffic came from it can determine if it is the middle or entry guard for the hidden service. If it is the middle node it identifies the hidden services entry guard (one of the three anyway), if it is the entry guard it identifies the hidden service.

After identifying the servers three entry guards (which takes all of a couple of seconds to minutes), there are a few things the attacker can do. Powerful attackers (passive / external) like the feds (assuming they are not complete fucking retards, which is asking for a pretty big assumption on your part, but humor me) would probably do one of two things: if any of the entry guards are located in the USA they can do warrantless trap and traces of the entry guard to determine the IP addresses of the servers it communicates with and when, and then they could do an end point timing correlation attack to deanonymize the hidden service. If all of the entry guards are outside of the USA they could use a mutual legal assistance treaty to accomplish the same thing, although they may be delayed by some period of time ranging from hours to maybe even months, depending on the location of the entry guards. However there is a tremendous chance that any given hidden service has at least one entry guard in either the USA or Germany, and normally entry guards rotate every month to two months so even if they are out of luck this month next month they will probably be in luck.

Less powerful attackers (active / internal), like me, would be forced to try and get the hidden service to use one of our entry guards (since we can not do passive/external surveillance on the entry guards as easily as the feds can). The number one way to accomplish this is likely via a CPU exhaustion DOS. If the hidden services three entry guards can not manage its circuits, it will select new ones that can. If an attacker can do a sustained CPU exhaustion attack against all selected entry guards until one of its entry guards is selected, it can deanonymize the hidden service with an end to end timing attack after its entry guard is utilized. One way around this attack would be to select to use strict guard nodes in Torrc, then if the hidden services entry guards are DOSed the hidden service becomes unreachable, but at least it can not be forced into selecting new entry guards until it is deanonymized.

The solution in OP works like this. There are two instances of Tor running on the hidden service server. One (HST) manages the hidden services circuits, the other (CT) is a normal instance of Tor running as a regular non-hidden service client. In the Torrc of HST, it is configured to use CT as a socks proxy. This results in a circuit that looks like this

Hidden Server <-> CT entry <-> CT middle <-> CT Exit <-> HST Entry <-> HST middle <-> HST Final <-> Clients Final

Now the malicious client can still force the hidden service to open an arbitrary number of HST circuits, and can do the previously mentioned attack to trace up to HST entry. However, if the weak active attack does sustained DOS against all selected HST entry nodes until they own one of them, they are only in a position to identify CT exit instead of the hidden server. Likewise, if the feds use a trap and trace or MLAT to passively spy on HST Entry, they are only in a position to identify CT exit, not the hidden server. Normal Tor clients that do not serve hidden services will not open a new circuit per request, rather they rotate circuits approximately once every ten minutes. Thus, the force the hidden service to open a billion new circuits to send watermarked traffic down them attack becomes infeasible to carry out, and the hidden service remains as anonymous as a regular Tor client. This is probably adequate to protect from non-retarded-fed level attackers (if such a mythical beast actually exists).

2362
Security / Re: a (possibly) better way to configure hidden services
« on: August 11, 2012, 04:53 am »
They will prob easily get it from your insecure application or web server before having to brute force down some guard nodes and find where you are. You would need significant resources to do that, but any idiot running Havij can SQL dump and get root login.

Right, some hidden services have been identified through insecure applications, but I have yet to find one documented case of a HS being deanonymized through an attack on the Tor network, in the last 2 years. If I did my experiment, I definitely wouldn't run PHP or MySQL. Just a static HTML page. I'd have to look into which web server is the most secure. Probably a light weight one with few features (that can be exploited).

I guess nobody who has the skills to trace hidden services wants to do it. I have been thinking of implementing the trace to entry guards attack, it would take me all of an hour to make a program that would be able to identify any normally configured hidden services entry guards in a few minutes at the most. Getting around entry guards would be more of a challenge for me, since I can not just order their ISP to monitor traffic to and from them. I would give it a shot with a sustained CPU DOS against its entry guards and hope that it selects one of my entry guards while I can maintain the DOS, but that is less sure. One thing though is that I lack any real motivation to do this, I don't particularly want to attack any hidden service and I support Tor. If I knew that I would get $10,000+ for deanonymizing a hidden service, and I didn't have any ideological objection to doing do, I would be a lot more motivated to actually go to the trouble (and spend the money required...at least a few servers particularly if I wanted to try a sustained DOS against several entry guards) to do it.

2363
Security / Re: a (possibly) better way to configure hidden services
« on: August 11, 2012, 04:47 am »
Everybody keeps saying that hidden services can be easily deanonymized, yet I've never seen anyone actually do it with a modern version of Tor. Yes, I know there was a paper from SIX years ago that did it, but supposedly those holes have been plugged. I'm thinking of setting up an HS and offering a BTC reward to the first person who can tell me the IP address. I just need to do it in a way that keeps me anonymous, and I haven't figured that part out yet.

They 'plugged' the hole by introducing entry guards, now instead of being able to trace the hidden service in 60 seconds you can trace three nodes that are directly connected to it in 60 seconds. That solves the issue if the attacker is able to add two nodes to the Tor network, but doesn't do shit to protect from attackers who can simultaneously DDOS selected entry guards until they own one of the targets, or even easier simply send a court order to one of the identified entry guards or its infrastructure. If the guard is in USA they don't even need a warrant to do a trap and trace on it and then they can identify the hidden service from that. At the very best a normally configured hidden service is as anonymous as its least secure entry guard is from being hacked, at worst it is as anonymous as someone tracing to its entry guards in a minute and then using a trap and trace on one of them.

2364
Security / Re: a magic trick
« on: August 10, 2012, 10:00 pm »
yes at 100GB it would be unrealistic, but if every entry is only 100kb it would be only 10 gigabytes, and as the bits set to one are random each server would only need to XOR 5 gigabytes of data per request with a database of 100,000 items. If entries are limited to 10kb, each server would need to XOR about 500 megabytes per request with a database of 100,000 items.

2365
Security / Re: a magic trick
« on: August 10, 2012, 09:08 pm »
This would get unrealistic pretty quick as the item count goes up. You aren't going to XOR a hundred thousand items per database request.

The idea can be applied to any finite set, its just basic property of parity. Alice could request a set of 16 items including the one she cares about from Party A, and the same 16 without the one she cares about from Party B. Obviously this suffers the same problem as you have above, if you both requests you know which item was being requested.

That would not give the same privacy benefits, if Alice gets 16 items from a database of a hundred thousand items, once from each of two servers, both of the servers know that there is a 50% chance that she wants one of the 16 items they sent her, and then they know that there is a 1/32 chance that she wants any one of the 16 items they sent her. After only a few requests an individual server could quickly determine which sort of items Alice is interested in. With this, they have absolutely no idea which of the items she wants, unless they get together and share her request strings with each other. She could want any one of the hundred thousand items in the database.

Also the way you say it can be done, would require each of the servers to send Alice 16 megabytes of data per request, if the database items are 1 mb each. The way I described in the OP they would each only need to send her 1mb item, so it scales a lot better and has much better privacy guarantees.

disclaimer: I did not invent this 

2366
Security / Re: a magic trick
« on: August 10, 2012, 09:05 pm »
This would get unrealistic pretty quick as the item count goes up. You aren't going to XOR a hundred thousand items per database request.

The idea can be applied to any finite set, its just basic property of parity. Alice could request a set of 16 items including the one she cares about from Party A, and the same 16 without the one she cares about from Party B. Obviously this suffers the same problem as you have above, if you both requests you know which item was being requested.

why not? I have run this as code and it had no problem with a database holding a hundred thousand items.

2367
Security / Re: a (possibly) better way to configure hidden services
« on: August 10, 2012, 09:01 pm »
Jondonym is a fine VPN and you will not likely find much better, they cooperate immediately with court orders but prior to a court order requesting logs to a specific site or from a specific user they do not log anything. Also the court orders need to be carried out against individual nodes, which are in different jurisdictions. Of course such a small network is much easier for a passive attacker to pwn though.

You can make Tor circuits up to 8 nodes there are network limits that prevent you from extending past that though, although there is little point in using additional nodes. The goal of the scheme I show in the OP is not to add additional nodes but rather to gain the anonymity benefits of Tor running as a non hidden service client for Tor hidden services.

Actually come to think of it, I believe Tor automatically rotates entry guards if it detects that your IP address has changed, so as long as they are not using strict entry guards in their Torrc Tor would take care of the details of changing entry guards when the the servers location changes for them.

2368
Security / Re: a (possibly) better way to configure hidden services
« on: August 10, 2012, 07:27 pm »
Quote
I think the next step in the evolution of anonymity is a cloud-based network of anonymous, donated VPSs that anybody can set up (think a VirtualBox appliance spread around via torrent) and each one runs a small fragment of the overall operation with massive redundancy across the board.  Latency goes up, not to mention all the other technical challenges, but this seems like a wise medium-term goal.

that sounds somewhat like freenet

2369
Security / Re: a (possibly) better way to configure hidden services
« on: August 10, 2012, 07:26 pm »
Two instances of Tor.

Tor one is hidden service, Tor two is normal client. Tor one Torrc uses Tor one as socks proxy. Now circuits look like this:

Hidden Service <-> T2 entry <-> T2 middle <-> T2 exit <-> T1 entry <-> T1 middle <-> T1 final <-> Clients final <-> etc

now when client adds some nodes to Tor and forces the hidden service to open an arbitrary number of circuits, they will trace to T1 entry in a matter of seconds very easily. If they do active DOS attacks against the set of nodes that make up the possible selections for T1 entry they may be able to own T1 entry. Of course the feds can simply subpoena one of the nodes that is T1 entry and get the information for the node behind it, which if you use a normal hidden service configuration will be the hidden server itself. But now they merely obtain T2 exit, and furthermore they can not continue to do the force the hidden service to open a billion circuits to traceback attack because T2 is a normal Tor client circuit. Configure T1 and T2 Torrc appropriately to make sure there is not node reuse (or family reuse?) between the instances of Tor.

Latency is doubled, but it should probably prevent the feds from being able to trace hidden services. Right now they either can, or the only thing stopping them is their own stupidity. Will add donation link to my signature sometime ;).

That's a very interesting idea and probably needs to be tested.  Perhaps if you set a test site up and draft Shannon to try and find it.  ;)

I have tested it and it works fine, although there is higher latency. I have not done an in depth analysis of the anonymity properties, but the only problem I can imagine would be if T1 and T2 re-use nodes between them. Even that wouldn't be horrible for a hidden service, considering the entry guard can already trivially determine if it is an entry guard for any given hidden service. You might not even need to protect from node reuse for hidden services, although if you were a normal client it would be important to do so because you would definitely not want to reuse the same node for entry and exit in that case. I would bet five hundred bucks that configuring a hidden service to use two instances of Tor in this way would extremely increase the anonymity provided. As it stands today, tracing hidden services is trivial. You can trace to each of a hidden services entry guards in under a minute, and then it is just a matter of either forcing it to change to new entry guards until it picks one of yours, or if you are a stronger attacker simply sending a court order to one of the entry guards or its infrastructure. A hidden service with an entry guard in USA could realistically be deanonymized in a couple of hours if the feds had a fucking clue.


Quote
IMHO, LE can probably trace any hidden service if they make a single, coordinated effort. Making it harder will only delay the inevitable if enough resources are dedicated to the process. It has to nearly impossible (and not just difficult) or there has to be another layer of protection beyond the hidden service.

If LE actually had a clue they wouldn't even need to spend much effort to trace hidden services. If I had the powers of even a low ranking federal agent I could certainly deanonymize any 'out of the box' configured hidden service. It is simple.

Quote
My guess is that SR is always changing servers, all of which are remotely managed through tor, public wifi, etc and only for a short period of time. As long as they can quickly deploy the SR clone in 1-2 steps and make all subsequent configuration changes offline before uploading them, they won't have to be exposed to the server for long.

Hopefully they actually know what they are doing if they always change servers, it would be a waste of time to change the location of the server without rotating all of its entry guards. But the time frame they will have to switch the server to a new location is very small, hidden services can be traced very quickly by moderately powerful attackers (and FBI has legal powers that put it well within this range, even if their technical people are dumb shits)

Quote
I don't know how feasible it is to seamlessly rotate servers hosting a hidden service; If it's possible and doesn't introduce too much downtime, then they are either doing this already or should look into it.

It can be done with no downtime at all very easily.

Quote
k i think arma needs to hire your ass for the good of mankind

actually i can't imagine your resume going over well

name: *bangs on keyboard*
cv: admined drug boards
references: bunch of nyms
etc :P

I doubt that they want anything to do with anyone who has such a resume :P.


2370
Security / Re: How do you make a .onion website?
« on: August 10, 2012, 06:57 am »
Actually Tor hasn't been called TOR for a long time, Shannon is completely right here.

He can be a little combative, but he knows his shit.
Fuck that. I'll write it however the fuck I like. If it's an abbreviation, it gets capitalized. Like USA, DEA, THC, whatever. Geez. If you're gonna make a point out of that, fuck you sincerely.

It isn't an abbreviation.

Pages: 1 ... 156 157 [158] 159 160 ... 249