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...