Recently, more than 300,000 home and small-office (SOHO) routers have been compromised by hackers. If you are an UPC Netherlands subscriber, you have a big chance to be a victim of this kind of router takeover.
30 November 2013:
I discovered a vulnerability (CSRF or sea-surf) in the Cisco EPC3925 router. It is the router actually used by UPC Netherlands subscribers (www.upc.nl). I decided to keep the discovery private, in order to present it for the first time during a security conference. So the issue was submitted to the HackInTHeBox call for papers.
16 December 2013:
Jeroen, an information security consultant, published in the wild the same security issue about the Cisco EPC3925 router. He was the first one providing the exploit code to change username and password to administer the router itself.
3 March 2014:
BBC warns the world about more then 300,000 home routers have been hacked (http://www.bbc.com/news/technology-26417441).
Team Cymru (it is a Celtic word, pronounced kum-ree) is the white hat hackers team that discovered the security issue, reporting that router and firewall from the following vendors are vulnerable to the attack:
Other unnamed vendors
How safe is your router?
If you are an UPC Netherlands subscriber, it is highly probable you have a Cisco EPC3925 router, and it means that you may have been hacked too, and you are a happy owner of one of the 300,000 home routers reported by the BBC.
Hacking a router represents the deepest and almost perfect attack to your security:
it compromises the security of all the internet connections you could have at home: your computer, your mobile phone, your smart television.
it is difficult to discover: no antivirus or firewall can detect it.
The best way to compromise you privacy, is to change the DNS settings of your router. In this way all the internet connection are redirected and intercepted (man in the middle attack). Actually Cisco EPC3925 routers are vulnerable to a CSRF attack that allows the user to change any setting in the router (my first exploit code, was about the Wi-Fi password/network name). Including the DNS settings.
Exploiting the geographical distribution of a security issue.
It is really interesting how an attacker could easily use the previous information to carry out a wide scale attack in the Netherlands.
The exploit code to infect a router is just a link in a web page. If the user clicks the link, the router is compromised.
The exploit code just will work for a specific router (in this case the Cisco EPC3925), highly distributed in the Netherlands.
In order to increase the chances of success, the attacker just has to “infect” with the malicious link pages written in Dutch (Dutch forums, websites, mailing lists). Another way to localize the attack would be to use targeted media advertisement systems, like Google Adsense, or Facebook. Imagine a banner advertising a free subscription to a gym in your area, a free ticket for the Cinema, all targeted just for Dutch users.
Even better, using banners advertising discounts or offers for Dutch UPC subscribers will increase the attack effectiveness 🙂
You can contact me at: email@example.com
Albert Heijn is a Dutch supermarket chain, their share is about 30% of the market, so it is safe to assume there are about 2 million customers. Almost every customer uses a “bonus card” which is for free, therefore we can assume there are at least 1 million customers actually using it.
Bonus cards track all the items you buy, so that customers habits are stored in a database; is it actually safe the way this information is collected and stored? Is it possible to steal that information and, for example, get the list of the items the royal family bought last week?
It is really possible! At least Appie, the mobile application from Albert Heijn, is able to query that database, retrieving all the informations available about your past purchases; the idea is to create an account on the app, and after that you can link your Bonus Card with that account, providing the digits you can find on your card (it is an EAN 13).
The security risk behind this scheme is that somebody could reverse the protocol used by the Albert Heijn system to query the customers database, and to create an automatic testing penetration tool that, once an account is created, tries to link somebody else’s bonus card to this profile, stealing his personal informations (mainly the history of the past purchases). This is achievable with a brute force approach; in an EAN 13 the first 3 digits are fixed, and the last one is a checksum. This means that an attacker should just brute force a 9 digits numeric sequence, absolutely doable!
It is 2 step process: link a brand new bonus card number to an account and try to retrieve the past history of this card. If it fails, try with another bonus card number, if it succeeds, get this information and repeat the process with other card number.
The technical Jargon
The whole attack just involves the calling of 2 API entry points: STORE_CARD_NUMBER and the PRODUCTS_BOUGHT_BEFORE (of course after calling LOGIN_MEMBER).
The authentication process with the server is based on Basic Auth and Digest Auth. The digest is the only guard against somebody trying to abuse the system; it is calculated as the SHA1 of the URL concatenated with the optional data we are sending, the user ID and a constant string, dynamically generated in the client application. It took a few hours to reverse the whole process and write and android application able to authenticate properly with the server and query the system.
The whole process (including entry points, digest algorithms) is not public, but you can easily get it by reversing the Android or iPhone applications.
Is somebody already stealing this data? How long will it take till somebody realizes it is possible, and exploits the system using the steps described in this paper, in order to resell this precious kind of informations?
The current paper is based on Appie version 2.2.3; version 3 adds more features and options, probably increasing the attack surface and giving a potential attacker even more options. I am pretty sure the Royal Dutch Family is safe, but the privacy of their shopping list is taking a big risk 🙂
Snapchat case is the most recent example of a new kind of security threat that represents one of today’s bigger security risk. The attacker was able to reverse engineer the mobile application, to guess the behavior of the communication protocol with the server, and to find loopholes in its flow.
The diffusion of mobile applications, as an extension of a web service, has widened the attack surface: the brand new option is to reverse engineering the Mobile Application in order to attack the web service.
All the informations the attacker needs are enclosed in the Mobile Application; it is just a matter of how hard the developers tried to hide it.
Software reverse engineering can be done in 2 possible ways (assuming of course you do not have the source code of the application):
- Static Analysis, or Dead Listing Approach;
- Dynamic Analysis, or Live Approach;
The Dead Listing Approach was perfect back in the days, when the applications were small and simple, for example DOS or Z-80 application. Nowadays this approach fits perfectly to Mobile Applications; all the findings presented in this paper are the result of a very quick and basic static analysis. A better and deeper reversing of the code is possible proceeding further with a dynamic analysis (and will be the matter of a future paper).
This kind of analysis is used by crackers to hack the application itself; according to an Arxan research (State of Security in theApp Economy:“Mobile Apps Under Attack”) more than 90% of top paid mobile apps have been hacked. 92% of Top 100 paid apps for Apple iOS and 100% of Top 100 paid apps for Android were found to have been hacked.
In this paper we are exploring the possibilities offered by this kind of analysis in order to achieve a malicious attack against the web service that is behind the mobile application.
There are three possible targets we are going to hit:
reverse engineering the communication protocol with the server (the backend API entry points);
reversing the application authentication process (username/password used by the app to authenticate, local SSL certificate/password)
gathering as much reserved informations as possible from the code, that represents a threat for the target.
The research was based on 10 highly popular free apps for Android, built and distributed by Dutch companies. Among them, there are hotel reservation apps (Booking.com), Online Banking apps (ABN AMRO, ING, RABOBANK). As soon as I cannot publish details that could lead to malicious attacks, I will just summarize the results of this analysis. Some of the companies involved in this research will be contacted to be warned against a potential security issue.
Communication protocol: 8 application out of 10 do not hide at all the communication protocol entry points with the server. It is possible to reconstruct all the protocol flow, even if such protocol is not public.
Application authentication process: 4 out of 10 applications simply contain the unencrypted credential to authenticate with the server.
Sensible information: 8 applications out of 10 contain unencrypted API Keys, like Facebook, Twitter, Google Maps, Flurry Analytics, Google Analytics.
Protection against reverse engeneering: 10 application out of 10 did not use any advanced application protection techniques, like assets encryption or tamper detection.
In one case the reverse engineering allowed me to create in no time a “cloned” application, able to create new users, to login and to query the main database, exactly the same way the official application does. For an attacker this could lead to automate penetration testing tools, DOS attacks, and probably sensitive data theft.
Apparently the mobile application market is still in his youth; mobile app protection is not a strategic priority and there is not enough focus on protecting the integrity of mobile apps against tampering/reverse-engineering attacks. In the following months probably we will see many more attacks, similar to the Snapchat one, and this is probably the only way to let the industry focus more on this issue.
I was reading about Sir Richard Branson having a perfect reproduction of his head in ice, to offer to first class passengers of Virgin Airlines; while reading it I got really sorry for the people not rich enough to have his own face scanned with lasers, modelled by a team of 3D modellers, and then printed in ice. It was so sad that I decided to devote my life to the search of a solution for this problem.
After months of hard research, a lot of ice cubes melting on my desk to understand better the problem, I finally found out the solution.
As soon as possible I will release an app that makes possible to have an ice cube with your face modelled in it, starting from a picture of you.
Sir Richard Branson, I am really sorry for you but I really think everybody has the right to have his own face printed on an ice cube!
I’m just wondering if simply adding Beer-Lambert law and Fresnel’s reflections to my code I can get this kind of result in realtime:
Summing up and simplifying a lot, the Fresnel’s law says:
- if a surface is pointing at you (angle of incidence=0), the reflection is small (R=0) and the refraction is big (T=1-R).
- If the surface is pointing to the side of your viewpoint (angle of incidence=90deg), the reflection is big and the refraction is small.
This means a solid object like a sfere or a human face near they borders reflect more light than you can expect.
The effect is noticeable on human skin too, as you can see in this rendering from Halflife with only the fresnel component visible:
A transparent object like a mirror, if the inclination is near 90 deg, transmits less light the expected.
This means that this effect is noticeable mostly along the outline of an object, or anyway in small, limited areas.
Beer-Lambert law says the amount of light transmitted through a material diminishes exponentially according to the path length; in the case of jelly materials, small objects and smal objects, I suppose I should give higher priority implementing this law, I’m really sorry for you, Augustin-Jean Fresnel !
The shader code should be something like this:
vec3 Absorbance = MaterialColor * MaterialDensity * -MaterialDepth; //density from 0.0 to 1.0
vec3 Transmittance = Refraction * exp(Absorbance);
I look forward to implement it and make some screenshot to compare the result with and without Beer’s law.