Quick hypothetical: Rather than wasting computing resources on running BitCoin mining (which attempts to hash numbers such that they will be below a certain other number) why not attempt to find exploits in popular browsers, Java, or Flash?
Bitcoin mining (according to this article: https://sanchom.wordpress.com/2011/05/24/bitcoin-mining-first-you-get-the-power-then-you-get-the-money/ which is old, so prices are probably down as computational complexity has increased over the last year) nets around $100 a month. We're talking about tons of computational power on a GPU that runs all day.
A good Java/Firefox/Chrome/IE exploit, when turned in to the proper authorities merits closer to $1337 per exploit, or if you have a particularly good one (like a Java6/7 0day, sold to the proper government it could be worth up to $100,000)
If you have a site, a hidden iFrame/Java Applet/Flash Plugin is all you need. If you set up two communication channels, websockets we'll say, and feed the user something to the hidden frame/applet, if the applet crashes, that websocket channel dies. If it also kills the browser, both die; if nothing happens, everyone goes about their merry way. When the site is closed, you'll need to emit a clean close on the channels so you don't get false results.
Slap this on a gaming website, a company homepage (if you're a corporation looking to use spare cycles), or somewhere else it won't be noticed, and you may have something much more lucrative than Bitcoin mining (or better for the community, if you see it that way.)
Thursday, August 30, 2012
Sunday, August 19, 2012
SQL Exploits Everywhere
Bruce Schneier says that if you are going to be a successful defender of technology, you need to look from the attacker's point of view.
In this case, I wanted to detail how a small system I found on my campus, could attack a much larger one, potentially proving to be disastrous.
There is a small, unsecured, system that is used by an office at my university to check out technological items to professors that need them. While in the office that developed this application, I saw that one of the employees was having trouble entering a "comment" for a checkout, it turned out, the comment was evidently being put in to a SQL statement un-escaped. The server that does this is web-facing.
I also happen to know that the developers for the campus' programs are (excuse me when I say this, if any of you ever read this) incredibly poor programmers. They can never decide who owns a bug. Each is locked in to their own specialty and can't see things from another perspective, and little testing is done before products are released (because I've experienced large bugs in the stable versions). No two developers have overlapping knowledge of any one product (if one leaves, and the software goes haywire, it stays that way, even if it is totally unusable, until the key developer comes back).
There are even flaws that allow you to view content that shouldn't be available to you, by incrementing numbers in address bars, or editing content through boolean values in cookies...there are bound to be hundreds of overlooked flaws in the software the university pumps out, as developers tire of the old and switch to the new, only re-visiting the old when they decide to write from scratch again.
I also know, that some systems developed take up to 24 hours for users to sync from one DB to another...meaning users and passwords (as hashes are unlikely in such large systems of software varying in age from nearly twenty-ish years old to now to be implemented, and if they are, they are likely nothing more than md5sums) We even use MSCHAP for network authentication (which was broken a long time ago, and is trivially easy to do now with even the smallest of CPUs on the market)
This leads to the conclusion, that user integrity could be easily compromised through one application. All you need is one break, and the user-names and passwords could be flowing...SSNs, DOBs, bank accounts, relative's names, email addresses, all part of a standard University's collection of data.
In this case, I wanted to detail how a small system I found on my campus, could attack a much larger one, potentially proving to be disastrous.
There is a small, unsecured, system that is used by an office at my university to check out technological items to professors that need them. While in the office that developed this application, I saw that one of the employees was having trouble entering a "comment" for a checkout, it turned out, the comment was evidently being put in to a SQL statement un-escaped. The server that does this is web-facing.
I also happen to know that the developers for the campus' programs are (excuse me when I say this, if any of you ever read this) incredibly poor programmers. They can never decide who owns a bug. Each is locked in to their own specialty and can't see things from another perspective, and little testing is done before products are released (because I've experienced large bugs in the stable versions). No two developers have overlapping knowledge of any one product (if one leaves, and the software goes haywire, it stays that way, even if it is totally unusable, until the key developer comes back).
There are even flaws that allow you to view content that shouldn't be available to you, by incrementing numbers in address bars, or editing content through boolean values in cookies...there are bound to be hundreds of overlooked flaws in the software the university pumps out, as developers tire of the old and switch to the new, only re-visiting the old when they decide to write from scratch again.
I also know, that some systems developed take up to 24 hours for users to sync from one DB to another...meaning users and passwords (as hashes are unlikely in such large systems of software varying in age from nearly twenty-ish years old to now to be implemented, and if they are, they are likely nothing more than md5sums) We even use MSCHAP for network authentication (which was broken a long time ago, and is trivially easy to do now with even the smallest of CPUs on the market)
This leads to the conclusion, that user integrity could be easily compromised through one application. All you need is one break, and the user-names and passwords could be flowing...SSNs, DOBs, bank accounts, relative's names, email addresses, all part of a standard University's collection of data.
The GUI
I have made it quite evident to those that listen that I hate GUI development...but that is hardly the full case. In truth, I hate GUIs. UI in general sucks; even in the real world.
Why do you have to press a button to eject a CD? To turn on a fan? Why do you "drag" icons to the "trash can"?
The initial screen you get upon turning it on (which is instant by the way...no slow "loading" or such) Shows the date, day of week, time, copyright (Microsoft by the way) a 4 x 5 grid that shows the names of your files (you could only have twenty, minus the five default installed programs: fifteen files!) and number of free bytes.
Navigation is simple, arrow keys, and you move a black box that inverts the colors: instant visual contrast.
Like most BASIC programs, you interact with them by entering commands; which feels much more native to me than clicking buttons or moving a mouse. It is a nice chat you have with a machine, and if you remove all of the extra words that you would from when you talk with a person, you pretty much end up already knowing all of the commands for a program.
When you enter a program, it is full screen, much like a new file on your desk would be: you pay attention to only that. (something Android and IOS [or *sigh* Palm, you too] seem to have gotten right...only after twenty years of bumbling around)
Things are generally simple and make sense in the world of the Tandy.
Sitting there is a slew of information (and yes, my desktop is cluttered). At the top, I have seven programs telling me that they are running perfectly fine! At the top left of the screen, I have the name of the current program, which is confusing, because it a) hides the menu bar, and b) tells me I'm running "Ubuntu Desktop" when I'm clearly not (oh, wait! you mean the thing that opens other programs is a program running on another program displaying itself through another program that is using programs to talk to my computer?) To the left are a bunch of icons some of which depict what they do...like the terminal and folder, but otherwise depict nothing of the sort: what does a fox hugging a globe have to do with the web? In the bottom left I have a trash can/recycle bin that doesn't actually erase things on my disk when I "delete" them.
I can nest hundreds of folders within folders and one file at the end...or none; and it helps a little, trying to find what I want...but not as much as it could.
Each file should have two states: archived/not archived, archived files can be seen are heavily compressed, to save space, and aren't in the FTS database. This will allow you to save projects, and move on.
Search should be able to look up many attributes of files, creation time, author, type, program created by, etc.
Applications should be able to store information in some kind of key -> value store (like a registry, and for those of you that argue, registries = good, if keys are named properly, and things aren't nested crazily) that is dependent upon the context, that way you could use the same email client for work and home contexts without it needing the back-end of being able to fetch from both and keep them separated.
Contexts, and the documents within, should be able to be encrypted and hidden, but the user should still be able to see the documents from one that isn't encrypted or hidden (unless it is unlocked at the moment) in their normal FTS search.
Entire contexts should be transferable (enterprises should love this, new employee gets emailed a context, and it includes all employee info, etc.)
Contexts should be built around messages, being that is what we do in the real world; talk to one another. You get a message, take an action, and move on. These should be able to be cataloged (instant time-sheets).
Files should be heavily overwritten when deleted, and be removed from the FTS database as well, to ensure nothing remains of them.
There should be no root to run things under, except the user. Everything should be user dependent.
Applications should be suspended when not in use by the user for security, privacy, and resource usage purposes.
All files an application creates should be saved in a directory somewhere, allowing a full cleanup when an application is removed from the device.
Why do you have to press a button to eject a CD? To turn on a fan? Why do you "drag" icons to the "trash can"?
The Way Things Used To Be
One of the best GUIs that I've run across recently is from a very old machine...the Tandy 102 (of which I scored two on Ebay for a reasonable price, being their working status was unknown)The initial screen you get upon turning it on (which is instant by the way...no slow "loading" or such) Shows the date, day of week, time, copyright (Microsoft by the way) a 4 x 5 grid that shows the names of your files (you could only have twenty, minus the five default installed programs: fifteen files!) and number of free bytes.
Navigation is simple, arrow keys, and you move a black box that inverts the colors: instant visual contrast.
Like most BASIC programs, you interact with them by entering commands; which feels much more native to me than clicking buttons or moving a mouse. It is a nice chat you have with a machine, and if you remove all of the extra words that you would from when you talk with a person, you pretty much end up already knowing all of the commands for a program.
When you enter a program, it is full screen, much like a new file on your desk would be: you pay attention to only that. (something Android and IOS [or *sigh* Palm, you too] seem to have gotten right...only after twenty years of bumbling around)
Things are generally simple and make sense in the world of the Tandy.
The Way Things Are
Fast-forward twenty years and you get this:
Sitting there is a slew of information (and yes, my desktop is cluttered). At the top, I have seven programs telling me that they are running perfectly fine! At the top left of the screen, I have the name of the current program, which is confusing, because it a) hides the menu bar, and b) tells me I'm running "Ubuntu Desktop" when I'm clearly not (oh, wait! you mean the thing that opens other programs is a program running on another program displaying itself through another program that is using programs to talk to my computer?) To the left are a bunch of icons some of which depict what they do...like the terminal and folder, but otherwise depict nothing of the sort: what does a fox hugging a globe have to do with the web? In the bottom left I have a trash can/recycle bin that doesn't actually erase things on my disk when I "delete" them.
I can nest hundreds of folders within folders and one file at the end...or none; and it helps a little, trying to find what I want...but not as much as it could.
The Way I Want
Enough complaining: now on to how I see to fix it.Hide the file system, except for people that want to use it.
Use a full-text-search solution that runs *once* whenever a file is updated to update it's database; and also index meta-data/file-type/etc. for faceted search.Each file should have two states: archived/not archived, archived files can be seen are heavily compressed, to save space, and aren't in the FTS database. This will allow you to save projects, and move on.
Search should be able to look up many attributes of files, creation time, author, type, program created by, etc.
Contexts
There should be an easy way to group files in to "projects" and have those show as your main view (or desktop) rather than having Desktop be an arbitrary folder. That way you can switch between contexts easily.Applications should be able to store information in some kind of key -> value store (like a registry, and for those of you that argue, registries = good, if keys are named properly, and things aren't nested crazily) that is dependent upon the context, that way you could use the same email client for work and home contexts without it needing the back-end of being able to fetch from both and keep them separated.
Contexts, and the documents within, should be able to be encrypted and hidden, but the user should still be able to see the documents from one that isn't encrypted or hidden (unless it is unlocked at the moment) in their normal FTS search.
Entire contexts should be transferable (enterprises should love this, new employee gets emailed a context, and it includes all employee info, etc.)
Contexts should be built around messages, being that is what we do in the real world; talk to one another. You get a message, take an action, and move on. These should be able to be cataloged (instant time-sheets).
Security
Programs should be sand-boxed, if necessary. Users should be able to decide which system functions an app can use with good granularity, and the app shouldn't be able to figure it out. (i.e. a list of permissions with checkboxes).Files should be heavily overwritten when deleted, and be removed from the FTS database as well, to ensure nothing remains of them.
There should be no root to run things under, except the user. Everything should be user dependent.
Applications should be suspended when not in use by the user for security, privacy, and resource usage purposes.
All files an application creates should be saved in a directory somewhere, allowing a full cleanup when an application is removed from the device.
Subscribe to:
Posts (Atom)