hbase attack scenarios?

[Wilm Schumacher <wi...@cawoom.com>]

Hi,

sry for asking a fundamental newbie question again :/.

But after coding some applications with using hbase I want to reconsider
the security. Especially after today some (i.e. billions) e-mail
addresses and hashes are stolen.

So, my question is: what are the most prominent and general attack
scenarios on a e.g. web app using hbase?

The official documentation
http://hbase.apache.org/book/security.html
is not very verbose about this topic.

Of course this depends on the application, but I would appreciate
general hints to possible attacks, which could be interesting for other
readers of this mailing list, too.

Perhaps as an example we could image a social network:

* with a table for the users (rowkey = username, data:passwdhash,
data:birthdate, data:firstname, data:lastname etc., and chatid:XYZ,
chatid:ZYX etc.)

* and a table for communication ("chat") between this persons (rowkey =
chatID + Timestamp).

* using the thrift interface (or somthing special adopted but similar to
the thrift interface. Some get, some mutateRow operations etc.)

for this application I can only image 4 possible attacks (which are
actually not specific to hbase)
1.) DOS
=> Firewall protection. But nobody can do something against that if it's
large enough

2.) Capturing of the application server (web server in this case) and
getting direct access to the db (and then do a scan of the data)
=> user access control (e.g.
http://hbase.apache.org/book/hbase.accesscontrol.configuration.html)

3.) errors in the (web-)application so that a user is allowed to read
chats of other people (by e.g. spoofing of requests)

4.) cross site scripting and cross site forgery (or session capturing etc.)

1 and 2 are standard attacks which affects every system, db or server,
and can be avoided by standard methods. 3 and 4 are standard tricks for
web apps where hbase cannot do anything to protect the data (where it's
actually not important which db someone uses). But there are trillions
of possible strategies against that.

But I cannot imagine something like an SQL-injection, where the
avoidance of the attack have to be build into the application (escaping
etc).

Are there any hbase specific attacks you can imagine?

Best wishes

Wilm

Re: hbase attack scenarios?

[Esteban Gutierrez <es...@cloudera.com>]

Hello Will,



--
Cloudera, Inc.



On Wed, Aug 6, 2014 at 9:14 PM, Wilm Schumacher <wi...@cawoom.com>
wrote:

>
>
> Am 06.08.2014 um 19:07 schrieb Andrew Purtell:
> > We have no known vulnerabilities that equate to a SQL injection attack
> > vulnerability. However, as Esteban says you'd want to treat HBase like
> any
> > other datastore underpinning a production service and out of an abundance
> > of caution deploy it into a secure enclave behind an internal service
> API,
> > so random (possibly untrusted) clients are not hitting it directly.
> this is of course a very good point. Not specific to hbase, but of
> course true for hbase, too.
>
> There should be of course only one type of client who hit the db
> directly: the operating service clients.
>
> > If you'd like to encrypt data flowing in and out of the secure enclave on
> > the wire, deploy a KDC for cluster services and enable strong
> > authentication plus SASL "auth-conf" protection level. Requires HBase
> > 0.98.3 or higher (HBASE-11149).
> thanks for the hints.
>
> > The administrative UIs might have some kind of cross-site vulnerability
> > because we don't worry about that; the UIs are expected to be firewalled
> > for admin access only.
> this is of course an important point, too.
>
> So my takeaway from your responses are:
> * make the db as encapsuled as possible => should be hit only by the
> service api which has to be as restrictive as possible
> * least priviliges of course
> * every administrative interface should be firewalled (actually I would
> also use openvpn, but the general point is clear)
>
> However, this are very general points (true of course, but very general
> and generic for all dbs or whatever system does the work).
>
> That's there is nothing else to consider makes me kind of nervous. So if
> there is something like a login, where the user can post "username" and
> "password", and I do a getRow for the username (=rowkey), and than e.g.
> make a check for the passwd (sha encrypted of course) etc. ... basically
> the user can define whatever string the user wants to the getRow rowkey.
>

You avoid that by exposing an internal service API to the clients as Andrew
said. There are many authentication protocols that you could use and HBase
should be only used as the store. For this trivial case a simple solution
might be better to pass the of SHA of password as part of the request to
this internal API and cache results via a LRU table.  So any attempt to try
to log in via brute force would be hitting first the internal API and not
HBase. If you cache valid users (should fit in memory) you will also avoid
going to HBase all the time.


>
> So the application does not need to "escape" the username for the getRow
> which is then pumped more or less directly into the db (even if it is
> just a getRow) ... just makes me nervous :D.
>



> However, the attack scenarios pointed out by Esteban (evil RPC => OOME)
> showed me, that I should restrict the possible strings (e.g. usernames
> in this case) to e.g. [a-Z0-9]{2,100}, even if there is no possible
> vulnerablity known.
>

