Showing posts with label tracking. Show all posts
Showing posts with label tracking. Show all posts

Monday, September 25, 2017

Tracking of potentially interesting data in a browser extension

Tracking of potentially interesting data in a browser extension


Intro

As noted in my last post, the next step is to identify potentially interesting data that the browser extension can track and analyze during a web browsing session. At this point, were not completely sure which data will be useful to us, so listed below are some of the potentially most interesting and useful things to track. A small Google Chrome extension is created as a proof of concept, which will be described as well as the Chrome extension architecture.


What to track

Network traffic

Since our goal is to write a IPS for the browser, tracking network traffic is obviously a requirement. During normal browsing, its possible to see the network requests in Chrome DevTools:

Chrome DevTools















Browser extensions can use the chrome.webRequest API to catch network requests. During the life 
cycle of a web request, several events are fired which we can use to analyze the traffic and decide what to do with the request. The event life cycle is shown in the image below:
Event life cycle in Chrome API

The granularity of those events enable us to, for example, catch and log the request between sending it to the remote server, and then analyze the response when it arrives. Or alternatively, if the requested domain is known to be malicious, the request can be denied completely. Logging every HTTP request made during browsing will be very useful for statistically analyzing the data later.

CPU and memory usage

Using experimental.systemInfo.cpu and chrome.experimental.processes its possible to track CPU and memory usage per process/tab. In the learning process, during normal browsing, extension will track the usage and try to establish the average CPU/memory usage as a baseline and will later compare the usage during browsing to that baseline.
The idea is that some malicious sites will try to max out the CPU and memory usage and cause the browser and/or system to be unresponsive, which the extension will detect as it would differ significantly compared to the baseline values. Special attention is needed to avoid identifyng CPU and memory usage spikes on regular websites as a potential malicious activity.

DOM (Document Object Model)

Tracking objects in the DOM is a tricky subject as the pages on the web differ significantly and there are many ways to attack the user.
Defending against clickjacking attacks is described in the article A Solution for the Automated Detection of Clickjacking Attacks. The idea is to track iframes on the page and when the user clicks on something, detect if there are overlapping clickable elements in the location of the click, suggesting potentially malicious transparent element in the iframe, as shown on the image below:

Clickjacking attempt against Twitter

Chrome extensions architecture

Extensions overview

A Chrome extension is a zipped bundle of HTML, CSS and Javascript files that add functionality to the browser. Extensions are basically web pages and as such, they can use the APIs that browsers provide to web pages, in addition to Chrome APIs made for use in extensions.

Many extensions have a background page, an invisible page that holds the main logic of the extension. An extension can also contain other pages that present the extensions UI. If the UI is needed, it can be presented as a browser action (shown on all pages) or page action (shown only on some pages, depending on a page). The following image shows the architecture of an extension with a browser action:
Browser action architecture


The HTML pages inside an extension have complete access to each others DOMs, and they can invoke functions on each other. In the background page, we can use any of the chome.* APIs, but if we need to interact with the page currently loaded in the browser, to read and change the DOM, we need to use content scripts.

Content scripts

A content script is some JavaScript that executes in the context of a page thats been loaded into the browser. It behaves more like a part of the loaded page than a part of the extension. They can access and change the web pages the user visits, but cannot modify the DOM of its parent extension background page. This increases security as the malicious web page cannot use the extensions content script to attack the extension.

But the content scripts arent completely cut off from the extension. They can communicate with the extension by sending messages using the chrome.runtime.sendMessage API call. The architecture is shown here:

Content script architecture


Its also important to note that content scripts are run in a special environment called an isolated world. They have access to the DOM of the page they are injected into, but not to any JavaScript variables or functions created by the page. Basically, the content script cant access the javascript code running on the page, and the same is in reverse - javascript code on the page cannot interfere with the content script. This is shown here:

Content script isolation

While this protects our extension against malicious web pages, it also limits what we can do. To get around that, we can either set up event listeners which will intercept events on the loaded page, or inject a javascript script directly to the page. The latter method is insecure and shouldnt be used for communicating with the extension.

Extension proof of concept

This simple extension tracks the CPU usage of the browser and shows it to the user when the browser action button is clicked. Also, it has a configuration page where the user can configure how often will the data be saved and whether or not the saving is enabled.
The extension consists of:
  1. browser action - popup page that is shown the the extension button is clicked and dsplays the cpu usage to the user
  2. background page - it handles getting the CPU data from the chrome API and saves the data to localStorage
  3. options page - shows the configuration options to the user

On the next image, the popup and options page are shown: 


The next step is adding new functionality to the extension such as adding a content script to track DOM data and adding more configuration parameters to the options page.

Heres the link to my Github repository containing the work-in-progress extension: IPS Extension


download file now

Read more »
Posted by at
Labels: , , , , , , , ,

