Add links to metadata on malicious extension hit

[mallorybowes]

Right now, everything is just a big munge in the source file. I want to annotate the positive hits with the URL to information about the malicious extension since getting info directly from the Chrome Web Store will probably be futile. (Since those extensions have already been pulled.) Maybe look at a JSON feed here much like what haveibeenpwned uses through their API...

[mallorybowes]

Been doing a bit of thinking about this and I think I'm going to create a second file that will have the per-record metadata. I'm kinda liking the approach of having a file w/just the malicious extensions in it so ppl can use it for their purposes w/minimal pre-processing required. The second file will have the per-record metadata in it which will include date of discovery, date added to repo, source URL, article URL, contributor, and contribution method. If ppl can think of other data they'd like captured at this level, feel free to add to the list!

Thanks to @itnAAnti for the comment about Jamf inclusion (https://github.com/mallorybowes/chrome-mal-ids/issues/2#issuecomment-749053102). Def got me thinking about things to do over the Christmas break!

[tchad-rogers]

Thank you for this amazing resource, @mallorybowes !

Two thoughts:

• I agree that for many use-cases, having a file with just the IDs is useful, so retaining the current format makes sense. I suggest also listing the IDs as the first column of the metadata file. First, this makes the file stand-alone, you don't need to reference two files to get everything. Second, the extension ID (column 0) can easily be used as the unique key when importing it in to a database. You could also make the metadata file the source of truth, and write a small script that pulls out column 0 and creates current-list.csv, so you only have one place to manually update.
• I suggest adding Extension Name as a column in the metadata file. When an extension is removed from the Chrome Store, finding the name can be challenging. (In my case, as a sys admin, if I need to ask a user to manually remove an extension, it makes it much easier if I know the name to tell them to remove.)

[mallorybowes]

Absolutely great points. I've been putting off the go-back-and-match-the-extension step of the metadata creation since it'll be a pain. But ultimately, it might have some value for ppl so I'll dive into it over the Christmas break. (It was kinda different when it was just me and a friend who were the only ones using the resource... :-)

I'll 100% incorporate your suggestions and I'll ping you for a quick check of my work before the commit. Thanks again for the help!

[tchad-rogers]

If you create the metadata file, create the structure, and populate all of the IDs, we can collaborate on the metadata collection and chip away at it over time. Populating meta data for 580 IDs on your own is no way to spend the holiday! XD

[mallorybowes]

Eh... I gots nothing better to do... :-) Like everyone else, covids has me locked in my place and working on populating the metadata will prolly be the only thing that will get me out of bed, over to the computer, and to stop watching Alias for the 40th time... :-D

Will def take you up on the collaboration going forward. (Just fyi, I messaged the guys at https://github.com/danielmiessler/SecLists to see if they wanted to include the list in their product. I'll make a post if it's accepted...)

[mallorybowes]

Starting to think I should add a field for "reported malicious" for those extensions that are in a non-confirmed state. (See the latest Kaspersky alert and Great Suspender extension stories) The way I'm seeing it work is adding those extensions to the overall list but with the flag so scripts / processes can display a "This extension has been reported as malicious" so the user can take appropriate action.

[tchad-rogers]

That's a good idea. I have also added Great Suspender to my list and had a few users remove it, even though it's only probably malicious.

[mallorybowes]

If you create the metadata file, create the structure, and populate all of the IDs, we can collaborate on the metadata collection and chip away at it over time. Populating meta data for 580 IDs on your own is no way to spend the holiday! XD

Well, after a sizeable delay, the first draft of the list with the added metadata has been added to the repo. It was def a best effort and I triple-checked each entry so I'm hoping I didn't cross the streams and screw up a line or two. From here on out, I'll populate both lists: the list of just extension ids and the list with the metadata. (I may decide to rewrite the bash script to use the meta source but that will be put on the to-do list atm... :-)

Thanks for your patience and help on this and hopefully this will be useful for ppl!

[mallorybowes]

From here on out, I'll populate both lists: the list of just extension ids and the list with the metadata.

Also, for right now, I created two discrete fields for "Confirmed Malicious" and "Reported Malicious" along with an "Additional Sources" field. The "Confirmed Malicious" and "Reported Malicious" both use a boolean value for state and I know I could just have the one "Confirmed Malicious" field with a 1 for confirmed, 0 for reported. But to me right now, I'm kinda liking the actual distinction of someone actually reporting the extension and having a field to point to the additional info since some of these "reported" situations can last a few months before being confirmed, if ever. I mean, technically, if an extension is confirmed to be malicious, it didn't necessarily have to have been in a previous state of being reported malicious w/o confirmation. (I'm looking at the two test cases of the Kaspersky and Great Suspender situations to come up with these subtle distinctions.)

So, to me:

• "Confirmed Malicious" = researcher + some third-party has confirmed the behavior
• "Reported Malicious" = researcher has found malicious behavior but claim hasn't been validated by a third-party

Ultimately, I may be splitting hairs too fine here but it's an easy fix to go to a single boolean "Confirmed Malicious" field if that's what ppl think is the better way to go... :-)

[molangning]

Eh... I gots nothing better to do... :-) Like everyone else, covids has me locked in my place and working on populating the metadata will prolly be the only thing that will get me out of bed, over to the computer, and to stop watching Alias for the 40th time... :-D

Will def take you up on the collaboration going forward. (Just fyi, I messaged the guys at https://github.com/danielmiessler/SecLists to see if they wanted to include the list in their product. I'll make a post if it's accepted...)

I am now working on porting the lists to seclists, you can check it out here https://github.com/molangning/bad-web-extensions/tree/main