0
0
No início de maio, a empresa de fitness Peloton anunciou que havia exposto os dados de contas de clientes na Internet. Qualquer pessoa pode acessar os dados da conta dos usuários dos servidores do Peloton, mesmo que os usuários definam seus perfis de conta como privados. A causa: uma API com defeito que permitia solicitações não autenticadas.
As interfaces de programação de aplicativos (APIs) permitem uma comunicação fácil de máquina para máquina. O uso de APIs teve um crescimento explosivo recentemente. De acordo com a Akamai, as comunicações API agora respondem por mais de 83% de todo o tráfego da Internet.
Eles também são a causa de muitos problemas de segurança. Além do Peloton, outras empresas noticiadas recentemente por problemas de segurança cibernética relacionados a APIs incluem Equifax, Instagram, Facebook, Amazon e PayPal.
Uso de API e ataques em crescimento
De acordo com um relatório divulgado em fevereiro pela Salt Security, 91% das empresas tiveram problemas de segurança no ano passado relacionados a APIs. As mais comuns foram vulnerabilidades, com 54% dos entrevistados, problemas de autenticação em 46%, bots em 20% e negação de serviço (DoS) em 19%.
Oitenta por cento das organizações não acreditam que suas ferramentas de segurança possam impedir ataques de API de maneira eficaz. A pesquisa da Salt Security descobriu que dois terços das organizações retardaram a implementação de um novo aplicativo em produção devido a preocupações relacionadas à segurança de API. Os clientes do Salt, todos com firewalls de aplicativos da web (WAFs) e gateways de API, passaram por vários ataques de API por mês, o que significa que os ataques de API estavam passando por essas ferramentas de segurança. Na verdade, de acordo com Salt, os WAFs e os gateways de API perdem 90% das 10 principais ameaças de segurança da API OWASP.
No entanto, mais de um quarto das organizações executam aplicativos essenciais baseados em API sem estratégia de segurança. Peloton, por exemplo, originalmente tornou os dados do usuário acessíveis por meio de APIs para qualquer pessoa, em qualquer lugar, sem qualquer autenticação, diz Tim Mackey, Estrategista de Segurança Principal do Synopsys Cybersecurity Research Center. “O primeiro passo que o Peloton deu para proteger sua API foi restringir o acesso aos assinantes, mas isso ainda significava que qualquer usuário poderia acessar os dados de qualquer outro usuário, independentemente das configurações de privacidade”, diz ele. “Dados que variam de idade e sexo do usuário, sua imagem de perfil e alguns dados de atividade estavam acessíveis”.
APIs com vazamento não são raras. De acordo com o relatório Salt Security, 82% das organizações não têm confiança em saber os detalhes da API, como se as APIs incluem informações de identificação pessoal (PII), como informações de rede proprietárias do cliente, informações de saúde protegidas e dados do titular do cartão, e 22% das organizações afirmam eles não têm como saber quais APIs expõem dados confidenciais.
O erro de Peloton foi usar APIs não autenticadas vulneráveis à autenticação de nível de objeto quebrada, diz Roshan Piyush, Engenheiro de Pesquisa de Segurança da Traceable. Outras empresas que enfrentaram o mesmo problema incluem Panera, Fiserv, LifeLock e Kay Jewelers, diz ele. “E a lista continua”. Geralmente, tudo se resume a uma proteção de autenticação e autorização negligenciada para as APIs no processo de desenvolvimento, diz ele.
É só o começo
Jeff Serota, Gerente de Tecnologia de Segurança Cibernética em uma instituição financeira de médio porte, diz que o uso de APIs por sua empresa cresceu dramaticamente nos últimos meses. Hoje, as APIs conectam cerca de 3.000 terminais, que incluem aplicativos internos e aqueles pertencentes a parceiros de negócios, bem como sites voltados para o cliente e dispositivos móveis.
Isso é só o começo, diz Serota. “Estamos há dois anos em um processo esperado de cinco anos e os próximos três serão uma rápida aceleração. Conseguimos um novo CISO há cerca de 16 meses, e ele vem do lado do desenvolvimento de API, então ele definitivamente aumentou essa velocidade”.
Até agora, diz ele, eles estiveram principalmente preparando o terreno. “Na verdade, estamos em um caminho agora em que estamos em um cronograma para eliminar todos os data centers locais e migrar para serviços da web e APIs para tudo”, diz Serota.
As chamadas de API passam por quatro URLs principais, diz Serota, com serviços diferentes, incluindo parâmetros diferentes em suas chamadas de API. Essa abordagem cria uma camada de proteção. “Com as APIs, devido ao quão arriscadas elas eram, nós realmente ofuscamos alguns de nossos nomes de endpoint de API para serem mais difíceis de fazer ataques transversais ou fazer descobertas”. A instituição também tem consolidado vários gateways de API em um gateway principal nos últimos seis meses.
Para o gateway de API, a empresa usa a Apigee, um fornecedor de segurança de API adquirido pelo Google em 2016. “Este é o gateway que você usará e é assim que será protegido”, diz Serota.
Algumas empresas tiveram problemas ao tentar integrar todos os desenvolvedores com um único gateway ou estavam preocupadas com possíveis gargalos, pontos únicos de falha ou ataques DDOS. Serota diz que não foi o caso da sua instituição. “Nossos desenvolvedores realmente preferem o método de gateway de API”, diz ele. “É baseado em SaaS e multirregional e, na verdade, oferece melhor disponibilidade e menor latência. Eles não têm as restrições de gateway que um gateway de API tradicional tem porque sabem que será escalonado automaticamente”.
Por exemplo, esperava-se que uma API registrasse 10 milhões de transações por mês, mas teve 200 milhões nas primeiras duas semanas após seu lançamento, diz Serota. “Eles não sentiram nenhuma latência ou degradação de desempenho”. Agora, o ambiente de produção vê cerca de 2 bilhões de chamadas de API por mês, diz ele, contra cerca de 800 milhões há dois anos.
Para autenticação, os aplicativos móveis e baseados na web da empresa usam uma tecnologia Java mais antiga, diz Serota, “mas estamos no processo de mudar tudo para uma autenticação baseada em API usando um kit de desenvolvimento de software. É uma parte importante da nossa transição agora e tem exigido muita colaboração de vários departamentos”.
A nova abordagem muda completamente a forma como a instituição busca ataques baseados em credenciais, diz Serota. Para parceiros externos, a empresa está buscando um modelo de confiança zero para suas chamadas de API. “Gostaríamos de acelerar, mas temos parceiros que ainda não estão prontos”.
Para os consumidores que acessam a instituição por meio de seus próprios aplicativos web ou mobile, haverá persistência. Isso significa que os consumidores não precisarão passar pelo processo de autenticação várias vezes. “Nossos modelos de confiança zero significam que não permitimos qualquer tipo de persistência de sessão, qualquer tipo de cookie-ing”, diz Serota. “Você deve se autenticar novamente todas as vezes. Eu volto à filosofia básica de que quando você quer seguro, conveniente ou rápido, você pode ter dois, mas não todos os três”.
Para APIs que ficam dentro do perímetro de segurança da empresa, há ainda outra abordagem. “Uma vez lá dentro, tendemos a usar outros métodos além da confiança zero, que são mais leves”, disse Serota. “Estamos usando segurança de IP, dependendo de onde está indo, contas de serviço para autenticação, fazendo coisas mais baseadas no Active Directory”.
A análise comportamental também está em vigor para detectar comportamentos suspeitos para tráfego externo e interno e filtros automáticos para as mensagens ruins óbvias. “Ser capaz de separar o joio do trigo na porta da frente nos permite olhar para as boas chamadas esperadas com mais intensidade”. A análise do comportamento também está nas transações reais. “Usamos tudo, desde reputação de IP até análise comportamental para o usuário e padronização de contas”, diz Serota. “Digamos que temos um usuário que recebe um depósito de US$ 200 todas as sextas-feiras e agora começa a depositar US$ 800 em cheques todas as quartas-feiras; começamos a olhar para isso. Não é apenas para proteger nossos ativos, mas para garantir que estamos relatando proativamente o que pode ser lavagem de dinheiro ou tráfico de pessoas”.
Usando a automação, a empresa conseguiu reduzir o número de problemas que chegam ao centro de operações de rede e à equipe de resposta a incidentes de segurança cibernética em 35%, diz Serota. “Menos falsos positivos estão chegando a eles”.
Para ajudar nisso, há pouco mais de um ano as equipes NOC e CSIRT implantaram o Salt Security, usado em fluxo compartilhado com o gateway de API da Apigee. “Ele vê todo o tráfego chegando às nossas APIs de nível superior e, em seguida, está aprendendo com elas, nos dando prováveis atacantes e recomendações sobre como melhorar nosso código”, diz Serota.
Outras equipes também adotaram a plataforma, incluindo a equipe de detecção de fraude, a equipe de desenvolvimento e a equipe de arquitetura de segurança. “Isso nos permitiu acelerar os cronogramas nas migrações de API”, diz Serota.
Ataques de bot em APIs
O tráfego de API está crescendo, mas o tráfego de API malicioso está crescendo mais rápido. O volume mensal de chamadas de API dos clientes da Salt Security cresceu 51%, enquanto a porcentagem de tráfego malicioso cresceu 211%.
Em uma análise da Akamai de um mês de dados de API de 100 clientes empresariais nos setores de serviços financeiros, varejo, mídia e entretenimento, a empresa encontrou 744 bilhões de chamadas de API, 12% das quais vieram de malfeitores conhecidos e 25% vieram de clientes finais que não eram navegadores da web nem dispositivos ou aplicativos móveis, o que significa que eles poderiam ter se originado com agentes mal-intencionados em vez de usuários legítimos.
Os aplicativos front-end tradicionais – sites e aplicativos móveis – possuem proteções contra invasores, diz Rishi Pande, Diretor-Gerente de Segurança Cibernética da Ernst & Young. Isso inclui defesas contra DDoS, enchimento de credenciais e outros ataques automatizados. “Seu front end pode estar protegido, mas se o gateway de API não estiver protegido, você pode transbordá-lo facilmente”, diz ele. O espaço está evoluindo rapidamente, com alguns clientes presumindo que sua tecnologia oferece proteção, mas as ferramentas em si não estão totalmente prontas.
O problema de enchimento de credenciais não desaparece apenas com APIs, diz Pande. “As pessoas ainda não resolveram esse problema”.
Na verdade, os ataques à camada API estão se tornando populares entre os hackers porque é mais anônimo e as APIs geralmente não são tão bem protegidas quanto sites e aplicativos móveis, diz Jason Kent, Hacker Residente na Cequence Security. Kent uma vez descobriu como abrir portas de garagem tirando vantagem de um problema de projeto com a API da empresa de portas de garagem. “Na segurança padrão de sites, há todo esse código extra que você pode executar no lado do cliente para saber se é um invasor ou uma pessoa real”, diz ele. “Em uma API, nos livramos de tudo isso. Facilitamos realmente um ataque acontecendo em alta velocidade com a frequência que você gostaria”.
Kent diz que a segurança da API hoje é sobre onde a segurança do aplicativo estava em 2009. A maneira como ele invadiu a API da porta da garagem foi olhando para seu aplicativo móvel. “O aplicativo que você baixa da app store é apenas um monte de pastas e arquivos compactados”, diz ele. “Ele contém um manifesto de todos os endpoints da API com os quais se comunicará”. Kent dá uma aula sobre como fazer isso para o OWASP.
Depois que os invasores desmontam um aplicativo móvel e descobrem como ele se comunica, eles podem usar o mesmo canal de API para enviar solicitações. A IA e o machine learning podem ajudar na defesa contra isso, diz ele, uma vez que as solicitações de API que vêm por meio de bots parecem diferentes daquelas que se originam com seres humanos reais usando aplicativos legítimos.
Hora de mudar de rumo
De acordo com o relatório “Postman’s 2020 State of the API”, que entrevistou mais de 13.500 desenvolvedores, apenas 36% das empresas fazem testes de segurança de suas APIs – em comparação com 70% que fazem testes funcionais e 67% que fazem testes de integração. De acordo com o relatório de estado da API de 2020 da SmartBear, a disponibilidade era a maior preocupação que os desenvolvedores tinham quando se tratava de suas APIs, seguida pela funcionalidade, com segurança em terceiro lugar.
Parte do problema é que as equipes de desenvolvimento geralmente são separadas das equipes de segurança, que são separadas das equipes de rede e infraestrutura. “A solução para os silos é DevSecOps”, disse Albert Whale, Gerente Sênior de Segurança Cibernética da Capgemini North America. “Agora podemos integrar os testes e dar esse controle aos desenvolvedores de aplicativos. Tornamos todos membros da equipe de segurança”.
Whale diz que criar aplicativos mais seguros desde o início é mais importante do que tentar proteger as coisas no final com tecnologias como gateways de API. “Eu vejo um gateway de API como um único ponto de falha”, diz ele. “Isso vai desacelerar o aplicativo porque ele precisa coletar todas as informações para canalizá-lo de volta. Isso não quer dizer que eles sejam terríveis, eles atendem às suas necessidades exatamente como um firewall de aplicativo da web faria, mas há momentos para usá-los e momentos para escalar além deles”.
Em vez disso, diz Whale, as empresas devem se concentrar em uma melhor arquitetura, melhor segurança e melhores chamadas de API. “Leva mais tempo para fazer isso, mas aplicativos melhor codificados são o que você precisa para melhor proteção. Quando você pode tornar um aplicativo robusto o suficiente para resistir a ataques, não precisa de outros elementos para fornecer segurança adicional.”
Os desenvolvedores estão começando a se tornar mais conscientes da segurança, concorda Mike Rothman, Analista e Presidente da Securosis, uma empresa de pesquisa de segurança cibernética. “Estamos vendo o DevSec para tentar fazer com que as pessoas colaborem”, diz ele. “Isso sempre acontece? Nem todas as vezes, mas estamos tentando quebrar muitos desses silos e quebrar as paredes e fazer as equipes trabalharem juntas”.
Quando se trata de segurança de API, existem várias áreas de vulnerabilidade, diz Rothman. Tudo começa com a lógica de negócios. “Este é um dos principais aspectos da segurança de aplicativos que não posso dizer que acertamos”. Com os aplicativos monolíticos sendo divididos em pequenos serviços conectados por APIs, o desafio de encontrar e mitigar problemas lógicos é ampliado. O aplicativo pode estar funcionando exatamente como foi projetado, o mecanismo de autenticação pode ser perfeitamente seguro, pode estar completamente livre de vulnerabilidades, mas se houver um problema na codificação, uma violação ainda poderá ocorrer.
Depois, há o conjunto padrão de vulnerabilidades a serem observadas. O OWASP API Top 10, lançado em 2019, não mudou nos últimos dois anos, diz Rothman. “Continuamos a ter os mesmos problemas continuamente”, diz ele. “Então, precisamos defender o ambiente em vários níveis – tecnologia de rede tradicional, tecnologia de segurança de aplicativo tradicional”.
Finalmente, as organizações precisam olhar para ferramentas, automação, tecnologias de varredura e monitoramento de telemetria porque não há pessoas suficientes para monitorar a segurança da API manualmente. “Temos que aproveitar o que temos e as pessoas não estão nisso”, diz Rothman. “Ter monitoramento para determinar como as APIs estão sendo chamadas e procurar comportamentos anômalos que possam indicar uso indevido”.
FONTE: CIO