Sunday, September 17, 2017

Tracking Down Credit Card Dumps

Tracking Down Credit Card Dumps


I have been examining numerous computers and media cards to support fraud investigations in the past year.  One group of thieves has been installing skimmers (devices that record magnetic stripe data) in the magnetic stripe readers on doors of certain banking institutions that limit access to their ATMs after hours.  Then the thieves install micro video cameras in the light fixtures of the ATMs to capture the users pin codes.  The thieves later match the recorded pin code to the skimmed account number at the door, encode new cards, and pillage bank accounts by getting cash at another ATM location.

It is not difficult to find the ATM videos on the media cards from the cameras or on the computer hard drives.  The credit card/ATM card numbers can be bit tougher, however.  Searching for 16 digit numbers in a Windows computer will yield a huge volume of false hits.  And, if the operation has been running for a while, many of the account numbers will be deleted.   Searching unallocated space is necessary to be thorough and to ensure your suspects get the full reward of their illicit activities.

All of the skimmers I have encountered are serial devices that communicate with software made for Windows-based computers by means of a USB-to-serial cable.  The cables do not look dramatically different than a standard USB cable, but they contain a chip that bridges the two protocols.  In a Windows computer, a USB driver for the cable must be installed before the program can communicate with the device.

The applications that communicate with the skimmer devices write the data to disk differently--some create a database while others use text files.  In my experience, both formats contain the complete track 1 and/or track 2 data.  Magnetic stripes contain three tracks, the first two in common use and encoded with particular standards.

Track 1 (IATA)

Track 1, known as "International Air Transport Association" format, has alphanumeric data.  It takes on the following format (from wikipedia):

Track 1, Format B:
  • Start sentinel � one character (generally %)
  • Format code="B" � one character (alpha only)
  • Primary account number (PAN) � up to 19 characters. Usually, but not always, matches the credit card number printed on the front of the card.
  • Field Separator � one character (generally ^)
  • Name � two to 26 characters
  • Field Separator � one character (generally ^)
  • Expiration date � four characters in the form YYMM.
  • Service code � three characters
  • Discretionary data � may include Pin Verification Key Indicator (PVKI, 1 character), PIN Verification Value (PVV, 4 characters), Card Verification Value or Card Verification Code (CVV or CVK, 3 characters)
  • End sentinel � one character (generally ?)
  • Longitudinal redundancy check (LRC) � it is one character and a validity character calculated from other data on the track. Most reader devices do not return this value when the card is swiped to the presentation layer, and use it only to verify the input internally to the reader.
Targeting track 1 data in a grep search is very simple:
$ grep -E ^%.[0-9]{16,19}^ file


Track 2 (ABA)

Track 2, known as the "American Banking Association" format, contains only numeric data.  It takes on the following format (from wikipedia):

Track 2: This format was developed by the banking industry (ABA). This track is written with a 5-bit scheme (4 data bits + 1 parity), which allows for sixteen possible characters, which are the numbers 0-9, plus the six characters  : ; < = > ? . The selection of six punctuation symbols may seem odd, but in fact the sixteen codes simply map to the ASCII range 0x30 through 0x3f, which defines ten digit characters plus those six symbols. The data format is as follows:
  • Start sentinel � one character (generally ;)
  • Primary account number (PAN) � up to 19 characters. Usually, but not always, matches the credit card number printed on the front of the card.
  • Separator � one char (generally =)
  • Expiration date � four characters in the form YYMM.
  • Service code � three digits. The first digit specifies the interchange rules, the second specifies authorisation processing and the third specifies the range of services
  • Discretionary data � as in track one
  • End sentinel � one character (generally ?)
  • Longitudinal redundancy check (LRC) � it is one character and a validity character calculated from other data on the track. Most reader devices do not return this value when the card is swiped to the presentation layer, and use it only to verify the input internally to the reader.
Targeting track 2 data in a grep search is also straight forward, though a reading of the above standard suggests the following search can miss.  I havent seen any different start sentinels or separators than those in the expression:
$ grep -E ^;[0-9]{16,19}= file
Though the preceding search has worked for me, the specifications for track 2 allow for other start sentinels and field separators.  A better but slower search would be:
$ grep -e ^[:;<=>?][0-9]{16,19}[:;<=>?]

Tracking Down Both Tracks at Once