Thats not exactly the case, in HBase the input will be serialized by the
HBase client and HBase will process that data correctly regardless the
input values (for HBase keys and values are plain bytes). The OOME
escenario implies that the user could connect directly to the HBase cluster
and generate corrupt messages that could trigger an OOME in the Region
Servers.



>
> Perhaps I did SQL too long to be a little more trustful. I guess this is
> the adaption process for me and "real" NoSQL. God, I love hbase ;).
>
>
+1



> Thanks for the replies and keep up the good work
>
> Wilm
>

Re: hbase attack scenarios?

[Wilm Schumacher <wi...@cawoom.com>]

Am 06.08.2014 um 19:07 schrieb Andrew Purtell:
> We have no known vulnerabilities that equate to a SQL injection attack
> vulnerability. However, as Esteban says you'd want to treat HBase like any
> other datastore underpinning a production service and out of an abundance
> of caution deploy it into a secure enclave behind an internal service API,
> so random (possibly untrusted) clients are not hitting it directly.
this is of course a very good point. Not specific to hbase, but of
course true for hbase, too.

There should be of course only one type of client who hit the db
directly: the operating service clients.

> If you'd like to encrypt data flowing in and out of the secure enclave on
> the wire, deploy a KDC for cluster services and enable strong
> authentication plus SASL "auth-conf" protection level. Requires HBase
> 0.98.3 or higher (HBASE-11149).
thanks for the hints.

> The administrative UIs might have some kind of cross-site vulnerability
> because we don't worry about that; the UIs are expected to be firewalled
> for admin access only.
this is of course an important point, too.

So my takeaway from your responses are:
* make the db as encapsuled as possible => should be hit only by the
service api which has to be as restrictive as possible
* least priviliges of course
* every administrative interface should be firewalled (actually I would
also use openvpn, but the general point is clear)

However, this are very general points (true of course, but very general
and generic for all dbs or whatever system does the work).

That's there is nothing else to consider makes me kind of nervous. So if
there is something like a login, where the user can post "username" and
"password", and I do a getRow for the username (=rowkey), and than e.g.
make a check for the passwd (sha encrypted of course) etc. ... basically
the user can define whatever string the user wants to the getRow rowkey.

So the application does not need to "escape" the username for the getRow
which is then pumped more or less directly into the db (even if it is
just a getRow) ... just makes me nervous :D.

However, the attack scenarios pointed out by Esteban (evil RPC => OOME)
showed me, that I should restrict the possible strings (e.g. usernames
in this case) to e.g. [a-Z0-9]{2,100}, even if there is no possible
vulnerablity known.

Perhaps I did SQL too long to be a little more trustful. I guess this is
the adaption process for me and "real" NoSQL. God, I love hbase ;).

Thanks for the replies and keep up the good work

Wilm

Re: hbase attack scenarios?

[Andrew Purtell <ap...@apache.org>]

We have no known vulnerabilities that equate to a SQL injection attack
vulnerability. However, as Esteban says you'd want to treat HBase like any
other datastore underpinning a production service and out of an abundance
of caution deploy it into a secure enclave behind an internal service API,
so random (possibly untrusted) clients are not hitting it directly.

If you'd like to encrypt data flowing in and out of the secure enclave on
the wire, deploy a KDC for cluster services and enable strong
authentication plus SASL "auth-conf" protection level. Requires HBase
0.98.3 or higher (HBASE-11149).

The administrative UIs might have some kind of cross-site vulnerability
because we don't worry about that; the UIs are expected to be firewalled
for admin access only.





On Tue, Aug 5, 2014 at 10:08 PM, Esteban Gutierrez <es...@cloudera.com>
wrote:

