Duy Linh✔
Writer
Một nghiên cứu bảo mật đối với dịch vụ PostgreSQL do Snowflake quản lý đã cho thấy cách một tài khoản cơ sở dữ liệu không có quyền quản trị tối cao vẫn có thể bị lợi dụng để chiếm quyền thực thi lệnh trên máy chủ chạy cơ sở dữ liệu. Bằng cách kết hợp nhiều tính năng có sẵn của PostgreSQL, các nhà nghiên cứu đã xây dựng được chuỗi leo thang đặc quyền, vượt qua những biện pháp ngăn chặn thông thường mà Snowflake triển khai để hạn chế việc thực thi lệnh và truy cập tệp thông qua SQL.
Phát hiện này cho thấy những quyền hạn tưởng chừng không quá nguy hiểm khi đứng riêng lẻ vẫn có thể kết hợp thành rủi ro bảo mật nghiêm trọng, đặc biệt trong các dịch vụ cơ sở dữ liệu đám mây được quản lý. Trong mô hình này, nhà cung cấp chịu trách nhiệm kiểm soát máy chủ và hệ điều hành, trong khi khách hàng vẫn quyết định cách phân bổ quyền cho các tài khoản trong cơ sở dữ liệu.
Các nhà nghiên cứu thuộc Varonis Threat Labs đã xác định chuỗi leo thang đặc quyền này và báo cáo cho Snowflake. Theo Varonis, vấn đề đã được Snowflake khắc phục ở phía máy chủ trước khi nghiên cứu được công bố. Vì vậy, khách hàng sử dụng Snowflake Postgres không cần thực hiện thêm hành động nào đối với phát hiện cụ thể này.
Nhóm nghiên cứu lần đầu báo cáo chuỗi lỗi vào ngày 31/5/2026 và công bố thông tin vào ngày 17/10/2026.
Đầu tiên, nhóm nghiên cứu sử dụng <span>CREATEROLE</span> để cấp cho tài khoản khởi tạo hai vai trò tích hợp sẵn là <span>pg_read_all_data</span> và <span>pg_write_all_data</span>. Những vai trò này cung cấp quyền truy cập rộng vào dữ liệu trong các bảng cơ sở dữ liệu và danh mục hệ thống, tạo điều kiện để nhóm nghiên cứu thay đổi các mục trong <span>pg_cron</span> – tiện ích mở rộng của PostgreSQL dùng để lập lịch và tự động thực thi tác vụ.
Sau đó, các nhà nghiên cứu chỉnh sửa một tác vụ đã lên lịch để tác vụ này chạy với quyền hạn cao của tài khoản <span>postgres</span>. Khi tác vụ được thực thi, nó tạo ra một hàm <span>SECURITY </span><span>DEFINER</span>.
Chuỗi hoạt động như thế nào qua từng mắt xích (Nguồn – Varonis)
Điểm quan trọng của loại hàm này là nó chạy với quyền của chủ sở hữu hàm thay vì quyền của người gọi. Nhờ cơ chế đó, nhóm nghiên cứu có thể giành được quyền siêu người dùng PostgreSQL mà không cần sử dụng phương pháp thay đổi vai trò trực tiếp vốn đã bị Snowflake chặn.
Tuy nhiên, quyền siêu người dùng trong cơ sở dữ liệu vẫn chưa đồng nghĩa với việc kiểm soát được máy chủ bên dưới. Snowflake đã chặn nhiều phương pháp thông thường, bao gồm đọc tệp trên máy chủ, thay đổi thiết lập hệ thống hoặc chạy chương trình thông qua SQL.
Để vượt qua những hạn chế này, các nhà nghiên cứu phát hiện cơ chế <span>internal</span> của PostgreSQL có thể liên kết một tên hàm cơ sở dữ liệu mới với một hàm C đã tồn tại trong phần mềm máy chủ. Điều này giúp họ tạo lại khả năng truy cập đọc và ghi tệp vốn bị chặn, nhưng thông qua những tên hàm khác.
Khi đã có quyền truy cập tệp, nhóm nghiên cứu tiếp tục sử dụng tính năng đối tượng lớn (large objects) của PostgreSQL để ghi vào tệp cấu hình. Họ thay đổi thiết lập <span>archive_command</span>, vốn được sử dụng để thực thi lệnh shell khi PostgreSQL lưu trữ một phân đoạn nhật ký ghi trước (WAL) đã hoàn tất.
WAL là cơ chế ghi lại những thay đổi trong cơ sở dữ liệu trước khi các thay đổi đó được ghi hoàn toàn vào các tệp dữ liệu. Khi cấu hình <span>archive_command</span> được kích hoạt, lệnh shell do các nhà nghiên cứu thiết lập có thể được thực thi với tư cách tài khoản hệ thống <span>postgres</span>.
Đây là bước giúp chuỗi khai thác vượt khỏi phạm vi quyền hạn trong cơ sở dữ liệu và đạt đến khả năng thực thi lệnh của hệ điều hành. Nói cách khác, vấn đề không nằm ở một quyền riêng lẻ có thể trực tiếp chiếm quyền kiểm soát máy chủ, mà ở việc nhiều tính năng và cơ chế cấp quyền của PostgreSQL được kết hợp theo cách cho phép vượt qua các lớp bảo vệ.
Phát hiện này cho thấy việc chặn những chức năng SQL thường được sử dụng để thực thi lệnh hoặc truy cập tệp chưa chắc đã đủ an toàn nếu các khả năng tương tự vẫn có thể được gọi thông qua những con đường khác.
Một vấn đề khác là các hoạt động diễn ra ở cấp độ hệ điều hành có thể không xuất hiện đầy đủ trong những truy vấn SQL thông thường. Do đó, nhật ký kiểm toán của cơ sở dữ liệu có thể không phản ánh toàn bộ diễn biến của một cuộc tấn công, khiến việc phát hiện và điều tra sự cố trở nên khó khăn hơn.
Dù vậy, Varonis cho biết chuỗi khai thác được chứng minh trong môi trường thử nghiệm độc lập của nhóm nghiên cứu. Báo cáo không cho biết dữ liệu khách hàng của Snowflake đã bị truy cập thông qua kỹ thuật này. Đây là điểm cần phân biệt rõ: nghiên cứu chứng minh một con đường khai thác có thể xảy ra, nhưng không đồng nghĩa với việc đã có sự cố xâm nhập dữ liệu khách hàng được xác nhận.
Đọc mật khẩu và khóa thông qua trình bao bọc my_read_file được xây dựng lại của chúng tôi (Nguồn – Varonis)
Theo báo cáo, Snowflake đã tiếp nhận thông tin về lỗ hổng vào ngày 1/6 và xác nhận vào ngày 9/6 rằng khả năng thực thi mã cục bộ bên trong máy ảo Snowflake Postgres đã vượt qua ranh giới bảo mật. Công ty đã xử lý vấn đề ở phía máy chủ trước khi nghiên cứu được công khai.
Các nhà nghiên cứu cũng nhấn mạnh đây là một chuỗi khai thác dựa trên những hành vi và tính năng của PostgreSQL, chứ không phải một mẫu phần mềm độc hại mới. Phát hiện này đồng thời cho thấy rủi ro leo thang từ cơ sở dữ liệu lên máy chủ không phải vấn đề hoàn toàn mới, khi những trường hợp liên quan đến thực thi mã trong PostgreSQL và thực thi lệnh shell thông qua pgAdmin cũng từng được ghi nhận.
Đối với các tổ chức tự vận hành máy chủ PostgreSQL, Varonis đưa ra một số khuyến nghị nhằm giảm nguy cơ xảy ra những tình huống tương tự:
Báo cáo lưu ý rằng địa chỉ IP và tên miền có thể được cố ý vô hiệu hóa trong các nguồn thông tin tình báo để tránh việc vô tình phân giải hoặc liên kết đến những tài nguyên không mong muốn. Việc khôi phục các giá trị đã vô hiệu hóa chỉ nên được thực hiện trong những nền tảng tình báo mối đe dọa được kiểm soát, chẳng hạn như MISP, VirusTotal hoặc hệ thống SIEM của tổ chức.
Nhìn chung, phát hiện từ Varonis Threat Labs là lời nhắc nhở về tầm quan trọng của việc quản lý đặc quyền trong PostgreSQL. Những quyền hạn không trực tiếp cho phép kiểm soát máy chủ vẫn có thể trở thành mắt xích nguy hiểm khi kết hợp với các tính năng có sẵn của hệ thống. Vì vậy, bên cạnh việc chặn những phương pháp khai thác phổ biến, các tổ chức cần xem xét tổng thể cách phân bổ quyền, cơ chế thực thi tác vụ và khả năng truy cập tệp trong môi trường cơ sở dữ liệu.
Phát hiện này cho thấy những quyền hạn tưởng chừng không quá nguy hiểm khi đứng riêng lẻ vẫn có thể kết hợp thành rủi ro bảo mật nghiêm trọng, đặc biệt trong các dịch vụ cơ sở dữ liệu đám mây được quản lý. Trong mô hình này, nhà cung cấp chịu trách nhiệm kiểm soát máy chủ và hệ điều hành, trong khi khách hàng vẫn quyết định cách phân bổ quyền cho các tài khoản trong cơ sở dữ liệu.
Các nhà nghiên cứu thuộc Varonis Threat Labs đã xác định chuỗi leo thang đặc quyền này và báo cáo cho Snowflake. Theo Varonis, vấn đề đã được Snowflake khắc phục ở phía máy chủ trước khi nghiên cứu được công bố. Vì vậy, khách hàng sử dụng Snowflake Postgres không cần thực hiện thêm hành động nào đối với phát hiện cụ thể này.
Nhóm nghiên cứu lần đầu báo cáo chuỗi lỗi vào ngày 31/5/2026 và công bố thông tin vào ngày 17/10/2026.
Cách các quyền hạn trong PostgreSQL bị kết hợp để leo thang đặc quyền
Chuỗi tấn công được bắt đầu từ một tài khoản không phải quản trị viên có tên <span>snowflake_admin</span>. Quyền đáng chú ý nhất của tài khoản này là <span>CREATEROLE</span>, cho phép tạo và quản lý các vai trò trong cơ sở dữ liệu. Mặc dù quyền này không trực tiếp mang lại khả năng kiểm soát toàn bộ PostgreSQL, các nhà nghiên cứu đã tận dụng nó để mở ra những con đường leo thang đặc quyền thông qua các tính năng khác của hệ thống.Đầu tiên, nhóm nghiên cứu sử dụng <span>CREATEROLE</span> để cấp cho tài khoản khởi tạo hai vai trò tích hợp sẵn là <span>pg_read_all_data</span> và <span>pg_write_all_data</span>. Những vai trò này cung cấp quyền truy cập rộng vào dữ liệu trong các bảng cơ sở dữ liệu và danh mục hệ thống, tạo điều kiện để nhóm nghiên cứu thay đổi các mục trong <span>pg_cron</span> – tiện ích mở rộng của PostgreSQL dùng để lập lịch và tự động thực thi tác vụ.
Sau đó, các nhà nghiên cứu chỉnh sửa một tác vụ đã lên lịch để tác vụ này chạy với quyền hạn cao của tài khoản <span>postgres</span>. Khi tác vụ được thực thi, nó tạo ra một hàm <span>SECURITY </span><span>DEFINER</span>.
Chuỗi hoạt động như thế nào qua từng mắt xích (Nguồn – Varonis)
Điểm quan trọng của loại hàm này là nó chạy với quyền của chủ sở hữu hàm thay vì quyền của người gọi. Nhờ cơ chế đó, nhóm nghiên cứu có thể giành được quyền siêu người dùng PostgreSQL mà không cần sử dụng phương pháp thay đổi vai trò trực tiếp vốn đã bị Snowflake chặn.
Tuy nhiên, quyền siêu người dùng trong cơ sở dữ liệu vẫn chưa đồng nghĩa với việc kiểm soát được máy chủ bên dưới. Snowflake đã chặn nhiều phương pháp thông thường, bao gồm đọc tệp trên máy chủ, thay đổi thiết lập hệ thống hoặc chạy chương trình thông qua SQL.
Để vượt qua những hạn chế này, các nhà nghiên cứu phát hiện cơ chế <span>internal</span> của PostgreSQL có thể liên kết một tên hàm cơ sở dữ liệu mới với một hàm C đã tồn tại trong phần mềm máy chủ. Điều này giúp họ tạo lại khả năng truy cập đọc và ghi tệp vốn bị chặn, nhưng thông qua những tên hàm khác.
Khi đã có quyền truy cập tệp, nhóm nghiên cứu tiếp tục sử dụng tính năng đối tượng lớn (large objects) của PostgreSQL để ghi vào tệp cấu hình. Họ thay đổi thiết lập <span>archive_command</span>, vốn được sử dụng để thực thi lệnh shell khi PostgreSQL lưu trữ một phân đoạn nhật ký ghi trước (WAL) đã hoàn tất.
WAL là cơ chế ghi lại những thay đổi trong cơ sở dữ liệu trước khi các thay đổi đó được ghi hoàn toàn vào các tệp dữ liệu. Khi cấu hình <span>archive_command</span> được kích hoạt, lệnh shell do các nhà nghiên cứu thiết lập có thể được thực thi với tư cách tài khoản hệ thống <span>postgres</span>.
Đây là bước giúp chuỗi khai thác vượt khỏi phạm vi quyền hạn trong cơ sở dữ liệu và đạt đến khả năng thực thi lệnh của hệ điều hành. Nói cách khác, vấn đề không nằm ở một quyền riêng lẻ có thể trực tiếp chiếm quyền kiểm soát máy chủ, mà ở việc nhiều tính năng và cơ chế cấp quyền của PostgreSQL được kết hợp theo cách cho phép vượt qua các lớp bảo vệ.
Phát hiện này cho thấy việc chặn những chức năng SQL thường được sử dụng để thực thi lệnh hoặc truy cập tệp chưa chắc đã đủ an toàn nếu các khả năng tương tự vẫn có thể được gọi thông qua những con đường khác.
Rủi ro bảo mật và khuyến nghị phòng ngừa
Nếu kẻ tấn công có được quyền truy cập tương tự trong một môi trường thực tế, chúng có thể sửa đổi hoặc phá hủy các tệp cơ sở dữ liệu, can thiệp vào quá trình khôi phục dữ liệu hoặc thay đổi nhật ký được lưu trữ cục bộ.Một vấn đề khác là các hoạt động diễn ra ở cấp độ hệ điều hành có thể không xuất hiện đầy đủ trong những truy vấn SQL thông thường. Do đó, nhật ký kiểm toán của cơ sở dữ liệu có thể không phản ánh toàn bộ diễn biến của một cuộc tấn công, khiến việc phát hiện và điều tra sự cố trở nên khó khăn hơn.
Dù vậy, Varonis cho biết chuỗi khai thác được chứng minh trong môi trường thử nghiệm độc lập của nhóm nghiên cứu. Báo cáo không cho biết dữ liệu khách hàng của Snowflake đã bị truy cập thông qua kỹ thuật này. Đây là điểm cần phân biệt rõ: nghiên cứu chứng minh một con đường khai thác có thể xảy ra, nhưng không đồng nghĩa với việc đã có sự cố xâm nhập dữ liệu khách hàng được xác nhận.
Đọc mật khẩu và khóa thông qua trình bao bọc my_read_file được xây dựng lại của chúng tôi (Nguồn – Varonis)
Theo báo cáo, Snowflake đã tiếp nhận thông tin về lỗ hổng vào ngày 1/6 và xác nhận vào ngày 9/6 rằng khả năng thực thi mã cục bộ bên trong máy ảo Snowflake Postgres đã vượt qua ranh giới bảo mật. Công ty đã xử lý vấn đề ở phía máy chủ trước khi nghiên cứu được công khai.
Các nhà nghiên cứu cũng nhấn mạnh đây là một chuỗi khai thác dựa trên những hành vi và tính năng của PostgreSQL, chứ không phải một mẫu phần mềm độc hại mới. Phát hiện này đồng thời cho thấy rủi ro leo thang từ cơ sở dữ liệu lên máy chủ không phải vấn đề hoàn toàn mới, khi những trường hợp liên quan đến thực thi mã trong PostgreSQL và thực thi lệnh shell thông qua pgAdmin cũng từng được ghi nhận.
Đối với các tổ chức tự vận hành máy chủ PostgreSQL, Varonis đưa ra một số khuyến nghị nhằm giảm nguy cơ xảy ra những tình huống tương tự:
- Kiểm soát quyền <span>CREATEROLE</span>: Xem đây là quyền có rủi ro cao và loại bỏ khỏi các tài khoản ứng dụng nếu không thực sự cần thiết.
- Rà soát các tác vụ và hàm đặc quyền: Kiểm tra những công việc được lập lịch bằng <span>pg_cron</span> và các hàm <span>SECURITY </span><span>DEFINER</span> để phát hiện thay đổi bất thường.
- Hạn chế quyền tạo hàm: Kiểm soát chặt chẽ những tài khoản được phép tạo hàm <span>internal</span> hoặc hàm sử dụng ngôn ngữ C.
- Bảo vệ tệp cấu hình: Ngăn chặn các thay đổi trái phép đối với cấu hình PostgreSQL, đặc biệt là những thiết lập có thể kích hoạt lệnh shell.
- Giới hạn truy cập mạng: Duy trì sự cách ly của các dịch vụ cơ sở dữ liệu và hạn chế những kết nối mạng không cần thiết.
Báo cáo lưu ý rằng địa chỉ IP và tên miền có thể được cố ý vô hiệu hóa trong các nguồn thông tin tình báo để tránh việc vô tình phân giải hoặc liên kết đến những tài nguyên không mong muốn. Việc khôi phục các giá trị đã vô hiệu hóa chỉ nên được thực hiện trong những nền tảng tình báo mối đe dọa được kiểm soát, chẳng hạn như MISP, VirusTotal hoặc hệ thống SIEM của tổ chức.
Nhìn chung, phát hiện từ Varonis Threat Labs là lời nhắc nhở về tầm quan trọng của việc quản lý đặc quyền trong PostgreSQL. Những quyền hạn không trực tiếp cho phép kiểm soát máy chủ vẫn có thể trở thành mắt xích nguy hiểm khi kết hợp với các tính năng có sẵn của hệ thống. Vì vậy, bên cạnh việc chặn những phương pháp khai thác phổ biến, các tổ chức cần xem xét tổng thể cách phân bổ quyền, cơ chế thực thi tác vụ và khả năng truy cập tệp trong môi trường cơ sở dữ liệu.
