Jump to content

endeavormac

Active Members
  • Posts

    6
  • Joined

  • Last visited

Everything posted by endeavormac

  1. They did not announce the winners in the last episode. When/where are they going to do this?
  2. I'm just arguing for the sake of brainstorming here/carrying on a conversation. nothing meant to be taken personally/offensively/flamishly 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> 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; I like this 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. Ok, I like this too
  3. Try grabbing a copy of psexec and using the -i switch to have the commands you run interact with the currently active desktop.
  4. <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?
  5. 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...