Candy security

Arseni Mourzenko
Founder and lead developer
161
articles
March 27, 2018
Tags: security 8 short 48

The ti­tle of this ar­ti­cle is a term I dis­cov­ered through the book of Kevin D. Mit­nick, The art of de­cep­tion, page 79. It means that the com­pa­ny has strong se­cu­ri­ty perime­ter with the out­side world, but once you got through, noth­ing can stop you.

In movies and games, hack­ing into sys­tems is of­ten a fast and straight­for­ward process. Find a PIN code dig­it by dig­it, and you can shut down a nu­clear re­ac­tor, or trans­fer bil­lions of dol­lars to your ac­count, or... what­ev­er.

There is no rea­son for the real life to be the same. In real life, hack­ing hap­pens in steps. Some­one finds a path in­jec­tion which makes it pos­si­ble to make an XSS ex­ploit, which in turn makes it pos­si­ble through a PC of an em­ploy­ee to gain ac­cess to se­cu­ri­ty cam­eras. From there, the hack­er achieves to mon­i­tor the LAN traf­fic, get a pass­word of a guy who can log in to the serv­er con­tain­ing the root cer­tifi­cate; in turn, it makes it pos­si­ble to de­crypt the re­main­ing traf­fic, hack into more ma­chines, and through them, get to the tar­get.

Un­less com­pa­nies do what­ev­er it takes to sim­pli­fy the job of a hack­er.

One of the un­for­tu­nate facts is that most com­pa­nies, in­clud­ing the large ones, are rea­son­ing in terms of us vs. they, or, if you want, com­pa­ny vs. out­side world. They pre­tend that the bad guy is some­where out­side, and a wall from the out­side world will keep him out­side in­def­i­nite­ly. This, in turn, leads to the be­lief that a mag­i­cal so­lu­tion to keep bad guys out­side ex­ists. It could be any­thing: a fire­wall, a router or a trust­ed sys­tem ad­min­is­tra­tor.

This works well, un­til you find that the bad per­son is al­ready in­side.

Since the com­pa­ny fo­cus­es on the sep­a­ra­tion be­tween we and them, the ef­fort goes into se­cur­ing the fron­tier. Once the bad guy is in­side, he is pre­sent­ed with amaz­ing op­por­tu­ni­ties. Such as do an SSH to the log ma­chine and get rid of the logs in­crim­i­nat­ing the at­tack­er. Or have fun with your back­ups be­fore play­ing with your data­bas­es.

For the past weeks, I was strength­en­ing the se­cu­ri­ty of spe­cif­ic ma­chines. For in­stance, a bunch of ap­pli­ca­tion servers are now us­ing TLS be­tween them and the re­verse prox­ies, and au­then­ti­cate those re­verse prox­ies by us­ing client-side cer­tifi­cates. This means that when some ma­chine, such as the DNS serv­er, is com­pro­mised, an at­tack­er would still be un­able to per­form MITM at­tack, or to sniff the traf­fic, or to pre­tend to be the le­git­i­mate client. To com­pro­mise the ap­pli­ca­tion serv­er, an at­tack­er would need to ei­ther gain root ac­cess to the re­verse proxy, or find a con­fig­u­ra­tion er­ror in Apache to by­pass cer­tifi­cate val­i­da­tion.

There were times where the same serv­er would host the ap­pli­ca­tion, the data­base and a dozen oth­er ser­vices. Com­pro­mise the serv­er, and you get ac­cess to every­thing. Now that dif­fer­ent com­po­nents are host­ed on ded­i­cat­ed ma­chines, there is re­al­ly no need to have the same lev­el of se­cu­ri­ty as be­fore. Gain­ing root ac­cess to the data­base serv­er should give you the abil­i­ty to trash the data, but it shouldn't make it pos­si­ble to use SMTP or change the ap­pli­ca­tion log­ic in or­der to at­tack the users or mon­i­tor the sur­veil­lance cam­eras.

This is why I strong­ly en­cour­age the teams who adopt­ed the mi­croser­vices ap­proach to en­sure every ser­vice they re­lease is avail­able through in­ter­net. Know­ing that the ser­vice is ex­pect­ed to be ac­cessed only by trust­ed per­son­nel gives a false sense of se­cu­ri­ty: most de­vel­op­ers will take ad­van­tage of that in or­der to avoid work­ing on com­plex se­cu­ri­ty sub­jects. How­ev­er, when you know that the ser­vice can be ac­cessed from any­where, you start think­ing if the fea­ture you're im­ple­ment­ing could be ex­ploit­ed by a ma­li­cious per­son or if it is re­al­ly nec­es­sary to con­fig­ure the serv­er so open­ly.