This is a overview for system build by man whom needed to test some functionality on SDR (Software Defined Radio) and its potential to “snatch” data over-the-air (OTA) on strictly defined use-case scenario. That is separate stuff. This article concentrates on searching the origin. Yes it does.
NUMBER MACHINE CHARACTERISTICS and GENERIC USECASE
So man goes and builds a system for testing his environment WLAN crypto. Unluckily he uses only WEP (which we all know how easy it is to crack etc. yes.), but decides to give a shot anyway – it would be easier to allow such weak security model to shine on testing.
The system man builds has relatively narrow use case support and characteristics to complete its existence:
MAN inputs a string gobbledygook of information to system in which system must create something comprehensive clear-text out of it.
To achieve such objective, the system must have few capabilities among the input-TEST-output function. First, it must be able to run the operation very fast so man might need to think how to cluster, swarm or run things in parallel. Second, it must be user friendly and easy to access to be utilized everywhere in-lab man might need such capability. You never know! Third, it must able to support queuing if man needs more than one piece of information out in random order AND fourth it surely must be able to support some sort of semantic understanding for information what it just got to process.
SO – WHAT IS NUMBER MACHINE?
As its relatives (and big brother) in real world (equals outside of mans lab environment) – it runs calculations very fast by using capabilities found with some videocards (ATI in this case) running in parallel. These are called nodes. Each node has capabilities to run such calculations in parallel with other(s). Then there is a feeder software. It helps nodes to accomplish all the tasking.
The calculations are aimed to perform a brute-force crack, or more precisely search systematically all possible keys (or passwords). We are looking to turn the gobbledygook string to something meaningful. This is particularly difficult as these scrambled pieces of text are typically created through some cryptographic hash function. Now, this created hash-string has unique properties, such as fixed-length fingerprint that can not easily reversed.
Whilst this search is very, very painstaking and consumes huge amount of time – the system uses additional resources. These resources include Google (search for hashes), predefined tables (maybe someone has found corresponding hash already), entry, precomputed and reverse lookup table – to find proper match for inserted. As some of the languages (such as finnish) has such wonderful potential in passwords or WEP keys, it must have separate tool. That’s based on dictionary AND its very own table.
HOW IT WORKS (That’s different on how it performs BTW…)
The usecase(s) allows man to create such system that it:
- There is apparatus called “Feeder”. It has SMTP interface to receive work orders via standardized manner.
- SMTP interface is coupled with service picking script (handler) work orders from storage and inserting them to local MySQL database.
- Being user friendly, the interfacing with user allows few options (+mandatory details) to be set inside the SMTP message body.
- Options include: work order priority, status request and cancellation of work. Man is not sure what other options it could have yet.
- The brute-forced string(s) (hash) are inserted into SMTP mail body with other viable data, like potential hostname in freewill order. The hostname has prefix ‘hostname:’ and ip-address as well. Rest goes as ASCII blob in general information.
- Hash value must be either HEX or Base64.
- The queuing handler responsible for picking up the work order containing the message makes distinction between the hash-value(s) to be brute-forced and other information. This is working with some extend rather nicely.
- Then for each of the separate hash-values, own line is created on processing table (DB) with separate working ID.
- Watchdog is responsible to have correct set of work-orders running on brute-force. This is BTW not based on John.
- When there is anything to inform in state of computing, the watchdog collects that information and sends it back to user defined on SMTP body. Surely man may have different recipient address than the sender (nil) inside of some lab LAN that does not provide such capability.
- The watchdog is being called also if man wants to cancel or re-prioritize some work. Yes, man must remember his details by himself.
- The hash is searched on nodes.
- Second last, the second most interesting thing is how system breaks the work-orders between nodes. Easy. Both of the nodes are actually using same piece of storage through network. The queue held information is dropped back on storage for processing and the brute-forcing application is breaking the string itself. But there’s a catch. Remember the feeder, it does the stupid housekeeping work and shares disk.
- While this multinode parallelism allows great deal of raw computing power, it’s not enough. We need the separate, external tools as well.
- Why yes! Here comes script(s) – there is 4 of them – which runs the search for such hashes on predefined tables (discussed before) AND from external sources, such as Google.
example (SMTP handshake):
220 numbers SMTP Service ready at Wed, 6 Nov 2013 03:12 +0200
250 numbers Hello [172.16.1.123]
mail from: firstname.lastname@example.org
250 2.1.0 Sender OK
rcpt to: email@example.com
250 2.1.5 Recipient OK
354 Start input; end with <CRLF>.<CRLF>
host:banaglore hash:6D1F3708B48D1CC76028F39D1415012EA01DC754 “My server keyfile 1 row”
host:chinalake hash:BD38C263237EB3CE29D95A917B69E11AFA86E671 “Thats it” prio:1
250 2.6.0 <012-2013@numbers> [QueueId=0122013] Queued
- (x) Last thing: How it knows based on what algorithm it must search? It does not. It tests. And only few qualify. And sometimes it goes wrong.
- Running reverse lookup table on one node and other tasks in separate node is possible, whilst not command-able through rigorous SMTP interface.
- Why SMTP interface why not HTTP GET/POST – …well SMTP’s are handy? 🙂
- Sometimes it finds mans WEP key within minutes.
- No Rainbow tables. Yet.
- Suggested reading: https://crackstation.net/hashing-security.htm#attacks
- Potential idea (from above!): “Add” crackstation as part of my rig – maybe its called metatasking then?
TECHNICAL SCHEMATICS (piece of..)
As components man is utilizing with the system allows searching the (truth) from variety of sources + directly brute-forcing the hashes, it makes possible to do some interesting combinations. These include:
- Semantic search from variety of open source locations for specific context and target information. Such as e-mail address list being used as basis for selector
- Correlation of search output patterns and selectors, such as ‘this guy is with this guys e-mail distribution list and they are both in same LinkedIn group’.
- Among that – system is able to search pattern having guys e-mail address, phone number AND potential online car-sales auction with his car’s license plate information.
The point is: With little effort the examples shown could be combined and such gathering process could be used to provide information and clues for running extensive password or key search.