Mbinu za Pentesting za Browser Extension

Tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Jifunze na fanya mazoezi ya Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks

Taarifa Za Msingi

Browser extensions zimeandikwa kwa JavaScript na zinapakiwa na browser kwa background. Zina DOM yao lakini zinaweza kuingiliana na DOM za tovuti nyingine. Hii inamaanisha zinaweza kuhatarisha usiri, uadilifu, na upatikanaji (CIA) wa tovuti nyingine.

Vipengele Vikuu

Extension layouts zinaonekana vizuri inapobonyezwa na zinajumuisha vipengele vitatu. Tuchunguze kila kipengele kwa undani.

http://webblaze.cs.berkeley.edu/papers/Extensions.pdf

Content Scripts

Kila content script ina ufikiaji wa moja kwa moja kwa DOM ya ukurasa mmoja wa wavuti na kwa hivyo inakabiliwa na ingozi inayoweza kuwa ya uharibifu. Hata hivyo, content script haina ruhusa nyingine isipokuwa uwezo wa kutuma ujumbe kwa extension core.

Extension Core

Extension core ina mengi ya vibali/ufikiaji wa extension, lakini extension core inaweza kuingiliana na maudhui ya wavuti tu kupitia XMLHttpRequest na content scripts. Pia, extension core haina ufikiaji wa moja kwa moja kwa host machine.

Native Binary

Extension inaruhusu native binary ambayo inaweza kufikia host machine kwa vibali kamili vya mtumiaji. Native binary inafanya muingiliano na extension core kupitia Netscape Plugin Application Programming Interface ya kawaida (NPAPI) iliyotumiwa na Flash na plug-ins nyingine za browser.

Mipaka

Caution

Ili kupata vibali kamili vya mtumiaji, mshambuliaji lazima amshawishi extension ipitishe malicious input kutoka content script kwenda extension’s core na kutoka extension’s core kwenda native binary.

Kila kipengele cha extension kimegawanywa kutoka kwa kila kimoja kwa mipaka thabiti ya ulinzi. Kila kipengele kinaendesha katika mchakato tofauti wa operating system. Content scripts na extension cores zinaendesha katika sandbox processes ambazo hazipatikani kwa huduma nyingi za operating system.

Zaidi ya hayo, content scripts zinatenganishwa na kurasa za wavuti wanazohusishwa nazo kwa kuendesha katika JavaScript heap tofauti. Content script na ukurasa wa wavuti wana ufikiaji wa DOM moja ya msingi, lakini hawabadilishi kamwe JavaScript pointers, kuzuia leaking ya utendakazi wa JavaScript.

manifest.json

A Chrome extension ni sawa na folda ya ZIP yenye .crx file extension. Core ya extension ni faili ya manifest.json katika mizizi ya folda, ambayo inaelezea muundo, ruhusa, na chaguzi nyingine za usanidi.

Mfano:

{
"manifest_version": 2,
"name": "My extension",
"version": "1.0",
"permissions": ["storage"],
"content_scripts": [
{
"js": ["script.js"],
"matches": ["https://example.com/*", "https://www.example.com/*"],
"exclude_matches": ["*://*/*business*"]
}
],
"background": {
"scripts": ["background.js"]
},
"options_ui": {
"page": "options.html"
}
}

content_scripts

Content scripts hupakiwa kila mara mtumiaji anapofika kwenye ukurasa unaolingana, katika kesi yetu ukurasa wowote unaolingana na kauli https://example.com/* na usioolingana na regex *://*/*/business*. Zinatekelezwa kama skripti za ukurasa mwenyewe na zina upatikanaji usio na vikwazo kwa Document Object Model (DOM).

"content_scripts": [
{
"js": [
"script.js"
],
"matches": [
"https://example.com/*",
"https://www.example.com/*"
],
"exclude_matches": ["*://*/*business*"],
}
],

Ili kujumuisha au kuondoa URL zaidi pia inawezekana kutumia include_globs na exclude_globs.

Huu ni mfano wa content script ambao utaongeza kitufe cha ‘explain’ kwenye ukurasa na utatumia the storage API kupata thamani ya message kutoka kwenye storage ya extension.

chrome.storage.local.get("message", (result) => {
let div = document.createElement("div")
div.innerHTML = result.message + " <button>Explain</button>"
div.querySelector("button").addEventListener("click", () => {
chrome.runtime.sendMessage("explain")
})
document.body.appendChild(div)
})

Ujumbe hutumwa kwa kurasa za extension na content script wakati kitufe hiki kinabonyezwa, kwa kutumia runtime.sendMessage() API. Hii ni kwa sababu content script haina uwezo wa moja kwa moja wa kufikia APIs, ingawa storage ni mojawapo ya istisna chache. Kwa kazi zinazozidi zile istisna, ujumbe hutumwa kwa kurasa za extension ambazo content scripts zinaweza kuwasiliana nazo.

Warning

