Jump to content

endeavormac

Active Members
  • Posts

    6
  • Joined

  • Last visited

Posts posted by endeavormac

  1. I'm just arguing for the sake of brainstorming here/carrying on a conversation. nothing meant to be taken personally/offensively/flamishly

    The counter to most of these is that, as I said in the paper, I wouldn't use a single account for either hosting the commands or posting them. I would post from randomly created accounts to randomly chosen accounts and then use the search feature to find the posts. Having the posts in the public timeline removes the ability for Twitter to either block a host account (because there isn't one) or the searchers (as they would be doing a generic public timeline search).

    When I said block IP, I meant the IPs of the specific bots, not the IPs posting messages. In your explanation, you have the bots eventually looking up the user by his username. By having the bots look up by username, you give twitter a way to identify with great accuracy the bots. If they can find one of your botnet controlling accounts, they can just go ahead and block IPs that use(|d) the API to look up those accounts, and then contact the relevant ISPs (blocking the bots, not the controller (well in addition to the controller)). Perhaps twitter would be viable as one of several command mechanisms, but you can't have it as the single control mechanism in your botnet.

    <edit>I see later you respond to this</edit>

    My counter argument to this working is that once Twitter works out the method the bot uses to spot the message it can then start doing regexp checking for those messages itself, a counter to that is to create a control language that was generic enough that the filter Twitter would have to put in place could also block legitimate traffic.

    As I think of this, here is what I would propose. Again, I'm not 100% sure of the twitter API, I've only played around with it somewhat, but if you can search the public timeline for certain words, here's what I would do:

    1) I would pick several popular words searched on twitter. For this example, we'll say the three most searched words are ["dog", "cat", "tiger"]

    2) Have your twitter bot search the public twitter timeline for these words on a pseduo-random time schedule. For example, at 2400, 0600, 1200 and 1800 GMT, but have a one hour lee way after the time, and randomize whether or not you're going to pull commands. So, out of the day, you may randomly only pull commands at two of the times.

    3) Include the word dog, cat or tiger somewhere randomly in your command. "ping dog <hostname>", "dog ping <hostname>", "ping <hostname> dog" would all be valid.

    4) Go through all the entries you pull down from twitter, up to the past hour, strip out the word you used, and check to see if the result is a valid command, IE "ping <hostname>"

    - This makes your bots harder to distinguish from regular users. You are shifting some of the locating of the individual commands to the bot machines, instead of through the twitter API.

    - This assumes they won't change the twitter API, but I give in to you on this one later in this post.

    - It also makes your botnet fairly easy to hijack. You may want some way of signing your messages.

    Here's an interesting idea. Hash the original command PLUS a salt known to you and bots. Take the first 8 chars of the hex digest, giving you 2^32 combinations. Use this, plus the salt again, as a key to encrypt each individual word, then base64 encode it. Throw your word in there ["dog", "cat", "tiger"], and your 8 hash chars (not the salt).

    Now look for your word ["dog", "cat", "tiger"], and then search for all 8 char words 0-9a-f (chances are there will be only one, but just in case). Unbase64 encode each word and try this 8 char hash plus salt to decrypt it. Take the 8 char hash out of the result, and hash the result with your salt. If the first 8 characters equal the 8 characters of the hash you found, you should be good.

    Now obfuscate your salt as well as you can in code. Until twitter can deduce your salt and this crazy algorithm, I have no idea how they would write a filter to block this crap. It will appear as a jumble of letters split up into words. If you had just a symmetric key, ping would appear the same everytime, but because of the 8 hex chars, you have 2^32 different possibilities for ping. You also A) keep others from seeing commands sent, and B) bots are assured you are the one issuing commands.

    Once the salt/key and algorithm are deduced it's game over. Just make things crazy.

    Sorry this post is so long. So I don't think I did a good job of explaining the code above, so I went ahead and implemented it in python. Here's a link: http://myw3b.net/~endeavormac/files/hak5twitterbot.tar

    I didn't feel it necessary to add the words (dog|cat|tiger) in, because this part is trivial. This handles everything else.

    Here's the output:

    &gt;&gt;&gt;
    encoding
    enter some text &gt; ping yahoo.com
    enter a salt    &gt; hellohak5
    47dd1f40 xiALPQ 0siKpTfGDrhG
    &gt;&gt;&gt; 
    encoding
    enter some text &gt; ping hak5.org
    enter a salt    &gt; hellohak5
    E6T5NQ 383f81c3 6JUtf3nTZf8
    &gt;&gt;&gt; 
    decoding
    enter the text &gt; E6T5NQ 383f81c3 6JUtf3nTZf8
    enter the salt &gt; hellohak5
    plaintext found: ping hak5.org
    &gt;&gt;&gt; 
    decoding
    enter the text &gt; 47dd1f40 xiALPQ 0siKpTfGDrhG
    enter the salt &gt; hellohak5
    plaintext found: ping yahoo.com
    &gt;&gt;&gt;

    They do but it takes them some time to work out that the bot is there, reverse engineer the bot, work out the fix, test it and roll it out. If you built the bot well you could have a rotating command structure where you could easily send down a new command language which, if you got in before the Twitter filters, would make them useless.

    I like this

    They can't change the API, it would kill too many apps that are already out there, the public outcry when their favourite Twitter client died would be too much.

    I guess this was just a scenario for if your botnet was large and hard to lock down. They couldn't change the API over night, but they could announce a change. Say, in 30 days our API will be changing. However, if your bot could modify itself to adjust for the new API changes (like you mentioned above), then this would indeed be impractical, regardless of botnet size, so I'm going to have to concede API changes as trivial to you.

    I think this method would be probably best employed as a backup channel in the same way confiker has p2p built in. If it is obfuscated enough in the bot then people won't really know what it does until it has been used to regain control and after that it can be burnt and a new backup put in place.

    Ok, I like this too

  2. <edit>

    After reading your http://www.digininja.org/twitterbot/ I like mubix's ideas.

    I guess the idea would be to make what you are looking for in the public timeline so close to what other people are writing that twitter will be apprehensive to write a filter for it, as they would deny too many regular tweets.

    </edit>

    I'm just going to weigh in here, and say no, I would not use twitter.

    The reason I would not use twitter is because you do not have very much control over the API or how twitter works. There is also a single point of failure here: twitter.

    If you have a relatively small botnet, then ok, maybe you will not run into problems.

    If your botnet became a problem/noticed, ways I would shut it down, were I twitter:

    Identify the offending twitter account.

    Identify IPs which were doing lookups on that account's feed.

    Contact the ISPs of those accounts. Hopefully, one of those IPs would belong to a company with a dedicated/informed IT department, whom I could A) inform and B) ask for a copy of the offending trojan.

    Take the trojan, and discover how it selects twitter accounts.

    Deny those twitter accounts.

    Block the offending IPs.

    Twitter being what it is, I'm sure they already have an incident model/plan for these things already in place.

    Worse case scenario, twitter could just change the way the API works. Imagine how easy something such as conficker would be to shut down if it was based off of something that the botnet creators had such little control over such as twitter.

    Here is what I think would be your best bet.

    Pick an algorithm which will create a predictable string based off of time. Say, each day it hashes the current unix timestamp / (60 * 60 * 24) to give you the number at the beginning of the day. Take the first characters of this hash, and now you have something that will change predictably.

    Now pick some free hosting sites, and some free dns services (.tk domains ring a bell). Have your bot request a page at *random_string*.*free_dns* or free_hosting_site.com/*random_string*

    You have created A) multiple points of failure. If one site begins blocking your bots, you can still use another. B) You are now in more control the protocols your botnet is using. Twitter API changing, it could happen. HTTP and DNS? No (sorry kaminsky).

    Make sure to scramble up your strings, and keep your bot dependent on as few external factors as possbile.

    </done weighing in>

    how was that?

  3. You don't need to modify the code.

    Let's say you have 16 rainbow tables numbered 1 through 16. Put 1 through 4 in a batch file, 5-8 in a batch file, etc, for each core you have on your processor. Now run all the batch files simultaneously, and your kernel will automatically schedule the processes among the different cores.

    Remember though that they will all be pulling the rainbow tables off the same disk. If you spend 100 seconds pulling information off the disk and 100 seconds in cryptanalysis, maybe distributing this task across your cores isn't going to be a good idea. If you spend 10 seconds pulling information off the disk and 100 seconds in cryptanalysis (IE make longer chains), then yeah, give it a shot.

    Hope this helps answer your question.

×
×
  • Create New...