LA PE­SA­DI­LLA DE LA BAN­CA Y EL RE­TAIL

¿Re­cuer­dan a Freddy Krue­ger, el psi­có­pa­ta que ate­rra­ba a los ha­bi­tan­tes de la ca­lle Elm? Un per­so­na­je si­mi­lar a él es­tá in­fil­trán­do­se en los de­par­ta­men­tos de IT y pue­de con­ver­tir­se en su peor pe­sa­di­lla, el malwa­re.

IT Now Guatemala - - IT PRO - Se­le­ne Ague­ro

¿Re­cuer­dan a Freddy Krue­ger, el psi­có­pa­ta que ate­rra­ba a los ha­bi­tan­tes de la ca­lle Elm? Un per­so­na­je si­mi­lar a él es­tá in­fil­trán­do­se en los de­par­ta­men­tos de IT y pue­de con­ver­tir­se en su peor pe­sa­di­lla, el malwa­re.

“Uno, dos, Freddy vie­ne por ti, tres, cua­tro, cie­rra la puer­ta, cin­co, seis, co­ge un cru­ci­fi­jo, sie­te, ocho, man­ten­te des­pier­to, nue­ve, diez, nun­ca más dor­mi­rás”. Esa era la can­ción que en­to­na­ban las vic­ti­mas de Freddy, an­tes de to­mar­las en su po­der y aun­que pa­rez­ca des­ca­be­lla­do, es­to no se ale­ja mu­cho de la reali­dad de los de­par­ta­men­tos de in­for­má­ti­ca.

Las pe­sa­di­llas en IT del sec­tor fi­nan­cie­ro y re­tail, se con­vier­ten en reali­dad cuan­do un malwa­re se in­fil­tra en sus sis­te­mas pa­ra ins­ta­lar­se en las ba­ses de da­tos de los ser­vi­do­res y des­truir lo que hay en su pa­so.

El na­ci­mien­to del malwa­re se re­mon­ta des­de 1949, cuan­do el ma­te­má­ti­co John Von Neu­mann, pre­sen­tó la Teo­ría y Or­ga­ni­za­ción de Autómatas Com­ple­ja, don­de mues­tra có­mo un pro­gra­ma pue­de ser di­se­ña­do pa­ra re­pro­du­cir­se a sí mis­mo, lo cual es el prin­ci­pio bá­si­co de un vi­rus in­for­má­ti­co y fue el pri­me­ro en el mun­do.

Ba­sa­dos en esa teo­ría, fue co­mo los hac­kers desa­rro­lla­ron el pri­mer vi­rus in­for­má­ti­co, Cree­per, que anun­cia­ba a los usua­rios de compu­tado­ras IBM 360, que

“Exis­ten di­ver­sas for­mas de in­fil­tra­ción, sin em­bar­go, la más co­mún en Cen­troa­mé­ri­ca y el Ca­ri­be se cen­tra en la in­ge­nie­ría so­cial”, Ra­fael Agui­le­ra, Sy­man­tec.

se ha­bían in­fec­ta­do del malwa­re pre­sen­tan­do el desafian­te men­sa­je “soy una en­re­da­de­ra atrá­pa­me si pue­des”.

Si bien es cier­to ese malwa­re de 1959 no re­pre­sen­ta­ba nin­gu­na ame­na­za a los usua­rios que caían en sus ga­rras, pues lo úni­co que ha­cía era brin­car de una má­qui­na a otra sin cau­sar ma­yor da­ño.

Pe­ro eso fue ha­ce más de 50 años, aho­ra los in­tere­ses de los ata­can­tes se ba­san en crear téc­ni­cas opor­tu­nis­tas pa­ra uti­li­zar el malwa­re co­mo una ma­ne­ra fá­cil de ata­car nue­vos blan­cos, en mu­chos ca­sos la in­dus­tria ban­ca­ria y de re­tail, que ade­más de te­ner di­ne­ro en sus ar­cas, po­seen da­tos va­lio­sos que ha­cen más gran­des las po­si­bi­li­da­des de lu­crar­se.

