Cracks and Hacks

...A private matter is something one doesn't want the whole world to know, but a secret matter is something one doesn't want anybody to know. Privacy is the power to selectively reveal oneself to the world.    If two parties have some sort of dealings, then each has a memory of their interaction.  Each party can speak about their own memory of this; how could anyone prevent it?  One could pass laws against it, but the freedom of speech, even more than privacy, is fundamental to an open society; we seek not to restrict any speech at all. ... - Hughes

International contract negotation tips

"As an experienced contractor who mainly deals with overseas clients, all I have to say is that if you go into this sort of work without fully understanding the risks them you should give it all up and go do something else. Some basic rules.

1) Agree a payment plan. Stage payments for specific milestones.

2) Use an accountant who knows what they are doing with international business

3) Suggest using an escrow account. Client pays all the money up front. Then agrees to release parts as deliveries are made. Also agree a timeout clause so that if they don't agree the final payment you get it automatically after 6 months. Russuans are very bad at agreeing the final payment.

4) Use a Lawyer who knows about international contract law.

5) Both parties to agree that the laws of ONE country shall apply to the contract. UNLESS it is with former parts of the USSR that are not in the EU. Then agree Swiss Law.

6) Every change no matter how small must be agreed in writing and signed off with agreed costs. Do not do anything as a freebie. This habit is endemic in many countries especially in Moscow.

7) Make sure that the person on the other side is actually authorized to sign the contract. I've had clients try to wriggle out of payment saying 'He was not authorised to sign the contract so we can't pay you'

8) If you are going to sign away the title of the stuff you develop then make the transfer of title a separate contract. Agree in the original contract that title will change hands only when the job has been completed AND full payment made.

9) Learn the language especially the swear words. A few curses in their language can work wonders when a client is being awkward."

WANT A SIMPLE WAY TO KEEP YOUR CLOUDY BIG DATA PRIVATE AT LITTLE COST?

An interesting spin on an old technique brought to Hadoop

http://eprint.iacr.org/2012/398.pdf

"...Retrieval of previously outsourced data in a privacy-preserving manner is an important requirement in the face of an untrusted cloud provider. PIRMAP is the rst practical PIR mechanism suited to real-world cloud computing.  In the case, where a cloud user wishes to privately retrieve large les from the untrusted cloud, PIRMAP is communication ecient. Designed for prominent MapReduce clouds, it leverages their parallelism and aggregation phases for maximum performance. Our analysis shows that PIRMAP is an order of magnitude more ecient than trivial PIR and introduces acceptable overhead over non-privacy-preserving data retrieval. Additionally, we have shown that our scheme can scale to cloud stores of up to 1 TB on Amazon's Elastic MapReduce service..."

Random thought for an exploding honey token

I remember when Nuxi and I would create computationally compact compressed files and see which mail servers would attempt to inspect the contents.  Typically, the MTA would fail over due to lacking heap space, heavy swapping, insanely large disk IO, and other resource utilization problems.  Besides, during the school year, exploding the mail gateways was a great way to cause the university’s mail server to go down and buy a few day’s extra time.  So why not cause the same reckless behavior, but cause a large blip to happen when an inside actor attempts to inspect a honey token? 

Name the compressed file CreditCard_Customers.zip , <insert juicy file name>.zip, etc…. Then place it somewhere available for the intended audience.  Or somewhere not available.  For instance, put it in the confidential file share.  Then watch asset’s system logs for resource utilization errors related to unpacking a 35 PB zip file.  Or see if someone attempts to email it to their personal email address (assuming the MTA will cough and die when inspection occurs.)  You did make your MTA rugged, right?

Here are two test files.  Modify to your liking. 

Lazy AWS devops

I am seeing too much echo chamber, saber rattling, foolish dogma about agile SA / devops. “Just use <insert configuration tool name here.>  All of your problems will be solved.” Yeah, right. And Unicorns talk to virgins. DevOps setup isn’t simple. One will need to think about a different paradigm. As a result, one’s mindset will change.  For better and worse, one will slowly morph into the Bastard Operator from Hell.

