Paid Advertising is
ha.ckers sla.cking
Who's got it? Who's giving it away? How to protect your privacy and steal it from other people. For intellectual privacy, personal privacy, and blackhats alike... 
Go to Topic: PreviousNext
Go to: Forum ListMessage ListNew TopicSearchLog In
Pages: Previous12
Current Page: 2 of 2
Re: Tor, IP privacy?
Posted by: jungsonn
Date: November 08, 2006 06:35PM

myeah.. but there are some sick people who are dedicated to them wiki's, and are looking at new post just as much as we look at traffic logs.

I am curious though if someone can pull it off.

Options: ReplyQuote
Re: Tor, IP privacy?
Posted by: rsnake
Date: November 16, 2006 03:07PM

I don't really see a way for them to stop you effectively anyway. Especially if you are using an onion network or a series of anonymous proxies or hacked machines, etc... etc...

- RSnake
Gotta love it.

Options: ReplyQuote
Re: Tor, IP privacy?
Posted by: maluc
Date: November 16, 2006 04:26PM

Well the idea is that it uses steganography, which is the process of hiding something in plain sight. It's not wise to put up a page that says
ID's 0-1500, Command, Fornicate,
ID's 1501-50000, Command, DoS,

Obviously that looks suspicious, as does gibberish encoding. Steganography will hide those same commands within:

Special processing is performed if fewer than 24 bits are available
at the end of the data being encoded. A full encoding quantum is
always completed at the end of a body. When fewer than 24 input bits
are available in an input group, zero bits are added (on the right)
to form an integral number of 6-bit groups. Padding at the end of
the data is performed using the "=" character. Since all base64
input is an integral number of octets, only the following cases can
arise: (1) the final quantum of encoding input is an integral
multiple of 24 bits; here, the final unit of encoded output will be
an integral multiple of 4 characters with no "=" padding, (2) the
final quantum of encoding input is exactly 8 bits; here, the final
unit of encoded output will be two characters followed by two "="
padding characters, or (3) the final quantum of encoding input is
exactly 16 bits; here, the final unit of encoded output will be three
characters followed by one "=" padding character.

(Copied from the MIME RFC2045). Editors have no way of knowing. the only potential trouble is if someone decides to edit the article with new information - thus the reason for an obscure fictitious topic. However, site admins may notice a peak in traffic for that wiki page(s) if the botnet is large enough.

Other than that, it should be very difficult to spot. And ofcourse, always have a backup C&C, or atleast a way to re-herd them..


Options: ReplyQuote
Re: Tor, IP privacy?
Posted by: rsnake
Date: November 16, 2006 05:10PM

Have you ever heard of SNOW? Stenographic nature of whitespace. It's one of the coolest stenographic techniques I've ever seen. It hides data in the whitespace at the end of lines (tabs and spaces).

- RSnake
Gotta love it.

Options: ReplyQuote
Re: Tor, IP privacy?
Date: November 16, 2006 05:20PM

There's no need to hide it too well: all you need is to permalink to the revision, even if an editor reverts it, the information is still there. Wikipedia already has this problem with people posting personal information on the wiki: removing old revisions is extremely difficult to do, and if they think it's regular vandalism, it probably won't get hard-deleted.

However, I invoke [[WP:BEANS]] and will say no more.

Options: ReplyQuote
Re: Tor, IP privacy?
Posted by: rsnake
Date: November 16, 2006 06:46PM

Ah, you mean because of the revision history. But that's not particularly sufficient command and control because it IS so hard to change. Whatever it is, it needs to be something you can modify regularly.

- RSnake
Gotta love it.

Options: ReplyQuote
Re: Tor, IP privacy?
Posted by: maluc
Date: November 16, 2006 07:24PM

Well i just like it for it's uniqueness really _-_

But ya, it's not particularly suited for any botnet that needs to be updated more often that once every other day.. for something like a distributed md5 cracker though, i think it should be suitable enough.

The whitespace encoding is one of the main methods i've read of when i was last researching into it. The nice thing is that it's very easy to encode random info into a page. The word based ones can be a pain in the bum to make a sensible paragraph around it :/