Iwategemea kivinjari, uwezo wa content script unaweza kutofautiana kidogo. Kwa vivinjari vinavyotokana na Chromium, orodha ya uwezo inapatikana katika [Chrome Developers documentation], na kwa Firefox, [MDN] ndiyo chanzo kikuu.
Pia ni muhimu kutambua kuwa content scripts zina uwezo wa kuwasiliana na background scripts, zikiwawezesha kufanya vitendo na kurudisha majibu.

Ili kutazama na kurekebisha content scripts katika Chrome, menyu ya Chrome developer tools inapatikana kupitia Options > More tools > Developer tools AU kwa kubonyeza Ctrl + Shift + I.

Mara developer tools zikiwa zimeonyeshwa, bonyeza Source tab, kisha Content Scripts tab. Hii inaruhusu kuangalia content scripts zinazoendesha kutoka kwa extensions mbalimbali na kuweka breakpoints ili kufuatilia mtiririko wa utekelezaji.

Content Scripts zilizowekwa

Tip

Kumbuka kuwa Content Scripts aren’t mandatory kwani pia inawezekana dynamically inject scripts na programatically inject them katika kurasa za wavuti kupitia tabs.executeScript. Hii inatoa udhibiti zaidi wa granular controls.

Kwa kuingiza content script kwa njia ya program, extension inahitajika kuwa na host permissions kwa ukurasa ambao script zitakuwa zinajiingiza. Ruhusa hizi zinaweza kupatikana ama kwa requesting them ndani ya manifest ya extension au kwa muda mfupi kupitia activeTab.

Mfano wa extension inayotegemea activeTab

{
"name": "My extension",
...
"permissions": [
"activeTab",
"scripting"
],
"background": {
"service_worker": "background.js"
},
"action": {
"default_title": "Action Button"
}
}
  • Ingiza faili la JS kwa kubofya:
// content-script.js
document.body.style.backgroundColor = "orange"

//service-worker.js - Inject the JS file
chrome.action.onClicked.addListener((tab) => {
chrome.scripting.executeScript({
target: { tabId: tab.id },
files: ["content-script.js"],
})
})
  • Inject a function kwa kubofya:
//service-worker.js - Inject a function
function injectedFunction() {
document.body.style.backgroundColor = "orange"
}

chrome.action.onClicked.addListener((tab) => {
chrome.scripting.executeScript({
target: { tabId: tab.id },
func: injectedFunction,
})
})

Mfano na ruhusa za scripting

// service-workser.js
chrome.scripting.registerContentScripts([
{
id: "test",
matches: ["https://*.example.com/*"],
excludeMatches: ["*://*/*business*"],
js: ["contentScript.js"],
},
])

// Another example
chrome.tabs.executeScript(tabId, { file: "content_script.js" })

Ili kujumuisha au kuondoa URL zaidi pia inawezekana kutumia include_globs na exclude_globs.

Scripts za Maudhui run_at

Sehemu run_at inadhibiti lini faili za JavaScript zinaingizwa kwenye ukurasa wa wavuti. Thamani inayopendekezwa na chaguo-msingi ni "document_idle".

Thamani zinazowezekana ni:

  • document_idle: Kadri inavyowezekana
  • document_start: Baada ya faili yoyote kutoka css, lakini kabla DOM nyingine yoyote itakapojengwa au script nyingine yoyote kuanzishwa.
  • document_end: Mara tu baada DOM kukamilika, lakini kabla rasilimali ndogo kama picha na frames zimepakiwa.

Kupitia manifest.json

{
"name": "My extension",
...
"content_scripts": [
{
"matches": ["https://*.example.com/*"],
"run_at": "document_idle",
"js": ["contentScript.js"]
}
],
...
}

Kupitia service-worker.js

chrome.scripting.registerContentScripts([
{
id: "test",
matches: ["https://*.example.com/*"],
runAt: "document_idle",
js: ["contentScript.js"],
},
])

background

Ujumbe unaotumwa na content scripts unakabidhiwa kwa background page, ambayo inachukua nafasi kuu katika kuratibu vipengele vya extension. Kwa kuzingatia, background page hubaki kwa muda wote wa extension, ikifanya kazi kwa utulivu bila mwingiliano wa moja kwa moja na mtumiaji. Ina Document Object Model (DOM) yake, kuruhusu mwingiliano tata na usimamizi wa hali.

Vidokezo Muhimu:

  • Kazi ya Background Page: Hufanya kazi kama kituo cha neva kwa extension, kuhakikisha mawasiliano na uratibu kati ya sehemu mbalimbali za extension.
  • Uendelevu: Ni kipengele kilicho karibu kila wakati, kisisichoweza kuonekana kwa mtumiaji lakini muhimu kwa utendakazi wa extension.
  • Automatic Generation: Ikiwa haijatolewa wazi, browser itaunda background page moja kwa moja. Page iliyoundwa moja kwa moja itajumuisha background scripts zote zilizoainishwa katika manifest ya extension, ikihakikisha utendakazi usio na mshono wa kazi za background za extension.

Tip