Scenario time: a tornado takes out your data center. Or if you were at Google last year, aliens land and take over the United States. You are at the symphony. Don’t worry! Good thing you have an AWS EC2 account ready to bring up Production DR and IT-based BC.

All accomplished without a touch of the keyboard or service.  Back to wrapping your arm around your date @ the symphony.  

If you want to read more about each layer, continue reading… If not, go outside and enjoy a beer.

The first layer is bootstrapping. Traditional practice, one would file a ticket with the DC techs to rack the new machine. The DC techs would rack, cable, and power on the asset. The machine would PXE boot to grab the image to the system via ftp and / or tftp. Such a pain. This procedure would take 2-3 hours for each machine. One could get 20-30 machines up in parallel. Maybe much less if one could get the systems pre-imaged from the hardware vendor. Too much time and effort wasted. With newer SA methods, boot strapping can be accomplished in less than 5 minutes. Pick one’s infrastructure as a service. Scalr, GoGrid, AWS EC2, Rackspace Cloud, OpenQRM, and Engine Yard come to mind. Grab ruby’s fog gem or the vendor’s toolkit. If you are feeling sassy, utilize a build system such as Jenkins, or Buildbot. Grab your api keys from your IaaS vendor. Place the credentials in the toolkit. Then put the automation script in the build system or run it from command line. The script below would utilize Fog for EC2 to bootstrap a pre-configured, low powered, logical machine.

#!/usr/bin/ruby

require 'rubygems'

require 'fog'

require './secrets.rb'

cloud = Fog::AWS::EC2.new(:aws_access_key_id=>@aws_access_key_id,:aws_secret_access_key=>@aws_secret_access_key )

server = cloud.servers.create(:image_id => 'ami-323', :flavor_id => 'm1.small')

puts "Private IP: #{server.private_ip_address}"

puts "Public IP: #{server.ip_address}"

Nifty, now you have a machine running. But you have to take it your methods to the next level and configure it to the tasked assigned to you. You can login to the machine, manually configure packages, settings, and test the system for assurance and compliance. If you are lucky, you would have written script automation to handle this for you. Most likely, you haven’t nor would you periodically run those scripts the machine. Over time, everything will not look the same. As the number of systems increase, it becomes harder to manage. Utilizing configuration tools such as Chef, Puppet, CFEngine, or BCFG2, one can ask the machines “AM I like the standard image?” When they do not, and they will, the tool will alert and automatically correct the issue. It is a manageable problem. Completely hands-off. Now I wouldn’t go so far to say this tool automation solves your needs. You will have Three Mile Island cascading failures.  

Congrats, one has their application running on their logical asset. But wait, Product needs to reconfigure the application service to fix a bug. Many will blindly apply the change across all systems in a rolling fashion. Orchestration by blind faith is great, but will fall short. Capistrano, Mcollective, ControlTier, or IronFan are great tools to use in this effect. Not everyone can acquire Yahoo’s Limo. Orchestrate the organization’s processes and procedures into a frankenstein tool. For instance, when I bring a new Cassandra node online, I use the following code:

announce(:cassandra, :server, :compliance)

neighbors = discover_all(:cassandra, :server, :compliance).map(&:private_ip)

nodes = <%= neighbors.join(',') %>

Configure monitoring to know the good state and health of the service(s.) Then have monitoring integrated with orchestration and boot strapping to provision / deprovision instances until the entire data center is running at an optimal level. Monit, Munin, and Nagios come to mind.

An amazing benefit from utilizing the modern methods above is that one’s infrastructure heals itself and doesn’t depend on a single failure. 

DevOps interview questions

directory '/etc/elasticsearch' do

        recursive :true

        owner   'elasticsearch'

        group   'root'

        mode    755

end

directory '/var/log/elasticsearch' do

        recursive :true

        owner   'elasticsearch'

        group   'root'

        mode    755

end

Can you spot the 5 fundamental flaws in the above config for Elastic Search?

1.  The directory / files are hardcoded.  You want to avoid this at all costs.  Otherwise, what is the point of your agile and maintainable software-defined-infrastructure?

2.  Setting the owner to elasticsearch is a security hole.  It has a daemon-writeable configuration directory.  Ensure your software follows the principle behind least privileges.

3.  Setting group to root fails on bsd.

4.  Owner / Group are not DRY. 

5.  Filesystem permissions are incorrect.

Google Glass Developer program - DOS and XSS

There were two very simple Google Glass Mirror's quickstart DOS and XSS vulnerabilities.  The fixes have been introduced in changeset https://github.com/googleglass/mirror-quickstart-java/commit/738352eb5b5b73aa7bb911d0aeee3386f40dbf26

The DOS fix is rather simple.  Limit the request to 1000 lines.  The XSS fix is hackish but works.  Instead of reflecting the client's input back to the user, the error is directed to the error logging infrastructure.  Let's hope the error logging infrastructure is anti-XSS enabled.   

Enterprise Risk Management competition

For those who believe in competition and free markets, I propose an evolutionary risk algorithm competition.  

Rule set:

  • Patentable
  • Equal or better than a publication in a recognized journal
  • Recorded results are better or generally accepted by risk analyst professionals. The results reduce risk which is complex and hard.
  • Publishable upon generation
  • Better than human-created results, for long term challenges, and the traditional solution. Wins vs. humans or algorithms create by humans.

Bug Age - Pattern series

I love standards. My blackhat persona says this makes it easy to break into systems (mono-risk culture.) Everyone must buy the same machine, same software, same configuration. My whitehat persona says this leads to less configuration flaws. Then opponents must move further up the stack and delve into about code insecurity. One would think we would be prepared / situated when attackers are forced to move onto code insecurity. Mind you, this is a 2-5 years evolution. But 2-5 years is a lot of time preparing for code insecurity. The challenge is how does one build secure code cost-effectively? I am amazed at all the clever ways one can break poorly written php / java / perl / javascript / actionscript/ C / ruby / python code. Software insecurity is a well understood challenge. I have never met a software developer who wanted to create insecure code. It is not a soft problem is the sense programmers write insecure code. But there exist tools (behavioral, developmental, and thought) to reduce / eliminate classes of vulnerabilities. Lost long ago were formal proofs. These computing systems formal designed stuff at a higher level, assigned appropriate interfaces and with some mathematical confidence show a permutation of interfaces couldn’t be utilized by a hacker in the right order to enact unexpected behavior. Formal proofs have disappeared. Ultimately, that is the next problem to solve. The Age of Bugs is dead. Academia and other hackers have moved into the Age of Systems. Eventually software developers will move beyond common software vulnerabilities and utilize mechanisms that eliminate them.  Until then, software developers have a number of patterns to recognize and formally solve. 

In the coming entries, we will cover the following patterns in detail;

Code correctness – incentives to get code right, not secure.
Old code is scary – threat models change after years of use
Holistic security – All encompassing
Open source lesson – many hands in the kitchen
Never ending security – the never ending story
Today’s XSS is tomorrow’s CSRF
Retire unused code – poor financial investment
Tools are tools – nothing more, nothing less

Lazyness - automation

Prehistoric code metric

When I think of application security metrics, I think of an immature field where there are no actuarial data sets. As a result, I see some interesting numbers come out on number of vulnerabilities per thousand lines of code, code agitation, insecure programming languages, etc…  Rarely are they even close to being statistically sound (lacking standard deviation, error rates, false assumptions, etc…) As a result, when I attempt to triage which area of the code base to focus on, there is the one tried and true method: code age.

This process is built upon the following assumptions;

  • Old code is likely to have more security vulnerabilities than newer code. This is due to increased application security vulnerability awareness training, secure libraries, and other engineering improvement processes.
  • Threats evolve. Functionality that never expected automation is now easily automated. Do a diff between OWASP Top 10 2010 / 2007 / 2004. Proof is in that diff pudding. Third party library dependencies had their threat models and vulnerabilities change, as a result, your code is now at greater risk. Attackers have gotten smarter, better tool sets, additional resources. Think of the analogy as code ferments. Its' security posture doesn't get better with age.

