Attack Driven Defense - infosec rant [was: What is Intel(R) Core™ vPro™ Technology Animation]
i really can't emphasize this enough: robust defense is based on realistic threats, and realistic threats are identified via attackers' perspective. i've been diving down this rabbit hole since before i challenged covert FLTINFOWARCEN members* to "get as blackhat on this motherfucker as you can" during an ad hoc challenge at DEF CON 13. i started down this path when i realized that robust peer to peer systems must protect each node to the highest degree required by any participant. it's the opposite of pandering to the "lowest common denominator". on the plus side, once you have addressed security for the "most stringent requirement" all other systems and peers enjoy the benefit of this elevated level of protection. the bad news is that attacks continue to improve, and i'm no where near satisfied in my ability to protect my own systems against the capabilities myself and my peers have at their disposal. the vast majority of infosec is useless bullshit, the vast majority of infosec conferences are pandering crap; the whole industry (educational/professional/military) is shit, if we're being honest. there is a great talk, fuck you to thinkst.com for blocking it, which covers these failings at just a conference level, with parallels to the industry as a whole: http://207.198.103.187:8081/infosuck-talk_about_talks.pdf sha256: ce836410fdc638066bf6aedec0e1d6f2ce66fb46329c5f92336e42a671272e55 i've never taken an infosec position, for these reasons, among others, and i don't plan to start. quality (and by extension, information security) should be a given, a "built-in" feature of any product, with the investment necessary to achieve it. anything less is bullshit; infosec should not exist! my $0.02 best regards, * hacker friends and i ran a challenge: here's the root password. we're running unencrypted 802.11b wifi, there's a $100 bill in the case. get in - you get money and the hardware! everyone failed, despite two interesting 0day attacks. (we ran IPsec with custom out-of-band keying seeded by VIA C5P hardware entropy generators with our own custom rngd.) after being unable to compromise our setup, $fed handed me a card. i still remember the latin translation adorning his card, which seems particular appropos given revelations this year: "let them hate us, so long as they fear us." On Mon, Sep 23, 2013 at 3:36 PM, coderman <coderman@gmail.com> wrote:
On Mon, Sep 23, 2013 at 1:33 PM, Jeffrey Walton <noloader@gmail.com> wrote:
... Do you just snatch the source code and intellectual property, or do you use it as a springboard into other things? (I've never really thought about it).
for better or for worse (mostly better) these systems have made their way into release package builds and production deployment processes.
i'm speaking in generalities here, for various reasons, but common trajectories include: - obtaining the private keys or http auth passwords for access to source code repositories. - obtaining ssh private keys for access to other systems, e.g. remote build hosts or even production hosts. - obtaining kerberos/ldap/http/* auth credentials for bug reporting systems, release code signing, or other facilities. - obtaining access to datacenter or operations automation: cfengine, chef, puppet, etc. these are really useful ;) - obtaining test automation tools and other "QA" hooks with elevated access and fewer controls. - privilege escalation on the CI host which in turn is often whitelisted and useful as further pivot. - providing example usage for invocation of and command line parameters for custom internal software. - providing excellent watering hole "infection vector" for technical staff in an org. e.g. taking over engineering workstations.
from here you've got everything you need to infiltrate an entire organization.
the source code provides "hard coded" keys/passwords or pointers to files where interesting bits lay,
the conduit to engineering systems which grant access to public facing services and data stores,
the credentials and access for all operational concerns,
the org is your oyster...
On Mon, Sep 23, 2013 at 4:17 PM, coderman <coderman@gmail.com> wrote:
...
the source code provides "hard coded" keys/passwords or pointers to files where interesting bits lay,
someone asks: "how do you find the interesting sources?" this is something i pride myself on, having dealt with scores of large enterprise systems and ERP deployments over many years. i'm going give hints, rather than specifics, but it will be sufficient for the motivated party. (people ask why i rarely distribute code myself - it is because i need every strategic advantage i can get, and custom software, builds, and configurations are part of that operational security. maybe one day...) orienting yourself in a large code base: 0. you must know how to code in, and what frameworks, libraries, and toolkits are common for, the language at hand. 1. filter all the third party components and sources out. these are not interesting. 2. keyword search for password handling, private keys, hardcoded secrets, etc. 3. keyword search for the public interfaces of interest, or API calls exposed, etc. 4. keyword search for business specific terms, e.g. where does the meat of their business logic reside? as you become more familiar with how various institutions implement large systems, you get a "sixth sense" or "intuitive" ability to focus in on the relevant parts and identify where shortcuts and oversights are most likely to occur. rinse, repeat, again and again, and eventually you'll find yourself 10x more effective at these tasks, having combined your increasingly accurate intuition with custom scripts and techniques for maximum effectiveness. it's an almost spooky ability when you look at a piece of code and just "know" where the bugs are, and sure enough, you find them right where you expect.
participants (1)
-
coderman