Urahisi unaotolewa na browser katika kuunda background page moja kwa moja (wakati haijatangazwa wazi) unahakikisha kwamba background scripts zote zinazohitajika zimeingizwa na zinafanya kazi, kurahisisha mchakato wa usanidi wa extension.

Mfano wa background script:

chrome.runtime.onMessage.addListener((request, sender, sendResponse) => {
if (request == "explain") {
chrome.tabs.create({ url: "https://example.net/explanation" })
}
})

Inatumia runtime.onMessage API kusikiliza ujumbe. Wakati ujumbe wa “explain” unapopokelewa, inatumia tabs API kufungua ukurasa katika tabo mpya.

Ili ku-debug background script unaweza kwenda kwenye extension details and inspect the service worker, hii itaifungua developer tools na background script:

Options pages and other

Viongezeo vya browser vinaweza kuwa na aina mbalimbali za kurasa:

  • Action pages zinaonyeshwa katika drop-down when the extension icon inapobonyezwa.
  • Kurasa ambazo extension itapakia load in a new tab.
  • Option Pages: Ukurasa huu unaonyeshwa juu ya extension wakati unabonyezwa. Katika manifest iliyotangulia katika kesi yangu niliweza kufikia ukurasa huu katika chrome://extensions/?options=fadlhnelkbeojnebcbkacjilhnbjfjca au kwa kubofya:

Kumbuka kuwa kurasa hizi hazidumu kama background pages kwani zinapakia maudhui kwa njia ya dynamic kulingana na haja. Licha yake, zinashiriki uwezo fulani na background page:

  • Communication with Content Scripts: Kama background page, kurasa hizi zinaweza kupokea ujumbe kutoka kwa content scripts, kurahisisha mwingiliano ndani ya extension.
  • Access to Extension-Specific APIs: Kurasa hizi zinafikia extension-specific APIs kwa kiasi kikamilifu, zikitegemea permissions zilizoainishwa kwa extension.

permissions & host_permissions

permissions na host_permissions ni vipengele katika manifest.json vinavyoonyesha uruhusa gani extension ina (storage, location…) na kwa kurasa za wavuti gani.

Kwa kuwa viongezeo vya browser vinaweza kuwa na privileged, extension mbaya au iliyodhulumiwa inaweza kumruhusu mshambuliaji njia mbalimbali za kuiba taarifa nyeti na kumtazama mtumiaji.

Angalia jinsi mipangilio hii inavyofanya kazi na jinsi zinavyoweza kutumika vibaya katika:

BrowExt - permissions & host_permissions

content_security_policy

Sera ya content security policy inaweza kutangazwa pia ndani ya manifest.json. Ikiwa ipo, inaweza kuwa vulnerable.

Mipangilio ya default kwa kurasa za viongezeo vya browser ni zilizo kali:

script-src 'self'; object-src 'self';

Kwa habari zaidi kuhusu CSP na potential bypasses angalia:

Content Security Policy (CSP) Bypass

web_accessible_resources

Ili ukurasa wa wavuti uweze kufikia ukurasa wa Browser Extension, mfano ukurasa wa .html, ukurasa huu unahitaji kutajwa kwenye sehemu ya web_accessible_resources ya manifest.json.
Kwa mfano:

{
...
"web_accessible_resources": [
{
"resources": [ "images/*.png" ],
"matches": [ "https://example.com/*" ]
},
{
"resources": [ "fonts/*.woff" ],
"matches": [ "https://example.com/*" ]
}
],
...
}

Kurasa hizi zinapatikana kwenye URL kama:

chrome-extension://<extension-id>/message.html

In public extensions the extension-id is accesible:

Although, if the manifest.json parameter use_dynamic_url is used, this id can be dynamic.

Tip

Kumbuka kwamba hata kama ukurasa umetajwa hapa, unaweza kuwa kulindwa dhidi ya ClickJacking kutokana na Content Security Policy. Kwa hivyo pia ni lazima kuangalia hiyo (sehemu ya frame-ancestors) kabla ya kuthibitisha kuwa shambulio la ClickJacking linawezekana.

Being allowed to access these pages make these pages potentially vulnerable ClickJacking:

BrowExt - ClickJacking

Tip

Kuruhusu kurasa hizi zionekane tu na extension na si kutoka kwa URL za nasibu kunaweza kuzuia mashambulizi ya ClickJacking.

Caution

Kumbuka kwamba kurasa kutoka web_accessible_resources na kurasa nyingine za extension pia zina uwezo wa contacting background scripts. Kwa hivyo ikiwa moja ya kurasa hizi ina udhaifu wa XSS inaweza kufungua udhaifu mkubwa zaidi.

Zaidi ya hayo, kumbuka kwamba unaweza tu kufungua kurasa zilizotajwa katika web_accessible_resources ndani ya iframes, lakini kutoka tab mpya inawezekana kufikia ukurasa wowote ndani ya extension ukijua extension ID. Kwa hivyo, ikiwa XSS imetambulika ikitumia vigezo hivyo, inaweza kutumika hata kama ukurasa haujatayarishwa katika web_accessible_resources.

