Re: DBs and Patents and Obama and Crypto

[Zack Payton <zpayton () gmail com>]

I'm a huge fan of that approach to DB monitoring (passive tap -> reassemble
-> protocol parse -> parse SQL syntax -> analyze).

Applications have a limited set of queries that they make and when you can
model those queries in terms of an AST, you can remove the data (aka the
literals) and simply hash the control logic then build a blume filter for
each application to do near-wire-speed lookups.  If something triggers,
either an app has updated (which is simple to verify), or the control logic
has changed via some form of injection (or 3rd your baseline wasn't
accurate which is a wholly separate topic).  No fancy machine learning
necessary.  Users are a little harder to model but we start by assessing
how much access to data do they actually exercise and alert on large
increases.  A stealthy attacker can stay under the radar by not doing
anything aggressive but most attackers will fall right into it.

I haven't (yet) spent to time reversing M$ wire protocols or doing this on
closed source grammars but it is possible to do query logging and feed them
into the AST generator some other way.  Agents are tricky but you can make
them light weight by just scraping off the socket and still doing your
protocol analysis rather than a more invasive debugger based approach.

I started down this route because most people don't really understand their
data models, and the apps and users that use them.  Once you get into that
space there is all kinds of benefits like auditing app privileges versus
columns actually read/written to start enacting better practice of
principle of least privilege, spotting apps that don't use prepared
statements just from the wire protocol, analyzing source IP and command
styles for database admins, spotting shared accounts, weak passwords,
identifying high privileged accounts, etc.  My point is there is a large
amount of data that can enable better decision capabilities.  I don't agree
that it's as complex as the NSA signals problems, but then again I don't
see new database features being developed every 2 weeks that the devs are
just dying to take advantage of so having to keep up with ensuring your
grammars have semantic predicates for every major version of your fancy
dialect isn't really a problem, you just gotta staff a guy that understands
compilers for when shit breaks.

When you start thinking about parsing data bases like that it starts to
remind me of the techniques applied by Ram Shankar and Sacha Faust in their
Data Driven Offense excellent talk <https://vimeo.com/133292422> only
instead of an LDAP database, we're talking about some other type and
applying similar techniques for different ends.

Z



On Fri, Oct 23, 2015 at 9:18 AM, Dave Aitel <dave () immunityinc com> wrote:

> I wanted to talk about patents in our industry, but I can't because
> everyone is all like "Software patents are evil" _until they get one_ and
> it gives me the sads.
>
> So instead I'm going to talk about this company I saw yesterday, which is
> basically this simple diagram:
>
> Web App
> [span port of your mid-tier] -----> [Parser for TDS] ---> [Machine
> learning to find SQLi]
>
> The good things about being on the network stack is that you can get
> access to clusters. The bad thing is that every minor change of the TDS
> stack or SQL syntax or anything of that nature means your system starts
> failing. And you have to auto-detect all possible variation in the network
> traffic because you're modeling what happens in an immensely complex piece
> of software on one side that you don't have access to.
>
> To avoid all possible ambiguity: This is an impossible problem to get
> right, even if you limit it to "parse one version of TDS exactly the same
> as SQL Server 2010 at a known patch level".
>
> The other option is to install debugger-like instrumenters on every DB
> server. In fact, a script to do this came out with an early version of
> Immunity Debugger, which integrated with SPIKE Proxy so you could scan for
> SQL Injection and use the feedback loop to guide your scanner around
> filters and false positives. The downside is of course having to install
> things on every DB server. In theory MS would release an API that allows a
> logical "span port" that gave you ever SQL request, and I bet there IS one
> somewhere in the auditing section.
>
> Aside from the horribleness of every possible solution in that area, which
> probably STILL works better than a few other things, I wanted to point out
> a KEY sentence you might have missed in the Crypto-War guidelines
> <https://assets.documentcloud.org/documents/2426450/read-the-nsc-draft-options-paper-on-strategic.pdf>
> the administration pointed out. It was this: Without voluntary
> <https://lists.immunityinc.com/pipermail/dailydave/2015-September/001016.html>and
> enthusiastic help from Apple and Google, really bad things we won't specify
> will happen, even if we force it all to be in cleartext. That "parse all
> variations of TDS" problem that we just looked at is the same as the SIGINT
> problem faced by the FBI/NSA/etc. Even WITH THE KEYS, the problem is
> completely intractable if Google and Apple and Microsoft want to make it
> so.
>
> I can hear Google's lawyers now: "Oh, we delivered you our latest protocol
> spec sheet, every two weeks as promised. Of course, our spec changes every
> two weeks right after we deliver it, and you are always out of date, and
> even if you WERE in date, only our software knows which version anyone is
> at at any given time, and parsing it incorrectly means you are wildly
> wrong, and if you can't provide a provably correct parser, no court will
> accept your analysis, etc. Hey, did we mention that every block is not
> encrypted, but of course it is XORed with this value which we calculate
> with the most crazy slow algorithm we could find, one million times. That's
> just this week though. Next week we are reversing every block, but we
> aren't going to update the version number on the wire."
>
> Just food for thought! ;)
> -dave
>
>
>
>
> _______________________________________________
> Dailydave mailing list
> Dailydave () lists immunityinc com
> https://lists.immunityinc.com/mailman/listinfo/dailydave
_______________________________________________
Dailydave mailing list
Dailydave () lists immunityinc com
https://lists.immunityinc.com/mailman/listinfo/dailydave