“El malwa­re tie­ne el al­can­ce de ro­bar in­for­ma­ción des­de es­ta­cio­nes fi­na­les y de ba­ses de da­tos de ser­vi­do­res. Aho­ra el malwa­re no bus­ca da­ñar los sis­te­mas, si no ob­te­ner el ac­ti­vo va­lio­so de las per­so­nas o em­pre­sas”, agre­gó Cris­tian Fuen­tes, se­nior se­cu­rity ad­vi­sor de Wi­de­fen­se, em­pre­sa de se­gu­ri­dad in­for­má­ti­ca y con­sul­to­ría.

Cu­rio­sa­men­te el pro­ce­so de re­ci­cla­je es una prác­ti­ca que tam­bién uti­li­zan los ci­ber­de­lin­cuen­tes pa­ra crear nue­vos ata­ques.

“El malwa­re exis­ten­te so­lo ne­ce­si­ta mo­di­fi­ca­cio­nes me­no­res pa­ra con­ver­tir­se en una ame­na­za de día ce­ro to­tal­men­te ope­ra­cio­nal. A un al­to ni­vel, se ne­ce­si­ta de una vul­ne­ra­bi­li­dad que per­mi­ta al malwa­re in­fil­trar un sis­te­ma. De allí la im­por­tan­cia de que las or­ga­ni­za­cio­nes man­ten­gan un pro­ce­so de ges­tión de vul­ne­ra­bi­li­da­des y for­ta­le­ci­mien­to de los sis­te­mas bus­can­do la mi­ti­ga­ción de es­tas ame­na­zas”, di­jo

Cé­sar Cas­ti­llo, in­ge­nie­ro de se­gu­ri­dad de Cew­tec.

Pa­ra Ro­dol­fo Cam­pos, ex­per­to de se­gu­ri­dad in­for­má­ti­ca de Fudog, un malwa­re prác­ti­ca­men­te es un soft­wa­re que pue­de desa­rro­llar­se en cual­quier len­gua­je de pro­gra­ma­ción y pue­de ex­plo­tar cual­quier vul­ne­ra­bi­li­dad en un sis­te­ma.

“La idea de desa­rro­llar un malwa­re, es que to­dos los pa­sos que yo ha­go de ma­ne­ra ma­nual de re­vi­sar una compu­tado­ra, de ex­plo­tar una vul­ne­ra­bi­li­dad y te­ner ac­ce­so a los sis­te­mas; se pa­sen a len­gua­je có­di­go y se em­pa­que­ten en un pro­gra­ma, pa­ra lue­go ser li­be­ra­dos”, agre­gó Cam­pos.

Sin em­bar­go, an­tes de crear el soft­wa­re ma­li­cio­so, los ata­can­tes nor­mal­men­te si­guen una ru­ta que con­sis­te ini­cial­men­te en iden­ti­fi­car el sis­te­ma ope­ra­ti­vo que uti­li­za la en­ti­dad, Win­dows, Li­nux, An­droid o IOS, en ca­so de que el ob­je­ti­vo sea un dis­po­si­ti­vo mó­vil.

“De­pen­dien­do del ob­je­ti­vo del ci­ber­cri­mi­nal, así se­rá ele­gi­do el sis­te­ma. Si el ob­je­ti­vo es com­pro­me­ter sis­te­mas de usua­rios de ho­gar o ad­mi­nis­tra­ti­vos, se­gu­ra­men­te de­be ele­gir un sis­te­ma de la fa­mi­lia de Mi­cro­soft. Si por el con­tra­rio la pla­ta­for­ma ob­je­ti­vo se­rán los dis­po­si­ti­vos mó­vi­les, es al­ta­men­te pro­ba­ble que la elec­ción sea An­droid. Pe­ro si el ob­je­ti­vo son ser­vi­do­res de ser­vi­cios en In­ter­net, lo más ló­gi­co se­ría ele­gir pla­ta­for­mas Li­nux. Es­to se de­be a la cuo­ta de mer­ca­do que po­see ca­da pla­ta­for­ma en sus di­fe­ren­tes sec­to­res”, aco­tó Amil­car De León, consultor de se­gu­ri­dad in­for­má­ti­ca de De­vel Se­cu­rity.