externally_connectable

A per the docs, The "externally_connectable" manifest property declares which extensions and web pages can connect to your extension via runtime.connect and runtime.sendMessage.

  • If the externally_connectable key is not declared in your extension’s manifest or it’s declared as "ids": ["*"], all extensions can connect, but no web pages can connect.
  • If specific IDs are specified, like in "ids": ["aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"], only those applications can connect.
  • If matches are specified, those web apps will be able to connect:
"matches": [
"https://*.google.com/*",
"*://*.chromium.org/*",
  • Ikiwa imeainishwa kama tupu: "externally_connectable": {}, hakuna app au wavuti itakayoweza kuungana.

Kadri idadi ya extensions na URLs zilizotajwa hapa inavyokuwa ndogo, ndivyo eneo la mashambulizi litakavyokuwa dogo.

Caution

Ikiwa ukurasa wa wavuti unaoharibika kwa XSS au takeover umeorodheshwa katika externally_connectable, mshambuliaji ataweza kutuma messages moja kwa moja kwa background script, akiepuka kabisa Content Script na CSP yake.

Kwa hiyo, hili ni bypass yenye nguvu sana.

Zaidi ya hayo, ikiwa client itainstall extension ya rogue, hata kama haikuruhusiwa kuwasiliana na extension iliyo hatarini, inaweza kuingiza data za XSS katika ukurasa wa wavuti ulioruhusiwa au kutumia vibaya APIs za WebRequest au DeclarativeNetRequest kubadilisha maombi kwenye domain inayolengwa kwa kubadilisha ombi la ukurasa kwa JavaScript file. (Kumbuka kwamba CSP kwenye ukurasa ulio lengwa inaweza kuzuia mashambulizi haya). Wazo hili linatokana na writeup hii.

Muhtasari wa mawasiliano

Extension <–> WebApp

Kwa mawasiliano kati ya content script na ukurasa wa wavuti kawaida hutumika post messages. Kwa hivyo, katika web application kawaida utapata miito kwa function window.postMessage na katika content script vinasikilizaji kama window.addEventListener. Hata hivyo, kumbuka kwamba extension pia inaweza kuwasiliana na web application kwa kutuma Post Message (na kwa hiyo web inapaswa kuikadiria) au tu kufanya web ipakie script mpya.

Ndani ya extension

Kawaida function chrome.runtime.sendMessage hutumika kutuma ujumbe ndani ya extension (kwa kawaida hushughulikiwa na background script) na ili kupokea na kushughulikia ujumbe listener huwekwa kwa kuita chrome.runtime.onMessage.addListener.

Pia inawezekana kutumia chrome.runtime.connect() kupata muunganisho wa kudumu badala ya kutuma ujumbe moja kwa moja; inaweza kutumika kutuma na kupokea messages kama kwenye mfano ufuatao:

chrome.runtime.connect() example ```javascript var port = chrome.runtime.connect()

// Listen for messages from the web page window.addEventListener( “message”, (event) => { // Only accept messages from the same window if (event.source !== window) { return }

// Check if the message type is “FROM_PAGE” if (event.data.type && event.data.type === “FROM_PAGE”) { console.log(“Content script received: “ + event.data.text) // Forward the message to the background script port.postMessage({ type: “FROM_PAGE”, text: event.data.text }) } }, false )

// Listen for messages from the background script port.onMessage.addListener(function (msg) { console.log(“Content script received message from background script:”, msg) // Handle the response message from the background script })

</details>

Pia inawezekana kutuma ujumbe kutoka background script kwenda content script iliyoko kwenye kichupo fulani kwa kutumia **`chrome.tabs.sendMessage`**, ambapo utahitaji kuonyesha **ID ya kichupo** utakayotumia kutuma ujumbe.

### Kutoka kwa `externally_connectable` zilizoruhusiwa kwenda kwenye extension

**Web apps na extension za browser za nje zilizoruhusiwa** katika usanidi wa `externally_connectable` zinaweza kutuma maombi kwa kutumia :
```javascript
chrome.runtime.sendMessage(extensionId, ...

Wakati inahitajika kutaja extension ID.

Native Messaging

Inawezekana kwa background scripts kuwasiliana na binaries ndani ya mfumo, ambazo zinaweza kuwa nyeti kwa udhaifu hatari kama RCEs ikiwa mawasiliano haya hayatahakikiwa ipasavyo. More on this later.

chrome.runtime.sendNativeMessage(
"com.my_company.my_application",
{ text: "Hello" },
function (response) {
console.log("Received " + response)
}
)

Web ↔︎ Content Script Communication

Mazingira ambayo content scripts hufanya kazi na yale ambapo kurasa za mwenyeji zinapatikana yamegawanywa kati yao, kuhakikisha isolation. Licha ya isolation hii, pande zote mbili zina uwezo wa kuingiliana na ukurasa wa Document Object Model (DOM), rasilimali inayoshirikiwa. Ili ukurasa wa mwenyeji uweze kuwasiliana na content script, au kwa njia isiyo ya moja kwa moja na extension kupitia content script, inahitajika kutumia DOM inayopatikana kwa pande zote kama njia ya mawasiliano.

Post Messages

// This is like "chrome.runtime.sendMessage" but to maintain the connection
var port = chrome.runtime.connect()

window.addEventListener(
"message",
(event) => {
// We only accept messages from ourselves
if (event.source !== window) {
return
}

if (event.data.type && event.data.type === "FROM_PAGE") {
console.log("Content script received: " + event.data.text)
// Forward the message to the background script
port.postMessage(event.data.text)
}
},
false
)

document.getElementById("theButton").addEventListener(
"click",
() => {
window.postMessage(
{ type: "FROM_PAGE", text: "Hello from the webpage!" },
"*"
)
},
false
)

Mawasiliano salama ya Post Message yanapaswa kuthibitisha uhalali wa ujumbe uliopokelewa; hili linaweza kufanywa kwa kukagua:

  • event.isTrusted: Hii ni True tu ikiwa event ilisababishwa na kitendo cha mtumiaji
  • The content script inaweza kutarajia ujumbe tu ikiwa mtumiaji atafanya kitendo fulani
  • origin domain: inaweza kutarajia ujumbe tu kutoka kwenye orodha ya allowlist ya domains.
  • Ikiwa regex inatumiwa, kuwa mwangalifu sana
  • Source: received_message.source !== window inaweza kutumika kuthibitisha kama ujumbe ulikuwa kutoka kwenye dirisha hiyo hiyo ambapo Content Script inasikiliza.

Ukaguzi uliotajwa hapo juu, hata ukifanywa, unaweza kuwa dhaifu; angalia ukurasa ufuatao kuhusu potential Post Message bypasses:

PostMessage Vulnerabilities

Iframe

Njia nyingine inayowezekana ya mawasiliano inaweza kuwa kupitia Iframe URLs, unaweza kupata mfano katika:

BrowExt - XSS Example

DOM

Hii si “kabla si” njia ya mawasiliano kabisa, lakini web na the content script wata kuwa na ufikiaji kwa web DOM. Kwa hivyo, ikiwa content script inasoma baadhi ya taarifa kutoka kwake, ikimwamini web DOM, web inaweza modify this data (kwa sababu web haipaswi kuaminiwa, au kwa sababu web ina udhaifu wa XSS) na kuathiri Content Script.

Unaweza pia kupata mfano wa DOM based XSS to compromise a browser extension katika:

BrowExt - XSS Example

Content Script ↔︎ Background Script Communication

Content Script inaweza kutumia functions runtime.sendMessage() or tabs.sendMessage() kutuma one-time JSON-serializable message.

Kushughulikia response, tumia Promise iliyorejeshwa. Hata hivyo, kwa ajili ya backward compatibility, bado unaweza kuingiza callback kama argument ya mwisho.

Kutuma ombi kutoka kwa content script inaonekana kama ifuatavyo:

;(async () => {
const response = await chrome.runtime.sendMessage({ greeting: "hello" })
// do something with response here, not outside the function
console.log(response)
})()

Kutuma ombi kutoka kwa extension (kwa kawaida background script). Mfano wa jinsi ya kutuma ujumbe kwa content script kwenye tab iliyochaguliwa:

// From https://stackoverflow.com/questions/36153999/how-to-send-a-message-between-chrome-extension-popup-and-content-script
;(async () => {
const [tab] = await chrome.tabs.query({
active: true,
lastFocusedWindow: true,
})
const response = await chrome.tabs.sendMessage(tab.id, { greeting: "hello" })
// do something with response here, not outside the function
console.log(response)
})()

Kwenye upande wa kupokea, unahitaji kuanzisha runtime.onMessage event listener ili kushughulikia ujumbe. Hii inaonekana sawa kutoka kwa content script au extension page.

// From https://stackoverflow.com/questions/70406787/javascript-send-message-from-content-js-to-background-js
chrome.runtime.onMessage.addListener(function (request, sender, sendResponse) {
console.log(
sender.tab
? "from a content script:" + sender.tab.url
: "from the extension"
)
if (request.greeting === "hello") sendResponse({ farewell: "goodbye" })
})

Katika mfano uliotajwa, sendResponse() ilitekelezwa kwa njia ya synchronous. Ili kubadilisha event handler ya onMessage kwa ajili ya utekelezaji asynchronous wa sendResponse(), ni muhimu kujumuisha return true;.

Jambo muhimu la kuzingatia ni kwamba katika matukio ambapo kurasa nyingi zimewekwa kupokea matukio ya onMessage, ukurasa wa kwanza kutekeleza sendResponse() kwa tukio maalum ndio pekee utaweza kutoa jibu kwa ufanisi. Majibu yoyote yanayofuata kwa tukio hilo hayatapewa kipaumbele.

Unapotengeneza extensions mpya, inapendekezwa kutumia promises badala ya callbacks. Kuhusu matumizi ya callbacks, function ya sendResponse() inachukuliwa kuwa halali tu ikiwa inatekelezwa moja kwa moja ndani ya muktadha synchronous, au ikiwa event handler inaonyesha operesheni asynchronous kwa kurudisha true. Iwapo hakuna handler atakayerejesha true au ikiwa sendResponse() itaondolewa kwenye kumbukumbu (garbage-collected), callback inayohusishwa na function ya sendMessage() itaitwa kwa chaguo-msingi.

Native Messaging

Browser extensions pia zinaruhusu kuwasiliana na binaries in the system via stdin. Programu lazima isakinishe json inayosema hivyo, kwa json kama:

{
"name": "com.my_company.my_application",
"description": "My Application",
"path": "C:\\Program Files\\My Application\\chrome_native_messaging_host.exe",
"type": "stdio",
"allowed_origins": ["chrome-extension://knldjmfmopnpolahpmmgbagdohdnhkik/"]
}

Ambapo name ni string inayopitishwa kwa runtime.connectNative() au runtime.sendNativeMessage() ili kuwasiliana na application kutoka kwa background scripts za browser extension. path ni path ya binary, kuna type moja tu halali ambayo ni stdio (tumia stdin na stdout) na allowed_origins inaonyesha extensions zinazoweza kuifikia (na haiwezi kuwa na wildcard).

Chrome/Chromium itatafuta json hii katika windows registry na kwenye baadhi ya paths za macOS na Linux (maelezo zaidi katika docs).

Tip

Browser extension pia inahitaji ruhusa ya nativeMessaing iliyotangazwa ili iweze kutumia mawasiliano haya.

Hivi ndivyo inavyoonekana code ya background script ikituma messages kwa native application:

chrome.runtime.sendNativeMessage(
"com.my_company.my_application",
{ text: "Hello" },
function (response) {
console.log("Received " + response)
}
)

In this blog post, muundo hatari unaotumia native messages umependekezwa:

  1. Extension ya Kivinjari ina wildcard pattern kwa content script.
  2. Content script inapitisha ujumbe za postMessage kwa background script kwa kutumia sendMessage.
  3. Background script inapitisha ujumbe kwa native application kwa kutumia sendNativeMessage.
  4. Native application inashughulikia ujumbe kwa njia hatari, na kusababisha code execution.

Ndani yake kuna mfano unaoelezea jinsi ya kwenda kutoka ukurasa wowote hadi RCE kwa kutumia extension ya kivinjari.

Sensitive Information in Memory/Code/Clipboard

Ikiwa Extension ya Kivinjari inahifadhi taarifa nyeti ndani it’s memory, inaweza kunyanyuzwa (dumped) (hasa kwenye mashine za Windows) na kutafutwa kwa taarifa hizi.

Kwa hivyo, memory ya Extension ya Kivinjari haipaswi kuchukuliwa kuwa salama na taarifa nyeti kama credentials au misemo ya mnemonic haipaswi kuhifadhiwa.

Bila shaka, usiweke taarifa nyeti katika code, kwani zitakuwa public.

Ili dump memory kutoka browser unaweza dump the process memory au kwenda kwenye settings ya extension ya kivinjari bonyeza Inspect pop-up -> Katika sehemu ya Memory -> Take a snaphost na CTRL+F kutafuta ndani ya snapshot kwa taarifa nyeti.

Zaidi ya hayo, taarifa zilizokuwa hatari sana kama mnemonic keys au passwords hazipaswi kuruhusiwa kukopiwa kwenye clipboard (au angalau zifutwe kutoka clipboard ndani ya sekunde chache) kwa sababu kisha michakato inayofuatilia clipboard itaweza kuzipata.

Loading an Extension in the Browser

  1. Pakua Extension ya Kivinjari na ui-fungue (unzip)
  2. Nenda kwenye chrome://extensions/ na wezesha the Developer Mode
  3. Bonyeza kitufe cha Load unpacked

Kwenye Firefox nenda kwenye about:debugging#/runtime/this-firefox na bonyeza kitufe cha Load Temporary Add-on.

Getting the source code from the store

Msimbo wa chanzo wa extension ya Chrome unaweza kupatikana kwa njia mbalimbali. Hapa chini kuna maelezo ya kina na maagizo kwa kila chaguo.

Download Extension as ZIP via Command Line

Msimbo wa chanzo wa extension ya Chrome unaweza kupakuliwa kama faili la ZIP kwa kutumia command line. Hii inajumuisha kutumia curl kudownload faili la ZIP kutoka kwenye URL maalum kisha kutoa yaliyomo ya ZIP kwenye saraka. Hapa kuna hatua:

  1. Badilisha "extension_id" na ID halisi ya extension.
  2. Tekeleza amri zifuatazo:
extension_id=your_extension_id   # Replace with the actual extension ID
curl -L -o "$extension_id.zip" "https://clients2.google.com/service/update2/crx?response=redirect&os=mac&arch=x86-64&nacl_arch=x86-64&prod=chromecrx&prodchannel=stable&prodversion=44.0.2403.130&x=id%3D$extension_id%26uc"
unzip -d "$extension_id-source" "$extension_id.zip"

Tumia tovuti ya CRX Viewer

https://robwu.nl/crxviewer/

Tumia extension ya CRX Viewer

Njia nyingine rahisi ni kutumia Chrome Extension Source Viewer, ambayo ni mradi wa open-source. Inaweza kusakinishwa kutoka kwa Chrome Web Store. Msimbo wa chanzo wa viewer upo katika GitHub repository.

Tazama msimbo wa extension iliyosakinishwa kwa eneo la ndani

Chrome extensions zilizowekwa mahali pa kompyuta pia zinaweza kuchunguzwa. Hivi ndivyo:

  1. Fikia saraka ya profile ya Chrome kwa kutembelea chrome://version/ na kubaini shamba la “Profile Path”.
  2. Nenda kwenye saraka ndogo ya Extensions/ ndani ya saraka ya profile.
  3. Folda hii ina extensions zote zilizosakinishwa, kwa kawaida zikiwa na msimbo wao wa chanzo katika muundo unaosomeka.

Ili kutambua extensions, unaweza kupangia IDs zao kwa majina:

  • Washa Developer Mode kwenye ukurasa wa about:extensions ili kuona IDs za kila extension.
  • Ndani ya kila folda ya extension, faili ya manifest.json ina shamba la name linaloweza kusomwa, likikusaidia kutambua extension.

Tumia File Archiver au Unpacker

Nenda kwenye Chrome Web Store na pakua extension. Faili itakuwa na nyongeza .crx. Badilisha nyongeza ya faili kutoka .crx kuwa .zip. Tumia programu yoyote ya archive (kama WinRAR, 7-Zip, n.k.) kutoa yaliyomo ya faili la ZIP.

Tumia Developer Mode katika Chrome

Fungua Chrome na nenda chrome://extensions/. Washa “Developer mode” juu kulia. Bonyeza “Load unpacked extension…”. Elekeza kwenye saraka ya extension yako. Hii haitapakua msimbo wa chanzo, lakini ni muhimu kwa kuangalia na kuhariri msimbo wa extension ambayo tayari imepakuliwa au imeandaliwa.

Chrome extension manifest dataset

Ili kujaribu kubaini browser extensions zilizo hatarini unaweza kutumia thehttps://github.com/palant/chrome-extension-manifests-dataset na kukagua faili zao za manifest kwa dalili zinazoweza kuonyesha udhaifu. Kwa mfano ili kuangalia extensions zenye zaidi ya watumiaji 25000, content_scripts na ruhusa nativeMessaing:

# Query example from https://spaceraccoon.dev/universal-code-execution-browser-extensions/
node query.js -f "metadata.user_count > 250000" "manifest.content_scripts?.length > 0 && manifest.permissions?.includes('nativeMessaging')"

Post-exploitation: Forced extension load & persistence (Windows)

Mbinu ya kujificha ya ku-backdoor Chromium kwa kuhariri moja kwa moja per-user Preferences na kutunga HMACs halali, ambayo husababisha browser kukubali na kuanzisha arbitrary unpacked extension bila prompts au flags.

Forced Extension Load Preferences Mac Forgery Windows

Detecting Malicious Extension Updates (Static Version Diffing)

Udukuzi wa supply-chain mara nyingi huja kama malicious updates kwa extensions ambazo awali zilikuwa benign. Njia ya vitendo yenye kelele ndogo ni kulinganisha kifurushi kipya cha extension dhidi ya toleo la mwisho linalojulikana kuwa sahihi kwa kutumia static analysis (kwa mfano, Assemblyline). Lengo ni kutoa tahadhari juu ya high-signal deltas badala ya kila mabadiliko.

Workflow

  • Submit both versions (old + new) to the same static-analysis profile.
  • Flag new or updated background/service worker scripts (persistence + privileged logic).
  • Flag new or updated content scripts (DOM access and data collection).
  • Flag new permissions/host_permissions added in manifest.json.
  • Flag new domains extracted from code (potential C2/exfil endpoints).
  • Flag new static-analysis detections (e.g., base64 decode, cookie harvesting, network-request builders, obfuscation patterns).
  • Flag statistical anomalies such as sharp entropy jumps or outlier z-scores in changed scripts.

Detecting script changes accurately

  • New script added → detect via manifest.json diff.
  • Existing script modified (manifest unchanged) → compare per-file hashes from the extracted file tree (e.g., Assemblyline Extract output). This catches stealthy updates to existing workers or content scripts.

Pre-disclosure detections

To avoid “easy mode” detections based on already-known IOCs, disable threat-intel-fed services and rely on intrinsic signals (domains, heuristic signatures, script deltas, entropy anomalies). This increases chances of catching malicious updates before public reporting.

Example high-confidence alert logic

  • Low-noise combo: new domains + new static-analysis detections + updated background/service worker + updated or added content scripts.
  • Broader catch: new domain + new or updated background/service worker (higher recall, higher noise).

Key Assemblyline services for this workflow:

  • Extract: unpacks the extension and yields per-file hashes.
  • Characterize: computes file characteristics (e.g., entropy).
  • JsJAWS / FrankenStrings / URLCreator: surface JS heuristics, strings, and domains to diff between versions.

Security Audit Checklist

Ingawa Browser Extensions zina limited attack surface, baadhi yao yanaweza kuwa na vulnerabilities au maboresho ya hardening. Zifuatazo ndizo za kawaida:

  • Punguza kadri inavyowezekana ombi la permissions
  • Punguza kadri inavyowezekana host_permissions
  • Tumia strong content_security_policy
  • Punguza kadri inavyowezekana externally_connectable; kama hakuna hitaji, usiweke by default — taja {}
  • Ikiwa URL vulnerable to XSS or to takeover imetajwa hapa, mshambuliaji ataweza send messages to the background scripts directly. Bypass yenye nguvu sana.
  • Punguza kadri inavyowezekana web_accessible_resources, hata empty kama inawezekana.
  • Ikiwa web_accessible_resources si none, angalia kwa ajili ya ClickJacking
  • Ikiwa mawasiliano yoyote yanafanyika kutoka kwa extension hadi kwa web page, check for XSS vulnerabilities zinazoweza kusababishwa katika mawasiliano hayo.
  • Ikiwa Post Messages zinatumika, angalia kwa ajili ya Post Message vulnerabilities.
  • Ikiwa Content Script access DOM details, hakikisha hazileti XSS watakapohaririwa na tovuti
  • Toa umuhimu maalum kama mawasiliano haya pia yanahusisha Content Script -> Background script communication
  • Ikiwa background script inawasiliana kupitia native messaging hakikisha mawasiliano ni salama na imefanywa sanitize
  • Sensitive information shouldn’t be stored ndani ya code ya Browser Extension
  • Sensitive information shouldn’t be stored ndani ya memory ya Browser Extension
  • Sensitive information shouldn’t be stored ndani ya file system bila ulinzi

Browser Extension Risks

  • The app https://crxaminer.tech/ analyzes some data like the permissions browser extension requests to give a risk level of using the browser extension.

Tools

Tarnish

  • Pulls any Chrome extension from a provided Chrome webstore link.
  • manifest.json viewer: simply displays a JSON-prettified version of the extension’s manifest.
  • Fingerprint Analysis: Detection of web_accessible_resources and automatic generation of Chrome extension fingerprinting JavaScript.
  • Potential Clickjacking Analysis: Detection of extension HTML pages with the web_accessible_resources directive set. These are potentially vulnerable to clickjacking depending on the purpose of the pages.
  • Permission Warning(s) viewer: which shows a list of all the Chrome permission prompt warnings which will be displayed upon a user attempting to install the extension.
  • Dangerous Function(s): shows the location of dangerous functions which could potentially be exploited by an attacker (e.g. functions such as innerHTML, chrome.tabs.executeScript).
  • Entry Point(s): shows where the extension takes in user/external input. This is useful for understanding an extension’s surface area and looking for potential points to send maliciously-crafted data to the extension.
  • Both the Dangerous Function(s) and Entry Point(s) scanners have the following for their generated alerts:
  • Relevant code snippet and line that caused the alert.
  • Description of the issue.
  • A “View File” button to view the full source file containing the code.
  • The path of the alerted file.
  • The full Chrome extension URI of the alerted file.
  • The type of file it is, such as a Background Page script, Content Script, Browser Action, etc.
  • If the vulnerable line is in a JavaScript file, the paths of all of the pages where it is included as well as these page’s type, and web_accessible_resource status.
  • Content Security Policy (CSP) analyzer and bypass checker: This will point out weaknesses in your extension’s CSP and will also illuminate any potential ways to bypass your CSP due to whitelisted CDNs, etc.
  • Known Vulnerable Libraries: This uses Retire.js to check for any usage of known-vulnerable JavaScript libraries.
  • Download extension and formatted versions.
  • Download the original extension.
  • Download a beautified version of the extension (auto prettified HTML and JavaScript).
  • Automatic caching of scan results, running an extension scan will take a good amount of time the first time you run it. However the second time, assuming the extension hasn’t been updated, will be almost instant due to the results being cached.
  • Linkable Report URLs, easily link someone else to an extension report generated by tarnish.

Neto

Project Neto ni Python 3 package iliyoundwa kuchambua na kufichua vipengele vilivyofichwa vya browser plugins na extensions kwa browsers maarufu kama Firefox na Chrome. Inabadilisha mchakato wa ku-unzip packaged files ili kutoa vipengele hivi kutoka kwa resources muhimu ndani ya extension kama manifest.json, localization folders au JavaScript na HTML source files.

References

Tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Jifunze na fanya mazoezi ya Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks