Un fallo en la aplicación Meta Muse AI permite que un malware local redirija el tráfico de dictado

Meta hizo mucho hin­ca­pié en la se­gu­ri­dad de su apli­ca­ción de asis­ten­te de IA, Muse, en su lan­za­mien­to a prin­ci­pios de este mes, des­ta­can­do que la apli­ca­ción se basa en Muse Se­cu­re VM. «Cada per­so­na man­tie­ne el con­trol sobre su Muse y de­ci­de qué nivel de ac­ce­so le con­ce­de», de­cla­ró la em­pre­sa pu­bli­ci­ta­ria, ha­cién­do­se eco de an­te­rio­res afir­ma­cio­nes gran­di­lo­cuen­tes sobre la pri­va­ci­dad de su ne­go­cio de re­co­pi­la­ción de datos. Sin em­bar­go, las afir­ma­cio­nes de Meta sobre Muse pa­re­cen un poco exa­ge­ra­das: un ata­can­te capaz de eje­cu­tar có­di­go local po­dría ob­te­ner más ac­ce­so del que un usua­rio de Muse ca­bría es­pe­rar. El in­ves­ti­ga­dor de se­gu­ri­dad Pa­trick Ward­le, fun­da­dor de la or­ga­ni­za­ción sin ánimo de lucro Ob­jec­ti­ve-See, ha idea­do una prue­ba de con­cep­to de­no­mi­na­da «not-a-mused» para lo que des­cri­be como una vul­ne­ra­bi­li­dad local de día cero en la apli­ca­ción Muse para macOS, que per­mi­te a un pro­ce­so local sin pri­vi­le­gios re­di­ri­gir el trá­fi­co de dic­ta­do de Muse y, po­ten­cial­men­te, abu­sar del ac­ce­so con­ce­di­do a la apli­ca­ción. Muse, ex­pli­ca en el re­po­si­to­rio del pro­yec­to, cuen­ta con una con­fi­gu­ra­ción no do­cu­men­ta­da de­no­mi­na­da «endo_vo­ya­ger_dic­ta­tion_end­point» que un ata­can­te que eje­cu­te có­di­go lo­cal­men­te puede mo­di­fi­car sin pri­vi­le­gios es­pe­cia­les para re­di­ri­gir el trá­fi­co de dic­ta­do a un punto final con­tro­la­do por el ata­can­te, lo que po­dría ex­po­ner el audio dic­ta­do y las in­di­ca­cio­nes en­via­das al mo­de­lo de IA del bac­kend. La falla po­dría per­mi­tir la in­yec­ción de in­di­ca­cio­nes, el robo de ma­te­rial de au­ten­ti­ca­ción y el abuso de cual­quier ac­ce­so que el usua­rio haya con­ce­di­do a Muse. La vul­ne­ra­bi­li­dad no su­po­ne un pro­ble­ma para un ata­can­te re­mo­to, ya que re­quie­re la ca­pa­ci­dad de eje­cu­tar có­di­go local. Por lo tanto, la prin­ci­pal preo­cu­pa­ción, según Ward­le, es que la vul­ne­ra­bi­li­dad otor­ga al malwa­re local un ac­ce­so mucho más am­plio del que ten­dría en otras cir­cuns­tan­cias. En esen­cia, se trata de una vul­ne­ra­bi­li­dad de es­ca­la­da de pri­vi­le­gios. En una en­tre­vis­ta te­le­fó­ni­ca con The Re­gis­ter, Ward­le com­pa­ró la si­tua­ción con vivir en un blo­que de pisos. «El hecho de que se mude un mal ve­cino no sig­ni­fi­ca que ese ve­cino tenga au­to­má­ti­ca­men­te ac­ce­so a todos los pisos», afir­mó. Apple, se­ña­ló Ward­le, ha hecho un tra­ba­jo real­men­te bueno con su marco de «Trans­pa­ren­cia, Con­sen­ti­mien­to y Con­trol» (TCC), que ges­tio­na el ac­ce­so a datos sen­si­bles en macOS, y con la se­pa­ra­ción de pri­vi­le­gios. Pero lo que le preo­cu­pa es que las apli­ca­cio­nes de IA elu­dan estas ba­rre­ras, ya que so­li­ci­tan o re­quie­ren un ac­ce­so ex­ce­si­vo a los datos y a las he­rra­mien­tas. Sobre las apli­ca­cio­nes de IA, afir­mó: «Son muy prác­ti­cas y te dan mucha au­to­no­mía. Pero tie­nen un ac­ce­so enor­me si las con­fi­gu­ras para que sean úti­les. Bá­si­ca­men­te, po­drían hacer cual­quier cosa en tu or­de­na­dor». Por ello, se­ña­ló, se con­vier­ten po­ten­cial­men­te en un único punto de fallo que rompe los con­tro­les de se­gu­ri­dad del sis­te­ma ope­ra­ti­vo. «Sabes que estas em­pre­sas de IA tie­nen mo­de­los de IA real­men­te ex­ce­len­tes para de­tec­tar erro­res», dijo Ward­le. «¿No los están eje­cu­tan­do con­tra [sus pro­pias apli­ca­cio­nes]? ¿Acaso la prio­ri­dad no es la se­gu­ri­dad de sus pro­pias apli­ca­cio­nes?». Ward­le se­ña­ló que el soft­wa­re de de­tec­ción y res­pues­ta en ter­mi­na­les (EDR) ha me­jo­ra­do en macOS en gran me­di­da por­que todo lleva firma di­gi­tal, por lo que es fácil iden­ti­fi­car los pro­ce­sos que no están cer­ti­fi­ca­dos y a los que no se de­be­ría per­mi­tir eje­cu­tar­se. Pero cuan­do a los agen­tes de IA se les con­ce­den am­plios per­mi­sos y ac­ce­so, el pro­duc­to EDR no puede dis­tin­guir si los co­man­dos pro­vie­nen del usua­rio, de un agen­te o de un ata­can­te. Estos agen­tes ne­ce­si­tan ac­ce­so, se­ña­ló Ward­le, para poder ser úti­les a los usua­rios. Lo que les falta a los crea­do­res de apli­ca­cio­nes de IA, se­ña­ló, es un sen­ti­do de la res­pon­sa­bi­li­dad res­pec­to al nivel de ac­ce­so que so­li­ci­tan sus apli­ca­cio­nes. Ward­le aña­dió que Apple ofre­ce un ser­vi­cio de dic­ta­do local en el pro­pio dis­po­si­ti­vo y que, si Meta hu­bie­ra op­ta­do por uti­li­zar esa API, esta vul­ne­ra­bi­li­dad no exis­ti­ría. En cam­bio, su­gi­rió, Meta optó por no uti­li­zar el ser­vi­cio de Apple, pre­su­mi­ble­men­te por­que quie­re ac­ce­der a esos datos. «Creo que, en cier­ta me­di­da, su ava­ri­cia por los datos de los usua­rios abre la puer­ta y crea una su­per­fi­cie de ata­que mayor», afir­mó. «Pero, al fin y al cabo, estas em­pre­sas de IA com­pi­ten por lo que ven­drá des­pués. La pri­va­ci­dad y la se­gu­ri­dad de los usua­rios no son sus prio­ri­da­des». Meta no res­pon­dió de in­me­dia­to a una so­li­ci­tud de co­men­ta­rios.®…