The Case of Pipka & Magecart
This article is for non-techies. If you are a programmer then most probably you will find this kid's stuff. But some of the concepts here could be eye openers even for seasoned programmers, not used to working with malware.
Secondly this article is limited to "skimmers" …malware that steal sensitive info and send it to the bad guys. Hence no talk on other malware like viruses, worms, trojans..or whatever fancy name you may dream of. Furthermore, I will try to make this light reading and promise…."No High Funda Stuff" .
After the first article you must wondering .. who's Magecart ? Has Pipka got a new friend ? or hooked up with Magecart ?. "Hooking" is going to be a very hot and relevant topic for our defense against skimmers.
So, without much ado, let's introduce
The Cast
Programmers are a breed that like to use big words and confuse people. Let's consider this term .."API (Application Program Interface) or Call-Gate ". On the net you will find this defined as
An application program interface (API) is a set of routines, protocols, and tools for building software applications.
We use interfaces everyday. Interfaces provide services. A remote to flip TV channels is an example. To change channels one uses the remote. If you tried to change channels by opening the back panel of the TV and poking in a metal screw driver with the power on, it would be quite a “Shocking” experience in more ways than one :). A remote therefore is an interface to get a service done.
A gate in a wall acting as an entrance to a cottage is an interface..it's there as a silent service to help you get into the cottage . You don't jump over the cottage wall because the owner's guard dog is sitting on the other side, just waiting for acrobats like you and might fancy sharpening his/her teeth while welcoming you :) . This example of a gate is interesting because the diagrams that follow look exactly like a wall with a gate.. hence this example. Incidentally, programmers familiar with machine/assembly level programming would find the term call-gate more familiar.
Browsers too, have hundreds of APIs / interfaces/gates . The one that concerns us most is the Network API which gets and sends data elsewhere..(Donald Duck or our Postman in the cast above) … Why ?. The reason is skimmers after obtaining card info need to transmit it to the bad guys. Without any network the skimmer is useless.. hence this API in particular is of maximum interest here. To be more precise, the address or URL to which data is being sent is of interest here and not the act of transmission itself.
You must be wondering why we are talking so much about APIs or Gates. The reason is these API(s) are like the "Jewels in the Crown" and need to be protected. This is where interesting things happen !.
So, let's forget about malware for a moment and consider a " Normal, No Malware , All good" web form. Below is a user submitting credit card details to a URL of the card company. The submit button is internally programmed by the site developer to call a browser internal network interface that in turn uses the browser internal postman as shown below after passing the wall or gate.
Now, moving ahead lets see what happens when a malware like Pipka or Magecart is introduced into the web page. As noted in my earlier article, malware is introduced into the webpage through some means, usually by the malware coder having unauthorised or hacked access to the target website.
Pipka and Magecart are relatively simple skimmers, no fancy stuff. When they steal card details it's as simple as it gets. They use the same API shown above and here is how they work.
The user fills in the card details and hits submit. Two things now happen. The first is the same as the "No malware page shown above" .. the details get submitted as before ( see prev. pic). However in addition to that Pipka and Magecart make a copy of the card details and send it via the network API as before but now Note.. to a site operated and controlled by the malware creator..bad guy's URL . Of course details are missing but essentially that's what happens. The user of couse is unaware of all this as everything seems normal..its all under the hood so to say.
To defend against simple malware like the one above we need to protect our Postman or Network API in some way. Here again programmers use fancy terms and the one we want is "Hooking ".
What exactly is Hooking ?
If you consider the earlier example of the cottage gate, then, hooking is like building an outer wall around the first wall and keeping someone in the middle to check things out… a wall enclosing another wall with someone in between. This new guy sitting between the two walls is called the "Hooker", a Proxy so to say. So, a new visitor to the cottage now first sees the outer wall and the Hooker sitting there. The visitor has no way of getting to the original gate except via the Hooker. The Hooker looks at the visitor and can now decide whether to let him/her through or reject and turn him/her back !
If you look closely at what we have done above, we have really build a protection layer around the original browser network API. Now, all the Hooker additionally needs is a list of allowable URLs, a Whitelist of addresses and can thereafter allow or block them during runtime.
Network Hooker : Defending against Pipka and Magecart …
Here is how it works.
So, after we make the above changes , looking at the above figure, we have our Big Blue Cop , the Hooker installed , the guy is up and active, guarding our API, diverting URL traffic as needed and blocking the malware network calls.... so what's next ? .
Should we get ourselves a beer and chill out ?
… For this moment..yes but not for too long….. Why ?
Let's look at the lyrics of the song by
The BEATLES !
The song is "Yesterday"
The lyrics go as
Yesterday, all my troubles seemed so far away
Now it looks as though they’re here to stay.
Yes, yesterday we malware defense gurus developed this fat blue cop called Hooker ( see the previous pic) who decided which URL's to pass and which to stop.. correct ? And Pipka and Magecart got blocked…with him our troubles went away…Great, but that was Yesterday !
What about Today or Now ? As the lyrics go .. our troubles look as though they're here to stay… Why ? Malware creators / writers are not fools. They were not born yesterday. They study yesterday's malware and yesterday's defense strategies and come up with new ones just to bypass the older guys.
Malware creation and Malware defense is like playing a never ending game of Chess. There is only a current winner who is the last survivor at that moment in time when one is looking. This means that any defense can be broken and any offense can be stopped and this cycle never ceases, the next one always getting the better of the previous !
So, lets see how a malware can be designed to bypass our Big Blue Hooker Cop and what's required. Let's now wear the "Bad Guy's Hat" and call this
The case of the Two Hookers
So, with the new hat , I'm Mr. Bad Guy and my thinking is as follows.
I know Mr. Hooker Cop is sitting there waiting to catch those bad URLs. However, if I ( the malware) could get in "First, before the Hooker Cop" then I would have direct access to the Postman (Donald Duck) .
The figure below illustrates this..
The malware hooker has direct access to Donald Duck because it hooked first (built the first wall..right hand side) before the cop hooker. The card company URL (blue arrow) starts at the user and first goes through the cop which sees that it's ok and hence passes it down the line.. The cop has no idea who is the receiver down the line (good or bad ? ) because hookers can hook other hookers for valid reasons as well.
Of course, if one takes the stand that a Cop Hooker must check and refuse to be a second hooker ( hooker of a hooker ) then this check is possible as follows…. simply console.log the object API and check to see if a [Native Code] string pops out. However, many libraries install hooks to provide additional functionality, so even though this check works it's not a good idea to implement in real life because its unreasonably restrictive !
A Defense Strategy
Defending against script and hooker based malware assumes that the script and hooker based malware is on the Javascript side which is true for this article's assumptions.
Since Hookers can Hook Hookers etc the best form of defense is
a) Use a hooker that is not affected by its position in the hooker chain. This can easily be done with a Hosted browser. Android webviews offer native side (Java) APIs to intercept all URLs called by a web page…in a position independent way ! because they are on the native Java side.
See the figure below and specifically the box entitled “Webview Native side Hooker. Do checks here ”. If the URL check is made on the Native side after Donald Duck, the postman, ( or before but still native side ..browser internals dependent..it does not matter which), then, there is no way for any Javascript side hooker on the web page to interefere with the checks because there is no direct access.
b) Get a White-listed set of URLs. This is easy if a site is not using 3rd party libraries. But if the site imports 3rd party libraries and those in turn import others then this list could grow. So assuming you have an un-infected set of these libraries and build your list from there ( version dependent) then if a malware strikes in the future, any additional unknown URL will be easy to catch. Of course this list itself has to be incorporated into the website checks as well.
c) The downside of b) is that false alarms can easily be generated if 3rd party libraries change versions or genuinely import newer libraries via newer URLs.
Nobody said that this defense is perfect, but, it's definitely better than nothing ! And if implemented correctly it's very effective. Furthermore the lyrics of "Yesterday" should always be kept in mind..
You are only smart until someone smarter than you comes along and blows your strategy up… which is just a matter of time !.. a nice comforting thought I would think :) .
An Implementation of the above strategy.
Here it starts getting a bit technical. We saw that we need to do URL checks on the native side or browser internals side and not on the webpage javascript because there was a problem of " who hooks first " .
Developers who have used the Chrome browser are well aware of the Developer Tools menu which has a network tab. If activated that shows a list of all URLs that are being loaded. But the problem here is this.. we can see the list but how do we programatically use that info. It cannot be done manually .. of course it would work but it would be crazy to even try that.
Another possible way is using a browser automation framework like Selenium. However, we need a separate app housing the automation code for this to work. With this strategy you can pull out the network tab list of loaded URLs from any browser and programatically do whatever … an ugly solution because of the two app ( browser and automation app) approach. Also, this approach will only work on a desktops.
Let's look at something that will work on both mobiles and desktops. This is done using a Hosted browser.
A Hosted browser is nothing but a fancy name for a regular browser but without the frame. In Android we have browser components called WebViews which we can embed into our own app. As the web page loads the embedded browser component sends the URL to its container … which is really our app waiting for this. This is all we really need. Once we get this URL list we can do whatever. To be really flexible we can also source the URL whitelist from outside which is easily done by adding another webview or browser component.
So without modifying any existing webpages we can check any URL without having to worry about …who is the faster Hooker.
Here is a video of a "Proof of Concept App" for Android mobiles that can do URL checking.
So, till we meet again…. Adios
References / Links:
The first article below has some code and links which techies may want to check out.
Chrome Debugging
Image Credits: For the smileys and the FAB FOUR, the Beatles( personal and non-commercial use)