> Hello Will,
>
> Thats a very interesting topic. Unfortunately many things depend on the
> version of HBase is under attack. As you say 1) DoS are too easy to trigger
> if HBase is exposed directly to applications and without any data
> validation, e.g. crafting the right RPC its possible to trigger an OOME in
> the RSs if running version prior to 0.94.x or 2) by looking at RPCs on the
> wire is trivial to perform replay attack if SASL is not being used. Even
> having additional layers like Thrift or REST there are limitations that
> need to be considered when exposing live traffic to HBase to avoid DDoS or
> other attacks.  I think interesting attacks have been discussed before such
> as https://issues.apache.org/jira/browse/HBASE-11070 and
> https://issues.apache.org/jira/browse/HBASE-11457
>
> cheers,
> esteban.
>
> --
> Cloudera, Inc.
>
>
>
> On Tue, Aug 5, 2014 at 9:46 PM, Wilm Schumacher <
> wilm.schumacher@cawoom.com>
> wrote:
>
> > Hi,
> >
> > sry for asking a fundamental newbie question again :/.
> >
> > But after coding some applications with using hbase I want to reconsider
> > the security. Especially after today some (i.e. billions) e-mail
> > addresses and hashes are stolen.
> >
> > So, my question is: what are the most prominent and general attack
> > scenarios on a e.g. web app using hbase?
> >
> > The official documentation
> > http://hbase.apache.org/book/security.html
> > is not very verbose about this topic.
> >
> > Of course this depends on the application, but I would appreciate
> > general hints to possible attacks, which could be interesting for other
> > readers of this mailing list, too.
> >
> > Perhaps as an example we could image a social network:
> >
> > * with a table for the users (rowkey = username, data:passwdhash,
> > data:birthdate, data:firstname, data:lastname etc., and chatid:XYZ,
> > chatid:ZYX etc.)
> >
> > * and a table for communication ("chat") between this persons (rowkey =
> > chatID + Timestamp).
> >
> > * using the thrift interface (or somthing special adopted but similar to
> > the thrift interface. Some get, some mutateRow operations etc.)
> >
> > for this application I can only image 4 possible attacks (which are
> > actually not specific to hbase)
> > 1.) DOS
> > => Firewall protection. But nobody can do something against that if it's
> > large enough
> >
> > 2.) Capturing of the application server (web server in this case) and
> > getting direct access to the db (and then do a scan of the data)
> > => user access control (e.g.
> > http://hbase.apache.org/book/hbase.accesscontrol.configuration.html)
> >
> > 3.) errors in the (web-)application so that a user is allowed to read
> > chats of other people (by e.g. spoofing of requests)
> >
> > 4.) cross site scripting and cross site forgery (or session capturing
> etc.)
> >
> > 1 and 2 are standard attacks which affects every system, db or server,
> > and can be avoided by standard methods. 3 and 4 are standard tricks for
> > web apps where hbase cannot do anything to protect the data (where it's
> > actually not important which db someone uses). But there are trillions
> > of possible strategies against that.
> >
> > But I cannot imagine something like an SQL-injection, where the
> > avoidance of the attack have to be build into the application (escaping
> > etc).
> >
> > Are there any hbase specific attacks you can imagine?
> >
> > Best wishes
> >
> > Wilm
> >
>



-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: hbase attack scenarios?

[Esteban Gutierrez <es...@cloudera.com>]

Hello Will,

Thats a very interesting topic. Unfortunately many things depend on the
version of HBase is under attack. As you say 1) DoS are too easy to trigger
if HBase is exposed directly to applications and without any data
validation, e.g. crafting the right RPC its possible to trigger an OOME in
the RSs if running version prior to 0.94.x or 2) by looking at RPCs on the
wire is trivial to perform replay attack if SASL is not being used. Even
having additional layers like Thrift or REST there are limitations that
need to be considered when exposing live traffic to HBase to avoid DDoS or
other attacks.  I think interesting attacks have been discussed before such
as https://issues.apache.org/jira/browse/HBASE-11070 and
https://issues.apache.org/jira/browse/HBASE-11457

cheers,
esteban.

--
Cloudera, Inc.



On Tue, Aug 5, 2014 at 9:46 PM, Wilm Schumacher <wi...@cawoom.com>
wrote:

> Hi,
>
> sry for asking a fundamental newbie question again :/.
>
> But after coding some applications with using hbase I want to reconsider
> the security. Especially after today some (i.e. billions) e-mail
> addresses and hashes are stolen.
>
> So, my question is: what are the most prominent and general attack
> scenarios on a e.g. web app using hbase?
>
> The official documentation
> http://hbase.apache.org/book/security.html
> is not very verbose about this topic.
>
> Of course this depends on the application, but I would appreciate
> general hints to possible attacks, which could be interesting for other
> readers of this mailing list, too.
>
> Perhaps as an example we could image a social network:
>
> * with a table for the users (rowkey = username, data:passwdhash,
> data:birthdate, data:firstname, data:lastname etc., and chatid:XYZ,
> chatid:ZYX etc.)
>
> * and a table for communication ("chat") between this persons (rowkey =
> chatID + Timestamp).
>
> * using the thrift interface (or somthing special adopted but similar to
> the thrift interface. Some get, some mutateRow operations etc.)
>
> for this application I can only image 4 possible attacks (which are
> actually not specific to hbase)
> 1.) DOS
> => Firewall protection. But nobody can do something against that if it's
> large enough
>
> 2.) Capturing of the application server (web server in this case) and
> getting direct access to the db (and then do a scan of the data)
> => user access control (e.g.
> http://hbase.apache.org/book/hbase.accesscontrol.configuration.html)
>
> 3.) errors in the (web-)application so that a user is allowed to read
> chats of other people (by e.g. spoofing of requests)
>
> 4.) cross site scripting and cross site forgery (or session capturing etc.)
>
> 1 and 2 are standard attacks which affects every system, db or server,
> and can be avoided by standard methods. 3 and 4 are standard tricks for
> web apps where hbase cannot do anything to protect the data (where it's
> actually not important which db someone uses). But there are trillions
> of possible strategies against that.
>
> But I cannot imagine something like an SQL-injection, where the
> avoidance of the attack have to be build into the application (escaping
> etc).
>
> Are there any hbase specific attacks you can imagine?
>
> Best wishes
>
> Wilm
>