First, identify all applicable source code files / binaries. Proactively prevent new security vulnerabilities from being introduced in the source code / binaries. Then rank files / binaries by age where age is when the source was originally created. Then perform static analysis on the old code. Then begin the security push phase of the SDLC – hands-on review for security vulnerabilities. This phase forces engineering to look for vulnerabilities in old code.

Evolutionary hardware

For technical problems, one may struggle to define the specifications. When this happens, look at the behavioral design. Then one may find solutions from the design automation. Thankfully, evolution algorithms are a class of “soft computing” techniques which handles poor specifications. One will encounter direct application of the evolutionary algorithms via Neural networks, ReCaptcha, and / or Amazon Turk.  All which have been applied to solve noisy pattern recognition.

Evolvable hardware techniques have important advantages over neural networks. Hardware is really fast and are more easily understood / implemented than neural networks with fast operations and solution tractability. For these purposes, evolvable hardware has been developed for academic, military and industrial applications. So let’s borrow from them instead of reinventing the wheel.

With appropriate automation, evolvable hardware has a large potential to autonomously adapt to the constantly changing risk environment. This is extremely useful for situations where (real-time approaches nano-seconds) over systems is improbable / impossible. It doesn’t hurt evolvable hardware is useful when harsh or unexpected data points, threats, vulnerabilities, risks, and other conditions are encountered.

How to sell a story - Ira Glass

"...What nobody tells people who are beginners — and I really wish someone had told this to me . . . is that all of us who do creative work, we get into it because we have good taste. For example, you want to make TV because you LOVE TV. There is stuff that you just LOVE.

So you have really good taste. But you get into this thing where there is this gap. For the first couple years you are making stuff… but what you’re making isn’t so good. It’s not that great. It’s trying to be good, it has ambition to be good, but it’s not. But your taste, the thing that got you into the game, your taste is still killer. And your taste is good enough that you can tell that what you’re making is a disappointment to you. It’s still sorta crappy.

A lot of people never get past this phase. They quit. But the thing I would say to you with all my heart: most everyone I know who does interesting, creative work, went through years of this. We knew our work didn’t have this special thing that we wanted it to have. Everybody goes through this.

If you are just starting this phase, still in this phase, getting out of this phase, you gotta know it’s totally normal and the most important, possible thing you can do is do a lot of work. Do a huge volume of work. Put yourself on a deadline so that every week or every month you know you will finish one story. You create the deadline. It’s best if you have someone waiting for the work, even if it’s somebody that doesn’t pay you. It is only by going through a volume of work that you will close that gap, and your work will be as good as your ambitions.

In my case, I took longer to figure out how to do this than anybody I’ve ever met. It takes awhile. It’s going to take you awhile. It’s normal to take awhile. And you just have to fight your way through that...."

http://vimeo.com/24715531

Evolutionary risk modeling design thoughts

Defining the black-box system allows three key considerations which allows one to differentiate between evolutionary and conventional risk modeling designs.

Design consideration # 1: A tractable inverse model. If there is a tractable “inverse model” of the black-box system, then there is a way of deducing in advance a sequence of variations which bring about a desired set of objective values and risk acceptance modality. “Conventional” methods may be applied. Evolution’s blind generate-and-test nature is not needed, although evolutionary algorithms are quite competitive.

Design consideration #2: The inverse model is not tractable, but the forward model is: While one may predict the influence of variations upon the objective values / risk acceptance but the black-box system is not tractably invertible, one cannot derive and deduce in advance a sequence of variations to bring about a desired set of objective values. This implies an iterative approach, where variations are carefully selected according to the forward model and are applied in sequence. Interative design-and-test is a common component of traditional approaches. Search techniques, including evolutionary algorithms, can be competitive or the only choice.

Design consideration #3: Neither inverse or forward models are tractable. There is neither a way of discerning which variations will give improvements in the objective values, nor a way of predicting what will be the effects of variations on the objective values. By a hesitantly settled definition, evolutionary risk processes are those which proceed by incrementally applying variations which are essentially blind. Selection can lead to an improvement in objective values with neither a forward nor an inverse model. Whether evolutionary methods actually succeed in finding a satisfactory design is another issue, but these are the only way to go in general. Thus, there is an entire class of risks which can only be tackled by evolutionary methods.

Hilarious Ubuntu defect

https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1055766

Dear "root owning" overlords, When using grep recursively I only get local results: grep -R fish_t /home/noob/fish_game/* /home/noob/fish_game/fish.h: struct fish_t { /home/noob/fish_game/fish.c: struct fish_t eric_the_ fish; or worse: grep -R shark_t /home/noob/fish_game/* /home/noob/fish_game/fish.h: struct shark_t { /home/noob/fish_game/fish.c: struct shark_t_t mark_sw; I declare this a bug for two reasons: 1. The output is boring. 2. The terminal has more than 2 lines!!! It's an unefficient use of my screenspace. I believe the reason for this is that the grep command only searches locally for things I am actually looking for, I kind of expect the results I get from my codebase and as such it removes any sense of mystery or something new and exciting to spice up my dull geek existence. That's boring, grep -R should also search amazon, so I get more exciting results such as: Shark Season 1 Starring Steven Eckholdt, Nora Dunn, Patrick Fabian, et al. Amazon Instant Video to buy episodes: $1.99 to buy season: $34.99 ($1.59 per episode) Watch instantly on your PC, Mac, compatible TV or device. 2. Product Details See Color & Size Options NHL San Jose Sharks Primary Logo T-Shirt Men's by Reebok $16.95 - $19.99 new from $16.95 (1) Eligible for FREE Super Saver Shipping. 3. Product Details See Size Options Shark Week Girls T-Shirt by Hot Topic $22.50 See all 9,755 results "struct shark_t" (See all 1,583 results) 1. Product Details See Size Options D:fi D:struct Pliable Molding Creme by D:Fi $23.50 $17.05 ($11.37/100 g) new from $10.50 Only 7 left in stock - order soon. (35) Eligible for FREE Super Saver Shipping. 2. Product Details Take 'N' Play Anywhere Activities Activity Tin - Robo-struct by Patch Products $11.99 $8.77  new from $3.99 Order in the next 1 hour and get it by Tuesday, Sep 25. Only 12 left in stock - order soon. (1) Eligible for FREE Super Saver Shipping. Manufacturer recommended age: 4 - 9 Years 3. Product Details d:fi d:struct 2.65 oz by AMERICAN CREW This is less dull and also maximises the use of my terminal and hence increases my productivity. Please can you change the grep warez to have this feature, and just install it on my machine while I'm down the pub, after all you do "erm, have root", so it should be easy for you to do :-)

Security quotes

"Two can keep a secret if one is dead."

-- Unknown

"How you can tell an extrovert from an introvert at NSA ? In the elevators? The extroverts look at the OTHER guy's shoes."

-- Steven Aftergood, e-mail to Cryptography mailing list, 6/11/02.

" There's no reason to treat software any differently from other products. Today Firestone can produce a tire with a single systemic flaw and they're liable, but Microsoft can produce an operating system with multiple systemic flaws discovered per week and not be liable. This makes no sense, and it's the primary reason security is so bad today. "

-- Bruce Schneier, Cryptogram, 16/04/2002.

"The present need for security products far exceeds the number of individuals capable of designing secure systems. Consequently, indust ry has resorted to employing folks and purchasing "solutions" from vendors that shouldn't be let near a project involving securing a system."

-- Lucky Green

"The problem isn't the Internet. The problem is the horribly insecure computers attached to the Internet. I would rather rewrite Windows than TCP/IP."

-- Bruce Scheier, Netcraft interview, 13/8/04.

"People who are willing to rely on the government to ke ep them safe are pretty much standing on Darwin's mat, pounding on the door, scr eaming, 'Take me, take me!'"

-- Carl Jacobs, Alt.Sysadmin.Recovery

"When stopping a terrorist attack or seeking to recover a kidnapped child, encountering encryption may mean the difference between success and catastrophic failures"

-- Janet Reno, Sept 99. Or in plain English "When trying to commit economic espionage and illegaly spying on our citizens, encountering encryption...."

"What makes you think you can invent a good cipher if y ou have no expertise in the subject? Maybe you can, but it's not terribly likely. Imagine how you would react if your doctor told you "You have appendicitis, a disease that is life-threatening if not treated. We have a time-tested cure that cures 99% of all patients with no noticeable side-effects, but I'm not going to give you that: I'm going to give you a new experimental treatment my cousin dreamed up last week. No, my cousin has no medical training. No, I have no evidence that the new treatment will work, and it's never been tested or analyzed in depth -- but I'm going to give it to you anyway because my cousin thinks it is good stuff." You'd find another doctor, I hope. Rational people leave medical care to the medical experts. The medical experts have a much better track record than the quacks."

-- David Wagner PhD, sci.crypt, 19th Oct 02.

"History has taught us: never underestimate the amount of money, time, and effort someone will expend to thwart a security system. It's always better to assume the worst. Assume your adversaries are better than they are. Assume science and technology will soon be able to do things they cannot yet. Give yourself a margin for error. Give yourself more security than you need today. When the unexpected happens, you'll be glad you did."

-- Bruce Schneier.

"I believed then, and continue to believe now, that the benefits to our security and freedom of widely available cryptography far, far outweigh the inevitable damage that comes from its use by criminals and terrorists...I believed, and continue to believe, that the arguments against widely available cryptography, while certainly advanced by people of good will, did not hold up against the cold light of reason and were inconsistent with the most basic American values."

-- Matt Blaze, AT&T Labs, Sept 01.

"The more corrupt the state, the more numerous the laws "

-- Tacitus

"Every time I write about the impossibility of effectiv ely protecting digital files on a general-purpose computer, I get responses from people decrying the death of copyright. "How will authors and artists get paid for their work?" they ask me. Truth be told, I don't know. I feel rather like the physicist who just explained relativity to a group of would-be interstellar travelers, only to be asked: "How do you expect us to get to the stars, then?" I'm sorry, but I don't know that, either.'' "

-- Bruce Schneier, Cryptogram 15 Aug 01.

"$_='while(read+STDIN,$_,2048) {$a=29;$c=142; if((@a=unx"C*",$_) [20]&48) {$h=5;$_=unxb24,join"",@b=map{xB8,unxb8, chr($_^$a[--$h+84])} @ARGV;s/...$/1$&/;$d=unxV,xb25,$_;$b=73;$e=256| (ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=($t=255)& ($d>>12^$d>>4^$d^$d/8))<<17, $e=$e>>8^($t&($g=($q=$e>>14&7^$e) ^$q*8^$q<<6))<<9,$_=(map {$_%16or$t^=$c^=($m=(11,10,116,100,11,122,20,100) [$_/16%8])&110;$t^=(72, @z=(64,72,$a^=12*($_%16-2?0:$m&17)) ,$b^=$_%64?12:0,@z)[$_%8]}(16..271)) [$_]^(( $h>>=8)+=$f+(~$g&$t)) for@a[128..$#a]}print+x"C*",@a}'; s/x/pack+/g;eval"

-- D e C S S in PERL

"Cryptography is like literacy in the Dark Ages. Infini tely potent, for good and ill... yet basically an intellectual construct, an idea, which by its nature will resist efforts to restrict it to bureaucrats and others who deem only themselves worthy of such Privilege."

-- "A Thinking Man's Creed for Crypto", Vin McLellan.

"This is by-design behavior, not a security vulnerability. "

-- Scott Culp, Microsoft Security Response Center, discussing the hole allowing ILOVEU to propogate, 5/5/00.

"Paranoia is our profession."

-- Strategic Air command

"a trusted system is one which, when it breaks, can break your security policy "

-- Bob Morris, NSA.