I composed the following search to track down both tracks, and display the date and time of the swipe typically captured by the skimmer device.  The "-B1" argument shows one line of data before the hit, which is where the date and time are recorded.
$ grep -E -B1 ^%.[0-9]{16,19}^|;[0-9]{16,19}= file
You may have noticed the caret ("^") preceding the single quoted search in each of the grep expressions.  It requires the expression to be matched at the beginning of a line of data.  This is a search optimization.  I will now demonstrate two additional optimizations, one for searching allocated files, and the other for unallocated space (using the the sleuthkit tool "blkls"):
Searching mounted file systems (find files, export 7-bit strings, grep for track data):
$ find . -type f | while read i; do strings "$i" |  grep -E -B1 -H --label="$i" ^%.[0-9]{16,19}^|;[0-9]{16,19}=; done
Searching unallocated space of a forensic image (export unallocated, filter out 7-bit strings showing offset, grep for track data)
$ blkls -o63 image.dd | strings -td  |  grep -E -B1 ^%.[0-9]{16,19}^|;[0-9]{16,19}=


download file now

Read more »
Posted by at
Labels: , , , ,

Thursday, September 14, 2017

Google Apps Script Tracking add on usage with Google Analytics

Google Apps Script Tracking add on usage with Google Analytics


The following was originally published on the Google Developers Blog.

Editors note: Posted by Romain Vialard, a Google Developer Expert and developer of Yet Another Mail Merge, a Google Sheets add-on.

Google Apps Script makes it easy to create and publish add-ons for Google Sheets, Docs, and Forms. There are now hundreds of add-ons available and many are reaching hundreds of thousands of users. Google Analytics is one of the best tools to learn what keeps those users engaged and what should be improved to make an add-on more successful.

Cookies and User Identification

Add-ons run inside Google Sheets, Docs, and Forms where they can display content in dialogs or sidebars. These custom interfaces are served by the Apps Script HTML service, which offers client-side HTML, CSS, and JS with a few limitations.

Among those limitations, cookies aren�t persistent. The Google Analytics cookie will be recreated each time a user re-opens your dialog or sidebar, with a new client ID every time. So, Analytics will see each new session as if initiated by a new user, meaning the number of sessions and number of users should be very similar.

Fortunately, it�s possible to use localStorage to store the client ID � a better way to persist user information instead of cookies. After this change, your user metrics should be far more accurate.

Add-ons can also run via triggers, executing code at a recurring interval or when a user performs an action like opening a document or responding to a Google Form. In those cases, there�s no dialog or sidebar, so you should use the Google Analytics Measurement Protocol (see policies on the use of this service) to send  user interaction data directly to Google Analytics servers via the UrlFetch service in Google Apps Script.

A Client ID is also required in that case, so I recommend using the Apps Script User properties service. Most examples on the web show how to generate a unique Client ID for every call to Analytics but this won�t give you an accurate user count.

You can also send the client ID generated on client side to the server so as to use the same client ID for both client and server calls to Analytics, but at this stage, it is best to rely on the optional User ID in Google Analytics. While the client ID represents a client / device, the User ID is unique to each user and can easily be used in add-ons as users are authenticated. You can generate a User ID on the server side, store it among the user properties, and reuse it for every call to Analytics (both on the client and the server side). 

Custom Dimensions & Metrics
In add-ons, we usually rely on event tracking and not page views. It is possible to add different parameters on each event thanks to categories, actions, labels and value, but it�s also possible to add much more info by using custom dimensions & metrics.

For example, the Yet Another Mail Merge add-on is mostly used to send emails, and we have added many custom dimensions to better understand how it is used. For each new campaign (batch of emails sent), we record data linked to the user (e.g. free or paying customer, gmail.com or Google for Work / EDU user) and data linked to the campaign (e.g. email size, email tracking activated or not). You can then reuse those custom dimensions inside custom reports & dashboards.

Click for full-size version
Once you begin to leverage all that, you can get very insightful data. Until October 2015, Yet Another Mail Merge let you send up to 100 emails per day for free. But we�ve discovered with Analytics that most people sending more than 50 emails in one campaign were actually sending 100 emails - all the free quota they could get - but we failed to motivate them to switch to our paid plan.

Click for full-size version

As a result of this insight, we have reduced this free plan to 50 emails/day and at the same time introduced a referral program, letting users get more quota for free (they still don�t pay but they invite more users so it�s interesting for us). With this change, we have greatly improved our revenue and scaled user growth.

Or course, we also use Google Analytics to track the efficiency of our referral program.

To help you get started in giving you more insight into your add-ons, below are some relevant pages from our documentation on the tools described in this post. We hope this information will help your apps become more successful:
  • Google Analytics: Using localStorage to store the client ID
  • Google Analytics: Measurement Protocol
  • Apps Script: UrlFetch service
  • Apps Script: Properties service
  • Google Analytics: User ID
  • Google Analytics: About Events tracking
  • Google Analytics: Custom Dimensions & Metrics
Posted by Romain Vialard, Google Developer Expert. After some years spent as a Google Apps consultant, he is now focused on products for Google Apps users, including add-ons such as Yet Another Mail Merge and Form Publisher.


download file now

Read more »
Posted by at
Labels: , , , , , , , ,
Subscribe to: Posts (Atom)