Una vez ele­gi­da la pla­ta­for­ma ob­je­ti­vo, los ata­can­tes pro­ce­den a se­lec­cio­nar el mé­to­do de pro­pa­ga­ción. Si el ar­chi­vo se­rá un eje­cu­ta­ble (.exe, .bat, .com, .sh, en­tre otros), si es­ta­rá de­trás de las fa­mo­sas ma­cros de Mi­cro­soft Of­fi­ce, o bien un script web, en­tre otras for­mas.

Se­gún los pro­fe­sio­na­les en ciberseguridad, en es­te pa­so los ata­can­tes de­fi­nen a la vez el len­gua­je de pro­gra­ma­ción a uti­li­zar, pe­ro en es­te te­ma sur­ge una dis­yun­ti­va, por­que mien­tras unos ex­per­tos in­di­can que el len­gua­je que nor­mal­men­te uti­li­zan los ci­be­ra­ta­can­tes es C++ o C, otros di­cen que la ca­rac­te­rís­ti­ca de que pyt­hon es mul­ti­pla­ta­for­ma y que con él se pue­den ata­car ma­qui­nas Win­dows, Li­nux, Mac OS y dis­po­si­ti­vos An­droid, lo ha­ce más po­pu­lar pa­ra el desa­rro­llo de malwa­re.

Si­guien­do en el pro­ce­so del desa­rro­llo, los ata­can­tes se de­di­can a iden­ti­fi­car un pun­to dé­bil de la pla­ta­for­ma ob­je­ti­vo, por ejem­plo una vul­ne­ra­bi­li­dad de soft­wa­re que pue­de co­no­cer­se me­dian­te in­ves­ti­ga­ción de vul­ne­ra­bi­li­da­des pú­bli­cas o bien me­dian­te el aná­li­sis di­rec­to del soft­wa­re en bús­que­da de fa­llas no co­no­ci­das.

Ca­si de ma­ne­ra in­me­dia­ta el si­guien­te re­qui­si­to que de­sa­rro­llan es la de­fi­ni­ción de cuál se­rá la ac­ción que reali­ce el malwa­re una vez que ha in­fec­ta­do de ma­ne­ra sa­tis­fac­to­ria a su víc­ti­ma. Es de aquí don­de na­cen mu­chas ve­ces las di­fe­ren­tes ca­te­go­rías de malwa­re, de­bi­do a su com­por­ta­mien­to; una ac­ción po­dría ser re­pro­du­cir­se a sí mis­mo, per­mi­tir to­mar con­trol del dis­po­si­ti­vo in­fec­ta­do, cap­tu­rar las te­clas pre­sio­na­das o ro­bo de in­for­ma­ción.

El pro­ce­so de la co­di­fi­ca­ción del malwa­re de­pen­de di­rec­ta­men­te de la crea­ti­vi­dad y ha­bi­li­dad téc­ni­ca de la per­so­na que lo desa­rro­lle y una vez crea­da una ver­sión fun­cio­nal, co­mo cual­quier pieza de soft­wa­re, es­te de­be pa­sar por prue­bas pa­ra va­li­dar su efec­ti­vi­dad y fun­cio­na­mien­to.

Co­mo úl­ti­mo pa­so, ya cuan­do el có­di­go es­tá desa­rro­lla­do y su efec­ti­vi­dad pa­só las prue­bas a las que fue so­me­ti­do, los ata­can­tes pa­san por el pro­ce­so de ele­gir el mé­to­do de in­fil­tra­ción ade­cua­do pa­ra ca­da víc­ti­ma.

En cuan­to a los ata­ques di­ri­gi­dos a la in­dus­tria de ca­de­na de abas­te­ci­mien­to, el In­ge­nie­ro de Cew­tec ex­pli­có, que el enemi­go ha te­ni­do que en­fo­car­se en el ro­bo de da­tos de tar­je­tas de cré­di­to co­mo su­ce­dió con los ca­sos de Ho­me De­pot y Tar­get.

“Los da­tos de las tar­je­tas son de muy al­to va­lor pues per­mi­te frau­du­len­ta­men­te ad­qui­rir bie­nes que a su vez pue­den con­ver­tir­se en efec­ti­vo”, agre­gó el vo­ce­ro.

Y de­bi­do a que el ob­je­ti­vo de los ata­can­tes en el sec­tor re­tail es com­pro­me­ter la in­for­ma­ción de las tar­je­tas de cré­di­to pa­ra su pos­te­rior uso ilí­ci­to, los dis­po­si­ti­vos Point

of Sa­le son la pre­sa re­fe­ren­te pa­ra las cua­les los enemi­gos de­sa­rro­llan malwa­re pa­ra co­rrer en es­te ti­po de pla­ta­for­mas.

Se­gún Em­ma­nuel Es­pi­no­za de Con­zul­tek, pa­ra es­te sec­tor los ata­ques no son ne­ce­sa­ria­men­te di­ri­gi­dos y caen más en los ata­ques ma­si­vos. El sec­tor de dis­tri­bu­ción, al me­nos en La­ti­noa­mé­ri­ca, se di­fi­cul­ta el con­trol de to­das las má­qui­nas y la se­gu­ri­dad de las mis­mas, ya que no se cuen­ta con el pre­su­pues­to que pue­de lle­gar a te­ner el sec­tor fi­nan­cie­ro.

En la in­dus­tria ban­ca­ria, don­de se rea­li­zan transac­cio­nes mo­ne­ta­rias las 24 ho­ras del día, 365 días del año y que al­ma­ce­na can­ti­da­des mi­llo­na­rias de di­ne­ro, de­di­ca obli­ga­to­ria­men­te una can­ti­dad im­por­tan­te de re­cur­sos en he­rra­mien­tas de se­gu­ri­dad que res­guar­dan la in­for­ma­ción sen­si­ble. Y los ci­be­ra­ta­can­tes lo sa­ben, tie­nen cla­ro que los ban­cos y de­más en­ti­da­des fi­nan­cie­ras es­tán ro­dea­dos por to­do un ar­se­nal de he­rra­mien­tas que ase­gu­ran la in­for­ma­ción, por eso su mé­to­do de in­fil­tra­ción es la ca­pa ocho.

Los usua­rios, vis­tos co­mo el es­la­bón más dé­bil, son de las for­mas más uti­li­za­das y efec­ti­vas pa­ra pro­pa­gar malwa­re es y se­gui­rá sien­do la tác­ti­ca de in­ge­nie­ría so­cial.

“En el sec­tor ban­ca­rio, pa­ra rea­li­zar frau­de por me­dio de malwa­re, nor­mal­men­te exis­te al­gún ti­po de in­si­der (ata­can­te in­terno). Pe­ro tam- bién las téc­ni­cas de in­ge­nie­ría so­cial son muy efec­ti­vas pa­ra to­mar con­trol de los sis­te­mas y de esa for­ma po­der es­ca­lar a los sis­te­mas transac­cio­na­les pa­ra rea­li­zar frau­de”, ex­pli­có Luis Cor­dón vo­ce­ro de De­vel Se­cu­rity.

Tes­ti­go de es­ta si­tua­ción es el hac­ker éti­co Ro­dol­fo Cam­pos de Fudog, quien afir­ma que el phis­hing de­fi­ni­ti­va­men­te es la me­jor for­ma de in­gre­sar a las com­pa­ñías.

“A ve­ces uno se asus­ta de lo fá­cil que es con­se­guir in­for­ma­ción pú­bli­ca, po­der le­van­tar 500 cuen­tas de co­rreo elec­tró­ni­co con cual­quier he­rra­mien­ta, Pho­tos­hop una plan­ti­lla html que lo úni­co que se ha­ce es ha­cer­las pa­re­cer le­gí­ti­mas, en­viar­las por co­rreo y lo que que­da es sen­tar­se a pes­car pre­sas”, aco­tó.

Es­te ti­po de ata­ques son fo­ca­li­za­dos y per­so­na­li­za­dos, lo cual los ha­ce muy di­fí­ci­les de de­tec­tar. Fun­cio­nan co­mo un co­rreo per­so­na­li­za­do que es en­via­do a una per­so­na es­pe­ci­fi­ca den­tro de la or­ga­ni­za­ción, pa­ra que es­ta per­so­na re­ve­le da­tos que lue­go pue­den ser uti­li­za­dos pa­ra ac­ce­der a otros sis­te­mas.

Los ata­ques al sec­tor fi­nan­cie­ro son muy es­pe­cí­fi­cos y lle­gan a ser com­ple­jos, por lo cual es­tán pre­pa­ra­dos pa­ra una com­pa­ñía fi­nan­cie­ra y cam­bian de en­ti­dad en en­ti­dad.

In­can­sa­bles de bus­car la ma­ne­ra de lo­grar sus ob­je­ti­vos, los hac­kers tam­bién uti­li­zan una nue­va téc­ni­ca lla­ma­da wha­ling (ca­za ba­lle­nas) que se­gún Cam­pos, con­sis­te en di­ri­gir los ata­ques vía email a mer­ca­dos don­de se en­cuen­tra el per­so­nal de las em­pre­sas por­que es ahí don­de se en­cuen­tran fá­cil­men­te los ac­ce­sos de ad­mi­nis­tra­dor.

Pe­ro no so­lo el phis­hing es efec­ti­vo cuan­do se tra­ta de pro­pa­gar el malwa­re, los ata­can­tes tam­bién han en­con­tra­do en la po­pu­la­ri­dad de las re­des so­cia­les, una téc­ni­ca lla­ma­da scam, que con­sis­te en en­ga­ñar a los usua­rios con pu­bli­ca­cio­nes fal­sas pa­ra que ac­ce­dan a pá­gi­nas in­fec­ta­das y des­car­guen ar­chi­vos in­fec­ta­dos.

¿Có­mo se pro­te­ge la in­dus­tria?

Cons­cien­te de la as­tu­cia de los ata­can­tes, pro­fe­sio­na­les en se­gu­ri­dad co­mo Ci­lliam Cua­dra, CISO del Ban­co Na­cio­nal de Cos­ta Ri­ca, co­men­ta que en ge­ne­ral to­dos los ca­na­les de la en­ti­dad de­ben es­tar mo­ni­to­rea­dos in­te­gral­men­te cuan­do se tra­ta de ame­na­zas co­mo el malwa­re y que la for­ma de ope­ra­ción re­quie­re una ade­cua­da co­rre­la­ción de even­tos pa­ra la iden­ti­fi­ca­ción opor­tu­na.

“Es­te ti­po de ame­na­za re­quie­re el es­ta­ble­ci­mien­to de con­tro­les en las di­fe­ren­tes ca­pas de red, apli­ca­cio­nes y usua­rios fi­na­les. Las or­ga­ni­za­cio­nes de­ben sa­ber que sim­ples pie­zas de có­di­go ubi­ca­das en el lu­gar co­rrec­to pue­den te­ner un po­der de des­truc­ción muy im­por­tan­te – acon­se­jó el Chief In­for­ma­tion Se­cu­rity Of­fi­cer del Ban­co Na­cio­nal- pa­ra evi­tar es­pe­cí­fi­ca­men­te los erro­res de la ca­pa 8 den­tro de la ins­ti­tu­ción, se uti­li­zan he­rra­mien­tas pa­ra la de­tec­ción de pa­tro­nes de uso de re­cur­sos y com­por­ta­mien­tos de trá­fi­co que aler­tan de la exis­ten­cia de las ame­na­zas, los usua­rios de­ben ser sen­si­bi­li­za­dos so­bre la im­por­tan­cia de re­co­no­cer es­tas aler­tas”, aco­tó.

Newspapers in Spanish

Newspapers from Guatemala

© PressReader. All rights reserved.