Not to mention that wiki hosts images.. but constantly changing the image will stand out even more


Options: ReplyQuote
Re: Tor, IP privacy?
Posted by: banshee
Date: July 07, 2007 01:24AM

Hmmm. How about a CAPTCHA-like system? I truly can't see non-bot users causing a problem, though WP has banned Tor because of humans, not bots. Also, WP bans Tor nodes regardless of whether or not the IPs have been abusive. Personally, I find this policy shit, but w/e.

Options: ReplyQuote
Re: Tor, IP privacy?
Posted by: humble
Date: July 30, 2007 09:23AM

Wikipedia have permanent bans on most Tor IPs. If you're on a static IP and running Tor, it's probably a fast way to get your IP blacklisted indefinitely.

Options: ReplyQuote
Re: Tor, IP privacy?
Posted by: FiSh
Date: August 13, 2007 12:34PM

Is it possible that the node in question has been modified to save the information? There's some nasty stuff you can do with a Tor end node..

Options: ReplyQuote
Re: Tor, IP privacy?
Posted by: tx
Date: August 13, 2007 01:40PM

I wouldn't be surprised, HD Moore already came up with a method of tracking the people coming through an exit node. I would assume that since he's inserting content he has the ability to save the information as well.

-tx @

Edited 1 time(s). Last edit at 08/14/2007 01:43AM by tx.

Options: ReplyQuote
Re: Tor, IP privacy?
Posted by: Anonymous User
Date: August 14, 2007 07:05AM

Yes you can save all info if you own the exit node, however through a ssl line it can't. There is some paper circling the net which describes how to track users and log all their info. Beware, because it is illgal and violates the Tor rules, if you get caught they will try to prosecute.

Options: ReplyQuote
Re: Tor, IP privacy?
Posted by: istari
Date: September 06, 2007 06:04PM

@ the wiki botnet

I really don't think this could work out in a long term: each time you modify or create a page in wikipedia, a log entry is created, backups are saved and reviewers are emailed so that they can see what has been done, and remove it or change it back if it's wrong or breaks a rule. This means that any page that gets changed frequently will definately get noticed, especially if only an image or a few letters change each time (they have a rule against making small, futile changes that waste reviewer time)...

So, all in all, I guess that you could probably pull it off for a few days or so, but the botnet will ultimately get noticed and blocked if you try to use this channel a lot (which is kind of the idea, isn't it?)...

Options: ReplyQuote
Re: Tor, IP privacy?
Posted by: comperr
Date: September 07, 2007 01:21PM

Um capthcas are unless now a days.

while its true that they ban you - if you block wikipeda from exiting they will unban you

Options: ReplyQuote
Re: Tor, IP privacy?
Posted by: Linus
Date: January 10, 2008 02:54PM

I realise I'm replying to an old topic here, but it's still on the first page, so I will reply and make conversation. ^^

rsnake Wrote:
> See... I'm glad I asked because I didn't get the
> answer I was expecting. I thought you were going
> to say it's a single choke point. For every one
> entry point there could be zero to many display
> points for that same data. In the case of many
> you have to solve each issue one at a time, rather
> than solving it once at the input box. The only
> downside to that is you had better make sure you
> do all the output validation you will ever need.
> Quotes might seem okay if it's just on a page with
> nothing else, but it might not be okay in a URL
> parameter. :)
> The SQL Injection point is a good one though.

I noticed you and maluc talking about this and had to clearify something:
Handling an SQL Injection is *clearly* output filtering in most systems.
Output filtering is applied when the data you are working with is leaving the current processing system and being fed into a new one through a protocol of some kind.
In this case, you are taking whatever input you get from the user and sending it from your PHP script through (example) mysql_query($a.filter().$b) to a different process (SQL-server).

This line is fine however, I'll try to explain the difference in two examples:
consider a function a(b,c) which recursively parses an array b by executing a function with name c on all elements in this array, returning a new array with the parsed data and same key set.
$_GET = a($_GET, "mysql_real_escape_string");

This is input filtering. You are filtering ALL input with the same method, regardless of how it will be used in the PHP script.
Even if you are going to use $_GET['id'] to select an element from an existing array, it will still have been parsed through mysql_real_escape_string.

As for output filtering:
mysql_query("SELECT a,b,c FROM t WHERE d=".mysql_real_escape_string($_GET['d']));

This is output filtering. A filter is applied *as the content is used for a specific task*.

Jungsonn wrote:
>@ sql injection:
>most of the time i shove up everything htmlentities converted into a db.

This is however, *both* input filtering and output filtering.
You are input filtering the content that will later (presumably) be output to the user, and output filtering the SQL query.

As for me, I prefer output filtering. Why?

$where = array('unsafe_content' => $unsafe_content);
$db->dbSelect('table', $where);
$db->dbInsert('table', $more_unsafe_content);

Because well written database interfaces will secure data on their own. :)

The same goes for output to HTML of any format. A well-written ML-parser that content is fed through before output should easily be able to blacklist or whitelist whatever content it has to.

At first glance, input filtering may look like a good plan, with the 'catch-all'-plan for filtering. However, by parsing everything, rather than only what is necessary, you may introduce problems elsewhere and thereby making your system overly complex.
If you want a field somewhere which takes raw input, you'd need to ditch filtering for that field in a specific instance, if you want a specific blacklist for certain forums, you'll run into different problems.

Output parsing may look like the more advanced option, when it comes to staying in control and maintaining security; but a robust framework turns this into a non-issue.
Templating systems, among other things, work towards centralized output, which in turn gives you the security you get from input filtering, but with the granularity to avoid the problems you get when filtering all input:
$templateSystem->setWhiteList(array('b', 'i', 'u'));


Options: ReplyQuote
Re: Tor, IP privacy?
Posted by: rsnake
Date: January 10, 2008 08:09PM

I don't think most people would understand or agree with that being output filtering, Linus. I can see what you're saying, but unfortunately I think your way of talking about it is confusing at best. Sure, it's outputting it to a database, but that's still the internals of the system. When most people talk about output filtering they literally mean what is shown to the consumer. In this case what you are referring to would be input filtering and most definitely not output filtering.

More importantly your description doesn't even make sense if you are talking about it from the database's perspective. Clearly it's the input that is being filtered (prior to reaching the database) not the output (which is leaving the database). Make sense?

- RSnake
Gotta love it.

Options: ReplyQuote
Re: Tor, IP privacy?
Posted by: Linus
Date: January 11, 2008 11:12AM

By the same logic, looking at it from the visitors point of view, any output filtering in PHP would be input filtering for the visitor. (Something which would be a more fitting term for NoScript, which as far as I understand it filters the incoming HTML.)

I did a quick lookup over google on what input filtering pertains to for external verification. These were the relevant features:
1. Input once, but output many times.
2. No processing required on output.
3. Direct output from database is possible.

Now, take this query:
mysql_query('INSERT INTO v (html) VALUES ('.mysql_real_escape_string($_GET['html']).')');

The insertion statement is, according to your logic, input filtering. Yet it breaks all three statements. The mysql_real_escape_string statement will have to be reapplied. Both when recieved from the database and on a potential second query which also requires the $_GET['html'] data as input.

For comparison, input filtering prepares data for a potential action before it's used for that action:
$_GET['html'] = mysql_real_escape_string($_GET['html']);
mysql_query('INSERT INTO v (html) VALUES ('.$_GET['html'].')');

The data in $_GET['html'] has been one-point secured for all further use and output into SQL queries.

This does not say anything about the future security of the data recieved from the database. A database is, after all, not a secure source.


That said, I read up on both input and output filtering, and realized I had somewhat of a misconception on what output filtering indeed was.

Thus I withdraw my statements. =p
(Though, I have to say, this was an interesting eye-opener and topic! =) )


Options: ReplyQuote
Pages: Previous12
Current Page: 2 of 2

Sorry, only registered users may post in this forum.