Messages posted by: manthang

Có 2 trong 11 reason code cho việc thu hồi certificate là

 privilegeWithdrawn (9):
 aACompromise (10):

là em vẫn chưa tìm thấy ý nghĩa của nó, ngay cả tìm trong RFC 5280 cũng không thấy đề cập. nhờ mọi người ai biết mách nước hộ :p

Ngày nay, hệ thống giám sát đóng một vai trò quan trọng giúp theo dõi, kiểm tra sức khỏe, cung cấp thông tin và đưa ra cảnh báo khi có vấn đề xảy ra với các thành phần trong hạ tầng, ứng dụng công nghệ thông tin của tổ chức. Một hệ thống giám sát tốt cần có khả năng phát hiện nhanh chóng và chính xác những sự cố xảy ra và kịp thời gửi thông báo rõ ràng qua nhiều phương tiện như màn hình, email, tin nhắn tới người quản trị hệ thống.

Việc triển khai hệ thống cảnh báo qua SMS này đã được mình thực hiện thành công trên cả môi trường ảo hóa lẫn máy chủ thực và bước đầu làm việc tốt với thiết bị D-Com 3G của Viettel.

1) GIỚI THIỆU TỔNG QUAN

Hệ thống giám sát và cảnh báo qua SMS được triển khai trong bài này về cơ bản bao gồm các thành phần và hoạt động được mô tả như hình dưới đây:

• Máy Monitor sẽ gồm:

- Phần mềm Nagios giúp giám sát các bộ phận, thông số quan trọng của hạ tầng CNTT như: system metric (CPU load, RAM usage, disk usage, loaded processes, v.v..), network protocol (HTTP, SSH, FTP, SMTP, IMAP, POP3, v.v..), application (mail, web, database v.v..), service (DNS, DHCP, v.v..), server (Windows, UNIX, v.v..), network device (router, switch, firewall, v.v..).

- Phần mềm Gammu giúp truy cập tới các thiết bị điện thoại (trong đó có USB 3G), điều khiển việc gửi và nhận SMS cùng nhiều chức năng khác về quản lý cuộc gọi và danh bạ.

- Thiết bị D-Com 3G đóng vai trò làm GSM modem, liên lạc với nhà mạng di động để thực hiện việc gửi tin nhắn SMS.

• Khi có các sự kiện ngưng trễ hoặc khôi phục hoạt động từ các thành phần được giám sát, Nagios sẽ tự động tạo ra các thông báo. Nội dung của thông điệp cảnh báo này sẽ được truyền cho Gammu và từ đó đẩy tới thiết bị USB 3G rồi gửi tới số điện thoại của người quản trị.

Các phần tiếp theo sẽ giải trình các bước để thực hiện cài đặt, cấu hình và vận hành hệ thống cảnh báo qua SMS này.

2) CÀI ĐẶT VÀ CẤU HÌNH HỆ THỐNG CẢNH BÁO QUA SMS

2.1) Yêu cầu và chuẩn bị

• Một Nagios monitoring server

• Một USB 3G, ở đây sử dụng thiết bị D-Com 3G của Viettel.

• Gói mã nguồn của Gammu, tải về phiên bản 1.32.0 tại địa chỉ:
http://sourceforge.net/projects/gammu/files/gammu/1.32.0/gammu-1.32.0.tar.bz2

o Các gói phụ thuộc bắt buộc cho Gammu là: CMake, pkg-config
o Các gói phụ thuộc tùy chọn giúp mở rộng tính năng cho Gammu là: Bluez-libs, libusb-1.0, libCURL, libiconv, Gettext, MySQL, PostgreSQL, unixODBC, libdbi, Python SQLite + libdbi-drivers + SQLite.

• Nếu máy Nagios chưa nhận ra D-Com 3G như là một USB modem thì cần cài thêm gói usb_modeswitch để chuyển từ chế độ storage sang modem. Tải về mã nguồn của phiên bản 1.2.3 tại:
http://www.draisberghof.de/usb_modeswitch/usb-modeswitch-data-20120531.tar.bz2
http://www.draisberghof.de/usb_modeswitch/usb-modeswitch-1.2.3.tar.bz2

o Các gói phụ thuộc cần thiết cho usb_modeswitch là: libusb-devel, tcl

• Các gói make, gcc để phục vụ quá trình biên dịch và cài đặt chương trình từ mã nguồn.

• Cần tới quyền root trong quá trình cài đặt và cấu hình hệ thống.

2.2) Các bước thực hiện

2.2.1 Kết nối USB 3G tới máy Nagios

- Kiểm tra xem máy Nagios đã nhận ra USB 3G là một GSM modem hay chưa. Gõ lệnh sau:
Code:

# dmesg | grep GSM

Nếu thấy output như dưới đây thì ta chuyển qua bước 2.2.2 để làm tiếp

Code:

USB Serial support registered for GSM modem (1-port)
option 1-1:1.0: GSM modem (1-port) converter detected
usb 1-1: GSM modem (1-port) converter now attached to ttyUSB0
....

(để ý là tập tin đại diện cho thiết bị là /dev/ttyUSB0)

- Nếu output trống rỗng thì cần thêm gói usb_modeswitch. Trình tự cài đặt như sau:
Code:

# tar jxf usb-modeswitch-data-20120531.tar.bz2
# cd usb-modeswitch-data-20120531
# make install
# tar jxf usb-modeswitch-1.2.3.tar.bz2
# cd usb-modeswitch-1.2.3
# make install

2.2.2 Biên dịch và cài đặt Gammu

- Giải nén gói mã nguồn của Gammu:
Code:

# tar jxvf gammu-1.32.0.tar.bz

2

- Chuyển vào thư mục vừa được giải nén ở trên:
Code:

# cd gammu-1.32.0

- Chạy các lệnh sau để cấu hình, biên dịch và cài đặt Gammu:
Code:

# ./configure
# make
# make install

- Kiểm tra bằng lệnh:
Code:

# gammu

- Nếu nhận được thông báo lỗi liên quan tới library thì chạy 2 dòng lệnh sau:
Code:

# ln -s /usr/local/lib/libGammu.so.7 /usr/lib/libGammu.so.7
# ln -s /usr/local/lib/libgsmsd.so.7 /usr/lib/libgsmsd.so.7

2.2.3 Cấu hình Gammu để gửi SMS

- Tạo tập tin chứa thông số cấu hình của USB 3G cho Gammu:
Code:

# vi /etc/gammurc

Với nội dung mẫu như sau:
Code:

[gammu]
port = /dev/ttyUSB0 //đường dẫn tới tập tin device của thiết bị
connection = at19200 //loại kết nối, tương thích với tập lệnh AT

Ngoài ra, có thể sử dụng lệnh sau để cấu hình dễ dàng cấu hình các thông số bằng giao diện đồ họa:
Code:

# gammu-config

- Xác nhận USB 3G đã được nhận dạng thành công:
Code:

# gammu --identify
Device : /dev/ttyUSB3
Manufacturer : ZTE CORPORATION
Model : unknown (MF190S)
Firmware : BD_MF190SV1.0.0B01
IMEI : 864482000915806

Ngoài ra còn có 2 lệnh sau để theo dõi hoạt động của thiết bị cũng như thông tin về mạng di động:
Code:

# gammu –-monitor
# gammu –-networkinfo

- Nagios chạy với quyền của user nagios, vậy nên nếu muốn Nagios gửi được SMS thì user nagios phải có quyền truy cập tới các tập tin device, config và binary của Gammu. Chạy các lệnh sau để gán các quyền thích hợp đó cho user nagios:
Code:

# cp /etc/gammurc /home/nagios/.gammurc
# chown nagios.nagios /home/nagios/.gammurc
# chmod 4755 /usr/bin/gammu
# usermod -a -G dialout nagios
# usermod -a -G dialout apache

- Chuyển qua user nagios và thử gửi một SMS mẫu:
Code:

# su - nagios
$ echo "test SMS nagios" | gammu --sendsms TEXT +84932xxxxxx

Code:

If you want break, press Ctrl+C...
Sending SMS 1/1....waiting for network answer..OK, message reference=181

Nếu số điện thoại trong câu lệnh ở trên nhận được thông điệp “test SMS nagios” thì việc cấu hình để Gammu gửi đi SMS đã thành công. Tiếp theo sẽ cấu hình cho Nagios.

2.2.4 Cấu hình Nagios để gửi SMS theo nhóm

Phần này sẽ trình bày các bước để khởi tạo và định nghĩa các contact cho những cá nhân và nhóm sẽ nhận được cảnh báo khi một máy tính, thiết bị hay dịch vụ nào đó trong hệ thống xảy ra sự cố.

- Đầu tiên, cần thêm vào 2 câu lệnh để thực hiện việc gửi SMS tới các số điện thoại của các contact được định nghĩa trong tập tin contacts.cfg. Mở tập tin /usr/local/nagios/etc/objects/commands.cfg và bổ sung nội dung mẫu sau:

Code:

# 'notify-host-by-sms' command definition
define command{
command_name notify-host-by-sms
command_line /usr/bin/printf "%b" "*** Nagios ***\n Notification Type: $NOTIFICATIONTYPE$\n Host: $HOSTNAME$\n State: $HOSTSTATE$\n Address: $HOSTADDRESS$\n Info: $HOSTOUTPUT$\n Date/Time: $LONGDATETIME$" | /usr/local/bin/gammu --sendsms TEXT $CONTACTPAGER$
}
# 'notify-service-by-sms' command definition
define command{
command_name notify-service-by-sms
command_line /usr/bin/printf "%b" "*** Nagios ***\n Notification Type: $NOTIFICATIONTYPE$\n Service: $SERVICEDESC$\n Host: $HOSTALIAS$\n Address: $HOSTADDRESS$\n State: $SERVICESTATE$\n Date/Time: $LONGDATETIME$\n Additional Info: $SERVICEOUTPUT$" | /usr/local/bin/gammu --sendsms TEXT $CONTACTPAGER$

- Sau đó, tùy chỉnh lại mẫu generic-contact mà Nagios cung cấp sẵn sau khi cài đặt để các contact được tạo ở bước sau sẽ nhận được thông báo qua SMS. Mở tập tin /usr/local/nagios/etc/objects/templates.cfg và sửa mục generic-contact như sau:

Code:

define contact{
name generic-contact
service_notification_period 24x7
host_notification_period 24x7
service_notification_options w,u,c,r
host_notification_options d,u,r
service_notification_commands notify-service-by-sms
,notify-service-by-email
host_notification_commands notify-service-by-sms
,notify-host-by-email
register 0
}

- Tiếp đến, thêm mới các contact cho những người muốn nhận thông báo qua email và SMS từ Nagios. Mở tập tin /usr/local/nagios/etc/objects/contacts.cfg và bổ sung nội dung mẫu sau:

Code:

define contact{
contact_name manthang
use generic-contact
alias Thang Man (Sysadmin)
email <a href="mailto:manthang@gmail.com">manthang@gmail.com</a>
pager +84983xxxxxx //thay bằng sđt thực
}
define contact{
contact_name hoangbao
use generic-contact
alias Bao Hoang (Database)
email <a href="mailto:hoangbao@gmail.com">hoangbao@gmail.com</a>
pager +84123xxxxxx //thay bằng sđt thực
}

- Giờ ta sẽ gom nhóm các contact để gửi các thông báo thích hợp. Ví dụ, các thông báo liên quan tới thiết bị mạng chỉ được gửi tới nhóm network, thông báo liên quan tới máy chủ sẽ được gửi tới nhóm system, thông báo liên quan tới CSDL thì gửi tới nhóm database, v.v… Cũng trong tập tin contacts.cfg trên, tạo thêm các contactgroup theo mẫu sau:

Code:

define contactgroup{
contactgroup_name db-admins
alias Database Administrators
members hoangbao,manthang
}
define contactgroup{
contactgroup_name unix-admins
alias Linux System Administrator
members manthang
}

- Việc khai báo các contact ở trên không có nghĩa là họ sẽ nhận được thông báo mà ta cần liên kết các contactgroup tới một dịch vụ hoặc máy tính nào đó cần giám sát. Ví dụ, trong thư mục /usr/local/nagios/etc/objects/ tạo ra 2 tập tin email-server.cfg và db-server.cfg rồi định nghĩa như sau:

Code:

// trong email-server.cfg
define host{
use linux-server
host_name email-server
alias Zimbra Server
address 192.168.1.16
contact_groups unix-admins //nhóm Unix sẽ nhận notify
}
// trong db-server.cfg
define service{
use generic-service
host_name mysql-db
service_description MySQL Database Status
contact_groups db-admins //nhóm DB sẽ nhận notify
check_command check_nrpe!check_mysql_db
}

- Kế đến, thêm 2 object trên vào tập tin cấu hình chính của Nagios bằng cách mở tập tin /usr/local/nagios/etc/nagios.cfg và thêm vào 2 dòng sau:
Code:

cfg_file=/usr/local/nagios/etc/objects/email-server.cfg
cfg_file=/usr/local/nagios/etc/objects/db-server.cfg

- Cuối cùng, chạy các lệnh sau để kiểm tra cấu hình và khởi động lại Nagios
Code:

# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
# /etc/init.d/nagios restart

Giờ thử ngưng hoạt động của một máy tính, thiết bị hay dịch vụ nào đó thì sau một khoảng thời gian quy định trước, Nagios sẽ kiểm tra trạng thái và gửi đi SMS và email thông báo tình trạng của chúng tới số điện thoại và hộp thư của người quản trị.

3 HƯỚNG PHÁT TRIỂN

Cải tiến hệ thống giám sát và cảnh báo dùng Nagios và Gammu để ngoài gửi thông tin, cảnh báo thì hệ thống còn có thể nhận các xác nhận, chỉ lệnh từ điện thoại của người quản trị.

4 THAM KHẢO

[1] Sébastien Wains. Nagios + SMS notifications with Gammu and Siemens MC35i. Xem tại: http://blog.wains.be/2010/01/05/nagios-sms-notifications-gammu-siemensmc35i, 2010.

[2] Centreon Wiki Team. How To Send SMS With Gammu. Xem tại: http://en.doc.centreon.com/HowToSendSMSWithGammu, 2011.

[3] Tentang Saya. Install and configure gammu in CentOS 6. Xem tại: http://irhamnurhalim.wordpress.com/2012/02/09/install-dan-configure-gammu-di-centos-6, 2012

[4] Matt Bottrell. Nagios 2-way alerting via SMS. Xem tại: http://matt.bottrell.com.au/archives/170-Nagios-2-way-alerting-via-SMS-Part-1.html, 2008

1) Giới thiệu

Bài này sẽ trình bày việc cấu hình cho Nagios để giám sát dịch vụ Oracle Database có đang hoạt động hay không (up/down). Dưới đây là 2 trong vài cách thức để thực hiện:

-- Sử dụng plugin check_tcp có sẵn trong Nagios để kiểm tra xem cổng mạng (port) của database có được mở và ở trạng thái lắng nghe, chờ kết nối hay không. Hầu hết các database đều mở một TCP port để cung cấp khả năng truy cập qua mạng cho các ứng dụng. Đối với Orace thì cổng mặc định khi cài đặt là TCP 1521.

Tuy nhiên, nếu các ứng dụng đó cùng nằm trên một máy chủ với database thì việc mở thêm một port cho các kết nối mạng là không cần thiết vì chúng sẽ liên lạc với nhau nhờ cơ chế IPC (Interprocess Communication). Nhưng điều này lại gây trở ngại cho việc giám sát từ xa thông qua việc kiểm tra port mạng của database.

Ngoài ra thì với Oracle, các kết nối mạng tới database được xử lý bởi một tiến trình listener tách biệt với tiến trình chính của Oracle. Nên nếu chỉ kiểm tra port đang up/down thôi thì chưa đủ vì có thể listener ngưng chạy nhưng hoạt động của Oracle vẫn bình thường và ngược lại.

-- Sử dụng plugin check_oracle có sẵn trong Nagios để kiểm tra thông qua một thao tác đăng nhập từ xa thực sự vào database. Cách này không những xác định được port đang mở hay không mà có cho biết một thực thể (instance) của Orace đang chạy và có thể đăng nhập vào.

Yêu cầu ở đây là máy Nagios cần được cài chương trình Oracle client hoặc tối thiểu là bộ thư viện Oracle instantclient và câu lệnh sqlplus. Ngoài ra, cũng cần tạo thêm trong Oracle một tài khoản dành riêng với các quyền bị giới hạn chặt chẽ chỉ đủ để kiểm tra đăng nhập vào database.

Thử nghiệm dưới đây sử dụng addon NRPE để thực thi plugin check_tcp trên máy chủ Oracle Database.

2) Yêu cầu và chuẩn bị

+ Một máy chủ chạy Nagios có sẵn plugin NRPE.
+ Một máy chủ chạy Oracle Database với port của listener là 1521 và được cài daemon NRPE

Xem thêm 2 bài sau:
http://manthang.wordpress.com/2012/07/06/giam-sat-may-linuxunix-su-dung-plugin-nrpe-cho-nagios-tren-centos-6-2/
và
http://manthang.wordpress.com/2012/06/27/cai-dat-nagios-tren-centos-6-2/

3) Các bước thực hiện

Thực hiện trên máy Oracle Database

1. Mở tập tin cấu hình cho NRPE là /usr/local/nagios/etc/nrpe.cfg và thêm vào định nghĩa cho câu lệnh check_tcp như mẫu sau:

Code:

command[check_tcp]=/usr/local/nagios/libexec/check_tcp –p 1521

2. Nếu đang chạy daemon NRPE dưới dịch vụ xinetd thì không cần khởi động lại daemon này và ngược lại, cần khởi động lại NRPE nếu nó chạy độc lập.

Thực hiện trên máy Nagios

1. Định nghĩa một service mới để kiểm tra listener port trên máy Orace Database bằng cách tạo mới một tập tin /usr/local/nagios/etc/objects/oracle.cfg với nội dung mẫu như sau:

Code:

define host{
use linux-server
host_name oracle-db
alias Oracle DB 11g
address 192.168.1.14
}
//kiểm tra listener port của Oracle
define service{
use generic-service
host_name oracle-db
service_description Oracle Listener Port
check_command check_nrpe!check_tcp
}

2. Thêm object trên vào tập tin cấu hình chính của Nagios bằng cách mở tập tin /usr/local/nagios/etc/nagios.cfg và thêm vào dòng sau

Code:

cfg_file=/usr/local/nagios/etc/objects/oracle.cfg

Kiểm tra lại các tập tin cấu hình và khởi động lại Nagios

Code:

# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
# /etc/init.d/nagios restart

Tham khảo:
http://nagios.frank4dd.com/howto/db-monitoring.htm

–manthang

CA là một thành phần thiết yếu trong bất cứ thiết kế PKI nào. Đối với giải pháp PKI của Microsoft thì một CA là máy tính chạy hệ điều hành Windows Server (2003 hoặc 2008) được cài đặt dịch vụ Certificate Services. Nó thực thi các nhiệm vụ sau:

-- Xác minh nhận dạng của đối tượng yêu cầu chứng chỉ: CA phải thẩm định nhận dạng của đối tượng đầu cuối (như người dùng, máy tính, thiết bị mạng, dịch vụ, v.v..) trước khi cấp chứng chỉ cho họ. Điều này giúp đảm bảo đối tượng phải có đủ các quyền hạn cần thiết mới có thể yêu cầu CA cấp cho một loại chứng chỉ nào đó. Ngoài ra, tổ chức quản lý chứng chỉ có thể gặp mặt và phỏng vấn trực tiếp người yêu cầu.

-- Cấp phát chứng chỉ cho đối tượng yêu cầu: sau khi xác minh được nhận dạng của đối tượng, CA cấp loại chứng chỉ được yêu cầu cho đối tượng đó. Mỗi loại chứng chỉ sẽ có nội dung và mục đích sử dụng khác nhau. Ví dụ, nếu yêu cầu cấp chứng chỉ cho IPSec thì kết quả là chứng chỉ này chỉ có thể được dùng bởi máy chủ hoặc máy khách để xác thực các điểm đầu cuối trên kênh truyền thông được bảo vệ bởi IPSec.

-- Quản lý việc thu hồi chứng chỉ: CA sẽ định kỳ phát hành CRL sau một khoảng thời gian định trước. CRL chứa danh sách số thứ tự (serial number) của các chứng chỉ đã bị thu hồi và các mã số lý do (reason code) cho việc thu hồi.

Ở các tổ chức lớn thì PKI thường được triển khai với nhiều CA. Các CA được tổ chức thành một cấu trúc phân cấp bao gồm duy nhất một Root CA và một vài Subordinate CA như được thể hiện trong hình dưới đây:

Như đã giải thích ở phần 2 (*), mô hình CA phân cấp (hay Hierarchical PKI) này có khả năng mở rộng cao và an toàn hơn khi mà các non-issuing CA (ở đây là Root CA và các Intermediate CA), là các CA không trực tiếp cấp chứng chỉ cho các đối tượng đầu cuối thường sẽ không được kết nối vào mạng. Vì vậy mà chúng được bảo vệ trước các cuộc tấn công thông qua môi trường mạng. Ngoài ra thì mô hình này cũng cho phép việc ủy quyền, phân tách vai trò quản lý các CA cho các bộ phận khác nhau trong tổ chức.

Đây là mô hình rất phổ biến và được áp dụng bởi tất cả các nhà cung cấp dịch vụ chứng chỉ số hàng đầu thế giới như RSA, Thawte, VeriSign. Nó cũng được hỗ trợ bởi hầu hết các ứng dụng và thiết bị mạng.

Root CA

Nằm ở đỉnh cao nhất trong mô hình CA phân cấp, Root CA là điểm tin cậy cho tất cả các chứng chỉ được cấp bởi các CA khác trong mô hình. Điều này có nghĩa là một chứng chỉ được coi là tin cậy chỉ khi nó đó được kiểm chứng xuyên qua chuỗi chứng chỉ với điểm kết thúc tại Root CA.

Root CA tự cấp chứng chỉ cho chính nó và lúc này các trường Issuer Name và Subject Name trong chứng chỉ có cùng tên phân biệt (distinguished name). Cách duy nhất để xác minh chứng chỉ của Root CA có hợp lệ hay không là kiểm tra xem chứng chỉ đó có nằm trong Trusted Root Store hay không.

Root CA có thể cấp chứng chỉ cho các đối tượng đầu cuối nhưng thường nó chỉ cấp cho các CA khác. Khi thực hiện cấp chứng chỉ cho các thực thể, Root CA sẽ sử dụng khóa bí mật của nó để ký lên các chứng chỉ đó để chống lại các hành động thay đổi nội dung và chỉ ra rằng chứng chỉ được cấp bởi Root CA.

Intermediate CA

Trong mô hình CA phân cấp thì một Intermediate CA là CA cấp dưới của một CA khác. Nó sẽ cấp chứng chỉ cho các CA là cấp dưới của nó. Intermediate CA có thể nằm tại bất kỳ cấp độ nào trong mô hình phân cấp ngoại trừ vị trí của Root CA.

CA mà cấp chứng chỉ cho một CA khác thường được gọi là parent CA và Intermediate CA cũng được gọi là Subordinate CA.

Policy CA

Là một dạng đặc biệt của Intermediate CA, Policy CA mô tả các chính sách và thủ tục mà tổ chức cần triển khai để xác minh nhận dạng của chủ thể nắm giữ chứng chỉ và bảo đảm an toàn cho các CA. Một Policy CA sẽ chỉ cấp chứng chỉ cho các CA khác trông mô hình phân cấp. Tất cả các CA (ngoại trừ Root CA) sẽ là cấp dưới của Policy CA và tuân theo các chính sách và thủ tục được định nghĩa tại Policy CA.

Nếu tổ chức phải triển khai nhiều chính sách và thủ tục khác nhau cho việc cấp chứng chỉ thì cần thiết phải có nhiều Policy CA tồn tại như được thể hiện trong hình dưới đây:

Trong ví dụ này, có hai Policy CA. Một Internal Policy CA định nghĩa các chính sách và thủ tục được dùng để xác minh nhận dạng của các đối tượng yêu cầu cấp chứng chỉ, sẽ được hai Issuing CA (America CA và Europe CA) là nằm ngay dưới nó tuân theo. Một External Policy CA định nghĩa các chính sách và thủ tục được dùng để xác minh nhận dạng và bảo đảm an toàn cho quá trình cấp chứng chỉ cho các đối tượng không nằm trong nội bộ của tổ chức, sẽ được Customer CA nằm ngay dưới nó tuân theo.

Issuing CA

Thường nằm tại bậc thứ 3 trong mô hình phân cấp, một Issuing CA sẽ cấp chứng chỉ cho các đối tượng đầu cuối.

Như đã nói ở trên, Issuing CA cần tuân theo bất kỳ chính sách và thủ tục nào được định nghĩa bởi một Policy CA mà nằm giữa nó và Root CA. Issuing CA cũng có thể nằm ở bậc thứ 2 trong mô hình phân cấp và khi đó nó đóng vai trò của cả Policy CA và Issuing CA thông thường. Nó sẽ tự thẩm định và tuân theo các chính sách và thủ tục của chính nó.

Xem thêm:
(*) /hvaonline/posts/list/41926.html

–manthang

Chứng chỉ số là thành phần làm nền tảng cho hoạt động của PKI. Nó là tài liệu điện tử giúp nhận dạng và đại diện cho người dùng, tổ chức, máy tính, thiết bị mạng hoặc dịch vụ nào đó. Nó được phát hành bởi một Certification Authority (CA) và được liên kết với một cặp khóa công khai và khóa bí mật.

Một chứng chỉ là một tập tin được ký số, có kích thước từ 2KB đến 4KB và thường bao gồm các thông tin cơ bản sau:

-- Thông tin về người dùng, máy tính, thiết bị mạng, v.v.. mà nắm giữ khóa bí mật tương ứng với chứng chỉ được cấp phát. Người dùng, máy tính hoặc thiết bị mạng này được nhắc tới như là chủ thể (subject) của chứng chỉ.

-- Thông tin về CA phát hành chứng chỉ.

-- Khóa công khai tương ứng với khóa bí mật được liên kết với chứng chỉ.

-- Tên của các thuật toán để mã hóa và thuật toán tạo chữ ký số cho chứng chỉ.

-- Một danh sách các phần mở rộng (extension) cho loại chứng chỉ X.509 version 3.

-- Thông tin giúp xác định trạng thái thu hồi (revocation) và tính hiệu lực của chứng chỉ (như ngày phát hành và ngày hết hạn).

CA phải bảo đảm nhận dạng của đối tượng yêu cầu là xác thực trước khi cấp chứng chỉ. Việc xác minh nhận dạng có thể được thực hiện dựa trên các giấy phép an ninh (security credential) của đối tượng hoặc thông qua cuộc gặp mặt và trao đổi trực tiếp với người yêu cầu. Sau khi nhận dạng được kiểm chứng là hợp lệ, CA sẽ cấp chứng chỉ được ký số bởi khóa bí mật của nó cho họ. Chữ ký số này cho biết nguồn gốc của chứng chỉ (do CA nào cấp), đảm bảo khóa công khai là thuộc về chủ thể của chứng chỉ và giúp phát hiện những thay đổi, giả mạo nếu có trong nội dung của chứng chỉ.

Có 3 phiên bản của chứng chỉ số được dùng trong một hệ tầng PKI là:

-- Chứng chỉ X.509 version 1
-- Chứng chỉ X.509 version 2
-- Chứng chỉ X.509 version 3

X.509 version 1

Được định nghĩa vào năm 1988, X.509 version 1 giờ đây hầu như không còn được sử dụng nữa. Định dạng của loại chứng chỉ này được thể hiện như hình dưới đây:

Một chứng chỉ X.509 version 1 bao gồm các trường sau:

Version: chứa giá trị cho biết đây là chứng chỉ X.509 version 1

Serial Number: cung cấp một mã số nhận dạng duy nhất cho mỗi chứng chỉ được phát hành bởi CA

CA Signature Algorithm: tên của thuật toán mà CA sử dụng để ký lên nội dung của chứng chỉ số.

Issuer Name: tên phân biệt (distinguished name) của CA phát hành chứng chỉ. Thường thì tên phân biệt này được biểu diễn theo chuẩn X.500 hoặc định dạng theo đặc tả của X.509 và RFC 3280.

Validity Period: khoảng thời gian mà chứng chỉ được xem là còn hiệu lực, bao gồm 2 trường là: Valid From và Valid To.

Subject Name: tên của máy tính, người dùng, thiết bị mạng sở hữu chứng chỉ. Thường thì tên chủ thể này được biểu diễn theo chuẩn X.500 hoặc định dạng theo đặc tả của X.509, nhưng cũng có thể bao gồm các định dạng tên khác như được mô tả trong RFC 822.

Subject Public Key Info: khóa công khai của đối tượng nắm giữ chứng chỉ. Khóa công khai này được gửi tới CA trong một thông điệp yêu cầu cấp chứng chỉ (certificate request) và cũng được bao gồm trong nội dung của chứng chỉ được phát hành sau đó. Trường này cũng chứa nhận dạng của thuật toán được dùng để tạo cặp khóa công khai và khóa bí mật được liên kết với chứng chỉ.

Signature Value: chứa giá trị của chữ ký.

Các trường Issuer Name và Subject Name được cấu trúc để các chứng chỉ có thể được tổ chức thành một chuỗi các chứng chỉ mà bắt đầu bằng chứng chỉ được cấp cho người dùng, máy tính, thiết bị mạng, hoặc dịch vụ và kết thúc bằng chứng chỉ gốc của CA.

X.509 version 2

Mặc dù chứng chỉ X.509 version 1 cung cấp khá đầy đủ những thông tin cơ bản về người nắm giữa chứng chỉ nhưng nó lại có ít thông tin về tổ chức cấp phát chứng chỉ khi chỉ bao gồm Issuer Name, CA Signature Algorithm và Signature Value. Điều này không giúp dự phòng trong trường hợp CA được thay mới.

Khi chứng chỉ của CA được thay mới, trường Issuer Name trong cả 2 chứng chỉ mới và cũ đều như nhau. Tương tự, có thể có một tổ chức khác muốn tạo một CA có trường Issuer Name trong chứng chỉ giống như vậy. Giải quyết vấn đề này để có thể sử dụng lại Issuer Name thì chứng chỉ X.509 version 2 đã được giới thiệu vào năm 1993. Trong định dạng của nó có thêm 2 trường mới như được thể hiện trong hình dưới đây:

Hai trường mới được bổ sung là:

Issuer Unique ID: là một trường không bắt buộc, chứa chuỗi giá trị ở hệ 16, mang tính duy nhất và dành để nhận dạng CA. Khi CA thay mới chứng chỉ của chính nó, một Issuer Unique ID mới được khởi tạo cho chứng chỉ đó.

Subject Unique ID: là một trường không bắt buộc, chứa chuỗi giá trị ở hệ 16, mang tính duy nhất và dùng để nhận dạng chủ thể của chứng chỉ. Nếu chủ thể này cũng chính là CA thì trường này sẽ giống với Issuer Unique ID.

Ngoài việc đưa vào 2 trường mới ở trên thì trường Version trong chứng chỉ X.509 version 2 có giá trị là 2 để chỉ ra phiên bản của chứng chỉ.

Các trường Issuer Unique ID và Subject Unique ID đã cải tiến quá trình xâu chuỗi chứng chỉ. Giờ đây việc tìm kiếm chứng chỉ của của CA sẽ là so khớp Issuer Name trong chứng chỉ được cấp phát với Subject Name trong chứng chỉ của CA và thực hiện thêm một bước kiểm tra thứ hai là so khớp Issuer Unique ID trong chứng chỉ được cấp phát với Subject Unique ID trong chứng chỉ của CA.

Bước so khớp thứ hai này cho phép phân biệt giữa các chứng chỉ của cùng một CA khi CA đó làm mới lại chứng chỉ của chính nó. Cách này cũng giúp phân biệt giữa các CA khác nhau nhưng trùng Subject Name.

Mặc dù định dạng X.509 version có cải tiến hơn version 1 nhưng chuẩn này cũng không còn được áp dụng rộng rãi. Và thực tế thì trong RFC 3280 đã khuyến cáo là bỏ qua việc sử dụng 2 trường mới trên của X.509 version 2 do lo ngại có thể có sự xung đột xảy ra nếu như hai chứng chỉ có cùng Subject Name và Subject Unique ID.

X.509 version 3

Được ra đời vào năm 1996, định dạng X.509 version 3 được bổ sung thêm các phần mở rộng (extension) để khắc phục các vấn đề liên quan tới việc so khớp Issuer Unique ID và Subject Unique ID cũng như là các vấn đề về xác thực chứng chỉ. Một chứng chỉ X.509 version 3 co thể chứa một hoặc nhiều extension, như được thể hiện trong hình dưới đây:

Mỗi extension trong chứng chỉ X.509 version 3 gồm 3 phần:

Extension Identifier: là một mã nhận dạng đối tượng (Object Identifier – OID) cho biết kiểu định dạng và các định nghĩa của extension.

Criticality Flag: là một dấu hiệu cho biết thông tin trong extension có quan trọng (critical) hay không. Nếu một ứng dụng không thể nhận diện được trạng thái critical của extension hoặc extension không hề chứa giá trị nào thì chứng chỉ đó không thể được chấp nhận hoặc được sử dụng. Nếu mục criticality flag này không được thiết lập thì một có thể sử dụng chứng chỉ ngay cả khi ứng dụng đó không nhận diện được extension.

Extension Value: là giá trị được gán cho extension. Nó phụ thuộc vào từng extension cụ thể.

Trong một chứng chỉ X.509 version 3, các extension sau có thể có là:

Authority Key Identifier: extension này có thể chứa một hoặc hai giá trị, chúng có thể là:

+ Subject Name của CA và Serial Number của chứng chỉ của CA mà đã cấp phát chứng chỉ này.
Giá trị băm của khóa công khai của chứng chỉ của CA mà đã cấp phát chứng chỉ này.

+ Subject Key Identifier: extension này chứa giá trị băm của khóa công khai của chứng chỉ.

Key Usage: một CA, người dùng, máy tính, thiết bị mạng hoặc dịch vụ có thể sở hữu nhiều hơn một chứng chỉ. Extension này định nghĩa các dịch vụ bảo mật mà một chứng chỉ có thể cung cấp như:

+ Digital Signature: khóa công khai có thể được dùng để kiểm tra chữ ký. Khóa này cũng được sử dụng để xác thực máy khách và xác minh nguồn gốc của dữ liệu.

+ Non-Repudiation: khóa công khai có thể được dùng để xác minh nhận dạng của người ký, ngăn chặn người ký này từ chối rằng họ không hề ký lên thông điệp hoặc đối tượng nào đó.

+ Key Encipherment: khóa công khai có thể được dùng để trao đổi khóa, vú dụ như đối xứng (hoặc khóa phiên). Giá trị này được dùng khi một khóa RSA được dùng cho việc quản lý khóa.

+ Data Encipherment: khóa công khai có thể được dùng để mã hóa dữ liệu một cách trực tiếp thay vì phải trao đổi một khóa đối xứng (hay khóa phiên) để mã hóa dữ liệu.

+ Key Agreement: khóa công khai có thể được dùng để trao đổi khóa, ví dự như khóa đối xứng. Giá trị này được dùng khi một khóa Diffie-Hellman được dùng cho việc quản lý khóa.

+ Key Cert Sign: khóa công khai có thể được dùng để kiểm tra chữ ký của chứng chỉ số.
CRL Sign: khóa công khai có thể được dùng để kiểm tra chữ ký của CRL (danh sách chứa các chứng chỉ bị thu hồi).

+ Encipher Only: giá trị này được dùng kết hợp với các extension Key Agreement và Key Usage. Kết quả là khóa đối xứng chỉ có thể được dùng để mã hóa dữ liệu.

+ Decipher Only: giá trị này được dùng kết hợp với các extension Key Agreement và Key Usage. Kết quả là khóa đối xứng chỉ có thể được dùng để mã hóa dữ liệu.

Private Key Usage Period: extension này cho phép khóa bí mật có khoảng thời gian hiệu lực khác so với khoảng thời gian hiệu lực của chứng chỉ. Giá trị này có thể được đặt ngắn hơn so với khoảng thời gian hiệu lực của chứng chỉ. Điều này giúp khóa bí mật có thể được dùng để ký lên các tài liệu trong một khoảng thời gian ngắn (ví dụ, một năm) trong khi khóa công khai có thể được dùng để xác minh chữ ký trong khoảng thời gian hiệu lực của chứng chỉ là 5 năm.

Certificate Policies: extension này mô tả các chính sách và thủ tục được dùng để xác minh chủ thể của chứng chỉ trước khi chứng chỉ được cấp phát. Các chính sách chứng chỉ được đại diện bởi các OID. Ngoài ra, một chính sách chứng chỉ có thể bao gồm một đường dẫn (URL) tới trang web mô tả nội dung của chính sách và thủ tục.

Policy Mappings: extension này cho phép chuyển dịch thông tin về chính sách giữa hai tổ chức. Ví dụ, thử tưởng tượng rằng một tổ chức định nghĩa một chính sách chứng chỉ có tên là Management Signing mà trong đó các chứng chỉ được dùng để ký lên một lượng lớn các đơn đặt hàng. Một tổ chức khác có thể có một chính sách chứng chỉ tên là Large Orders mà cũng được dùng để ký lên một lượng lớn các đơn đặt hàng. Khi đó, Policy Mapping cho phép hai chính sách chứng chỉ này được đánh giá ngang nhau.

Subject Alternative Name: extension này cung cấp một danh sách các tên thay thế cho chủ thể của chứng chỉ. Trong khi định dạng cho Subject Name thường tuân theo chuẩn X.500 thì Subject Alternative Name cho phép thể hiện theo các dạng khác như User Principal Name (UPN), địa chỉ email, địa chỉ IP hoặc tên miền (DNS).

Issuer Alternative Name: extension này cung cấp một danh sách các tên thay thế cho CA. Mặc dù thường không được áp dụng nhưng extension này có thể chứa địa chỉ email của CA.

Subject Dir Attribute: extension này có thể bao gồm bất kỳ thuộc tính nào từ danh mục LDAP hoặc X.500 của tổ chức, ví dụ, thuộc tính country. Extension này có thể chứa nhiều thuộc tinh và với mỗi thuộc tính phải gồm OID và giá trị tương ứng của nó.

Basic Constraints: extension này cho biết chứng chỉ có phải của CA hay của các chủ thể như người dùng, máy tính, thiết bị, dịch vụ. Ngoài ra, extension này còn bao gồm một rằng buộc về độ dài của đường dẫn mà giới hạn số lượng các CA thứ cấp (subordinate CA) có thể tồn tại bên dưới CA mà cấp phát chứng chỉ này.

Name Constraints: extension này cho phép một tổ chức chỉ định không gian tên (namespace) nào được phép hoặc không được phép sử dụng trong chứng chỉ.

Policy Constraints: extension này có thể có trong các chứng chỉ của CA. Nó có thể ngăn cấm Policy Mapping giữa các CA hoặc yêu cầu mỗi chứng chỉ trong chuỗi chứng chỉ phải bao gồm một OID của chính sách chứng chỉ.

Enhanced Key Usage: extension này cho biết khóa công khai của chứng chỉ có thể được sử dụng như thế nào. Những cái này không có trong extension Key Usage. Ví dụ, Client Authentication (có OID là 1.3.6.1.5.5.7.3.2), Server Authentication (có OID là 1.3.6.1.5.5.7.3.1), và Secure E-mail (có OID là 1.3.6.1.5.5.7.3.4). Khi ứng dụng nhận được một chứng chỉ, nó có thể yêu cầu sự có mặt của một OID trong các OID kể trên.

CRL Distribution Points: extension này chứa một hoặc nhiều URL dẫn tới tập tin chứa danh sách các chứng chỉ đã bị thu hồi (CRL) được phát hành bởi CA. Nếu việc kiểm tra trạng thái thu hồi của chứng chỉ được cho phép thì một ứng dụng sẽ sử dụng các URL này để tải về phiên bản cập nhật của CRL. Các URL có thể sử dụng một trong các giao thức như HTTP, LDAP, FTP, File.

Authority Information Access: extension này có thể chứa một hoặc nhiều URL dẫn tới chứng chỉ của CA. Một ứng dụng sử dụng URL này để tải về chứng chỉ của CA khi xây dựng chuỗi chứng chỉ nếu như nó không có sẵn trong bộ nhớ đệm của ứng dụng.

Freshest CRL: extension này chứa một hoặc nhiều URL dẫn tới delta CRL do CA phát hành. Delta CRL chỉ chứa các chứng chỉ bị thu hồi kể từ lần cuối base CRl được phát hành. Nếu việc kiểm tra trạng thái thu hồi của chứng chỉ được cho phép thì một ứng dụng sẽ sử dụng các URL này để tải về phiên bản cập nhật của delta CRL. Các URL có thể sử dụng một trong các giao thức như HTTP, LDAP, FTP, File.

Subject Information Access: extension này chứa thông tin cho biết cách thức để truy cập tới các các chi tiết khác về chủ thể của chứng chỉ. Nếu đây là chứng chỉ của CA thì thông tin này có thể bao gồm các chi tiết về các dịch vụ xác minh chứng chỉ hay chính sách của CA. Nếu chứng chỉ được cấp cho người dùng, máy tính, thiết bị mạng, hoặc dịch vụ thì extension này có thể chứa thông tin về các dịch vụ được các chủ thể này cung cấp và cách thức để truy cập tới các dịch vụ đó.

Ngoài việc giới thiệu thêm các extension như đã nêu ở trên thì trường Version của chứng chỉ X.509 version 3 sẽ có giá trị là 3 để cho biết phiên bản của chứng chỉ.

–manthang

Mikko Hypponen, CRO của F-Secure, nói rằng hệ thống tự động tiếp nhận malware của họ đã nhận được mẫu Flame trong khoảng thời gian 2010 – 2011 nhưng lại không đánh dấu (flag) nó là chương trình cần được xem xét kỹ lưỡng. Điều tương tự này xảy ra sớm hơn (trước 2010) với các công ty antivirus khác. Khi Stuxnet được phát hiện thì người ta vỡ ra rằng một zero-day exploit trong Stuxnet cũng được sử dụng bởi một malware khác đã được phát hiện trước đó. Cả Stuxnet và Duqu chỉ bị tóm sau hơn 1 năm tung hoành. Đây là một dấu ấn tệ hại của ngành công nghiệp chống virus nói chung [1].

Lý giải cho việc 3 malware này qua mặt được cơ chế phát hiện của các antivirus, Mikko cho rằng rất có thể chúng được phát triển bởi các tổ chức tình báo của Mỹ và phương Tây, được đầu tư bài bản và chuyên sâu mà các sản phẩm antivirus dành cho người dùng thông thường không chống lại được. Ví dụ, với Stuxnet và Duqu thì chúng có các thành phần được ký số để chúng tồn tại trên hệ thống mục tiêu như là các ứng dụng tin cậy. Còn với Flame, thay vì cố gắng bảo vệ code bằng các custom packer và obfuscation engine – là những cơ chế có thể khiến chúng bị nghi ngờ thì attacker sử dụng SSH, SQLite, SSL và LUA library để làm cho Flame trông giống như hệ thống cơ sở dữ liệu, ứng dụng doanh nghiệp.

Một luận điểm khác trong bài là trước khi lan truyền các siêu malware tới thì attacker đã kiểm tra chúng một cách kỹ lưỡng để chắc rằng các chương trình antivirus hiện có trên thị trường không thể phát hiện ra được. Nhận định này không thực sự thỏa đáng bởi vì không riêng gì các cơ quan tình báo hay chính phủ mà những tội phạm công nghệ cao khác cũng thực hiện việc kiểm tra này trước khi phát tán malware [2].

Trước ý kiến là vì Stuxnet, Flame, Duqu và các targeted malware khác được tạo ra cho mục đích chính trị, quân sự và được hậu thuẫn bởi các tổ chức mang tầm quốc gia nên có thể các hãng antivirus không chú trọng mảng này, Mikko phản bác rằng bất kể nguồn gốc hay mục đích của malware thì các công ty đều nỗ lực để bảo vệ máy tính của người dùng, ngay cả khi khác hàng của họ không nằm trong tầm ngắm của các targeted malware. Lấy ví dụ với Stuxnet, trước khi lan truyền tới được đích đến hệ thống vận hành nhà máy làm giàu Uranium của Iran thì thông qua chức năng USB worm, nó đã nhiễm vào hơn 10 ngàn máy tính khác mà không phải mục tiêu thực sự của nó.

Cuối cùng, các hệ thống antivirus cần cân bằng giữa việc cố gắng phát hiện tất cả các malware với khả năng cảnh báo sai là thấp nhất. Và một điều luôn nhớ là không có giải pháp nào mang lại hiệu quả 100%. Để bảo vệ trước các cuộc tấn công có chủ đích và phức tạp thì cần tới cách tiếp cận phòng thủ nhiều lớp (defense-in-depth) với sự bổ sung của hệ thống phòng chống xâm nhập, cản lọc các ứng dụng độc hại đã biết, giám sát các lưu lượng mạng vào ra để kịp thời phát hiện các dấu hiệu bất thường.

manthang - HVA News

Tham khảo:
[1] http://www.wired.com/threatlevel/2012/06/internet-security-fail/
[2] http://www.schneier.com/blog/archives/2012/06/the_failure_of_3.html

3 thay đổi của Microsoft liên quan tới certificate sau sự kiện Flame

1. Flame đã sử dụng kiểu tấn công MD5 collision smilie

mới, chưa được biết đến trước đây để tạo một certificate giả như thể nó được Certificate Authority (CA) của Microsoft phát hành. Một trong những điểm yếu để khai thác và thực hiện thành công kiểu tấn công này là các certificate thực do Microsoft chứng nhận sử dụng thuật toán MD5 trong quá trình tạo chữ ký (signature). Vì vậy mà quyết định dùng thuật toán SHA thay cho MD5 là điều cực kỳ cần thiết để giảm thiểu rủi ro certificate bị làm giả.

2. Sau khi Flame bị phát giác, Microsoft lập tức cung cấp các bản security update cho các máy tính chạy Windows của người dùng nhằm thu hồi (revoke) certificate của 3 intermedia CA được sử dụng để xác thực (verify) certificate giả mà Flame đã sử dụng. Thực chất của công việc này là Windows sẽ đưa 3 certificate đó vào trong danh mục Untrusted Certificate Store, gồm các certificate không còn được tin dùng nữa. Thay vì phải tải security update thì người dùng cũng có thể tự tay làm việc này nhưng rõ ràng cả 2 cách đó đều khá lâu và không hiệu quả, nhất là trong trường hợp tính năng Windows Update bị khóa lại. Để khắc phục hạn chế đó, Microsoft đưa ra Automatic Updater. Tính năng mới này sẽ định kỳ hằng ngày tự động cập nhật danh sách các certificate và các key bị thu hồi và không còn tin cậy nữa.

3. Thuật toán RSA trước giờ vốn được coi là an toàn nhưng thực sự thì cách đây hơn 10 năm RSA key có chiều dài 512-bit đã bị phá vỡ, còn hơn 2 năm trước thì tới lượt 768-bit key bị hạ gục (**). Các chuyên gia đưa ra khuyến cáo rằng chỉ nên sử dụng RSA key có chiều dài từ 1024 bit trở lên mới và Microsoft sẽ bắt đầu ép buộc điều này kể từ tháng 8 tới đây. Như vậy, bất kỳ certificate nào (xác thực hay giả mạo, còn hiệu lực hay đã hết) sử dụng key có chiều dài thấp hơn 1024 đều không được Windows chấp nhận.

Đây là 3 sự thay đổi quan trọng nhằm ứng phó trước Flame cũng như là với các mối đe dọa khác trong tương lai nhằm vào hạ tầng khóa công khai (PKI) mà certificate là một phần trong đó.

manthang - HVA News

Tham khảo:
[1] http://blogs.technet.com/b/srd/archive/2012/06/06/more-information-about-the-digital-certificates-used-to-sign-the-flame-malware.aspx
[2] http://blogs.technet.com/b/srd/archive/2012/06/03/microsoft-certification-authority-signing-certificates-added-to-the-untrusted-certificate-store.aspx
[3] http://blogs.technet.com/b/pki/archive/2012/06/12/announcing-the-automated-updater-of-untrustworthy-certificates-and-keys.aspx
[4] http://blogs.technet.com/b/pki/archive/2012/06/12/rsa-keys-under-1024-bits-are-blocked.aspx
[5] http://threatpost.com/en_us/blogs/microsoft-releases-automatic-updater-certificate-revocation-lists-plans-invalidate-short-rsa-k

smilie

nôm na là bằng cách chèn thêm/thay đổi các khối bit trong nội dung của certificate thực để tạo ra một certificate giả nhưng lại có giá trị hash trùng với giá trị hash của certificate thực. Chi tiết xem thêm:
[1] http://www.cwi.nl/news/2012/cwi-cryptanalist-discovers-new-cryptographic-attack-variant-in-flame-spy-malware
[2] http://www.cwi.nl/system/files/PhD-Thesis-Marc-Stevens-Attacks-on-Hash-Functions-and-Applications.pdf

(**) http://www.h-online.com/security/news/item/768-bit-RSA-cracked-898986.html

TQN wrote:

Không phải chỉ mình con Duqu thôi đâu, đám mèo què của stl hồi xưa cũng đã có cái trò scan harddisk với mấy cái file .doc, .xls, .ppt, .wav, .jpeg.... 1 loạt, rồi cũng compress = zlib/gzip rồi up đi.

Vậy là em đoán trúng ý của anh rồi smilie

.

Những người tạo ra Flame cũng rất thông minh khi Flame chỉ trích xuất một phần nhỏ nội dung của các loại file trên và gửi cho C&C server xem xét. Nếu kẻ tấn công nhận thấy đó là những nội dung hữu ích, có giá trị thì mới chỉ lệnh cho Flame gửi lên C&C server toàn bộ nội dung của file đó.

Khả năng tự tiêu hủy, xóa dấu vết của Flame

Những người đứng đằng sau Flame có thể dễ dàng xóa sạch dấu vết mà Flame để lại trên các hệ thống bị lây nhiễm. Kết luận được đưa ra sau khi hãng bảo mật Symantec đã nhận thấy rằng những kẻ tấn công có thể sử dụng các máy chủ C&C (command-and-control) để loại bỏ hoàn toàn Flame khỏi máy tính của nạn nhân.

Theo một bài viết trên blog [1] của bộ phận Ứng phó An ninh của Symantec vào hôm qua, các máy chủ C&C có thể gửi một tập tin có tên Browse32.ocx tới các máy mục tiêu để gỡ bỏ siêu mã độc Flame. Sau đó tập tin này sẽ tìm kiếm trên máy bị nhiễm tất cả các tập tin mà Flame sử dụng, loại bỏ chúng và thậm chí ghi đè lên vị trí lưu trữ chúng trên ổ đĩa bằng các bit thông tin và các ký tự ngẫu nhiên để che đi dấu vết.

Qua phân tích của Symantec thì module này (tập tin Browse32.ocx) chứa 2 mã khai thác khác nhau: một là EnableBrowser, nhằm khởi tạo module và StartBrowse, nhằm xóa các tập tin do Flame tạo ra. Symantec cũng bổ sung thêm rằng module này được tạo ra vào ngày 9/5 và trông giống như SUICIDE, một module được tìm thấy trước đó trong mã chương trình của Flame.

Flame được phát hiện và được tiết lộ bởi chính phủ Iran và các công ty phương Tây cách đây 2 tuần. Con sâu này nhanh chóng gây sự chú ý hơn nhiều Stuxnet và Duqu. Dường như nó đã tồn tại, ẩn mình trong nhiều năm và không được biết đến chỉ tới khi người ta phát giác rằng tác giả của Flame đã sử dụng tấn công MD5 hash collision để giả mạo chứng chỉ số như thể do Microsoft phát hành rồi ký số lên các bản cập nhật giả mạo (thực ra là bản sao của Flame) và gửi tới các hệ thống Windows.

manthang - HVA News
(Theo Threatpost)

Tham khảo:
[0] http://threatpost.com/en_us/blogs/attackers-can-use-self-destruct-feature-kill-flame-060812
[1] http://www.symantec.com/connect/blogs/flamer-urgent-suicide

TQN wrote:

The attackers seem to have a high interest in PDF documents, Office and AutoCad drawings

Cái màn này thấy quen quá !

qua phân tích hạ tầng C&C của Flame, Kaspersky kết luận rằng tác giả của Flame có sự quan tâm đặc biệt tới các định dạng file mà có thể chứa những thông tin giá trị như AutoCAD (con Duqu cũng chú ý tới format này), PDF, Office, email. hắn đang cố đánh cắp những file như vậy trên máy của nạn nhân rồi nén, mã hoá và gửi về cho C&C server.

Hỏi đáp nhanh về siêu mã độc Flame

Giới nghiên cứu bảo mật trên thế giới đang dồn sự chý ý và quan tâm tới một “vũ khí tấn công trên không gian mạng” (cyber weapon) cực kỳ tinh vi mới được phát hiện gần đây bởi hãng Kaspersky. Nó được xem là bộ công cụ tấn công có chủ đích được thiết kế phức tạp và công phu hơn cả Stuxnet và Duqu. Đó chính là siêu mã độc Flame. Bài viết này sẽ cung cấp những thông tin cơ bản nhất liên quan tới Flame.

Flame là gì?

Nó là tên mã (code name) được đặt cho một phần mềm gián điệp được thiết kế rất phức tạp, hoạt động tinh vi và có tính mô-đun (modular) cao. Flame còn được biết đến với các tên gọi khác là Flamer và sKyWIper. Nó chỉ mới được phát hiện gần đây và người ta vẫn còn đang tiếp tục phân tích và làm rõ các thành phần chức năng và hoạt động của nó. Các hãng bảo mật ước tính có khoảng gần 1000 máy tính bị lây nhiễm bởi Flame và hầu hết nằm ở vùng Trung Đông.

Flame được tạo ra để làm gì?

Chương trình gián điệp này chuyên trách việc theo dõi và thu thập nhiều loại thông tin khác nhau. Nó không chỉ đánh cắp file và email, quay phim và chụp ảnh màn hình, ghi nhận các phím được gõ và các lưu lượng mạng từ các máy tính bị lây nhiễm mà còn có thể điều khiển được microphone và webcam để nghe lén và giám sát người dùng. Ngoài ra, nếu nhận được lệnh từ chủ nhân thì nó có thể tự sao chép để lây nhiễm sang các máy tính khác thông qua mạng cục bộ và các thiết bị lưu trữ di động. Như vậy, Flame là một công cụ tấn công phức tạp, có các đặc điểm và tính năng của cả backdoor, trojan, và worm.

Tất cả những chức năng trên đều có trong nhiều mã độc khác rồi. Vầy thì điểm mới lạ, độc đáo của Flame là gì?

Một tính năng hiếm thấy là Flame có thể điều khiển chức năng bluetooth của máy tính bị lây nhiễm để kết nối tới với các thiết bị bluetooth khác trong một khu vực giới hạn. Chưa rõ ràng để khẳng định điều gì sẽ xảy ra trong trường hợp này nhưng rất có thể là nhằm do thám âm thanh qua tai nghe và đánh cắp dữ liệu từ các smartphone. Các máy bị nhiễm Flame có thể quảng bá tín hiệu bluetooth nhằm thu hút các thiết bị khác kết nối tới nó. Sẽ cần thêm các phân tích kỹ hơn để bóc trần những chi tiết này.
Một tính năng độc nhất khác là trong thành phần của Flame có bao gồm trình thông dịch ngôn ngữ LUA mà có thể được dùng để dễ dàng mở rộng chức năng của nó bằng các script.

Khái niệm mô-đun cùng các tính năng gián điệp tinh vi thì chúng ta đều đã thấy có trong Zeus và SpyEye rồi. Vậy Flame có gì khác so với các trojan nhắm vào các giao dịch ngân hàng trực tuyến đó?

Không giống với Zeus và SpyEye, là các trojan nhằm nghe lén và đánh cắp các thông tin, giao dịch với ngân hàng qua mạng, những người đứng đằng sau Flame không có ý định lan truyền xa nó đi càng xa và nhanh nhất có thể mà trái lại việc cố gắng lan truyền bản thân nó không phải là trọng tâm đầu tiên. Vì sau quá trình phân tích bước đầu, nếu Flame nhận thấy không có bất kỳ thông tin gì hữu ích trên hệ thống nạn nhân thì Flame sẽ tự xóa bỏ nó. Còn nếu thông tin mà nó tìm thấy được cho là có giá trị thì chỉ khi nhận được mệnh lệnh để tự lan truyền thì nó mới cố gắng lây nhiễm sang các hệ thống khác bằng đường mạng nội bộ, thiết bị lưu trữ USB, hoặc các phương thức khác. Việc lan truyền có tính toán và chọn lọc này làm cho số lượng máy tính bị lây nhiễm ít đi rất nhiều. Qua vài năm thì tổng số hệ thống bị nhiễm bởi Flame là 1000, quá nhỏ nếu đem so với Zeus và SpyEye là những mã độc xuất hiện trên hàng triệu máy tính.

Flame đã có mặt trên các máy tính nạn nhân đầu tiên bằng cách nào?

Chúng ta không biết chắc điều này nhưng thường là bằng các con đường truyền thống mà các cuộc tấn công có chủ đích (targeted attack) đã sử dụng. Ví dụ, thủ phạm nhận diện một nhóm những người có quyền truy cập tới các thông tin có giá trị. Sau đó máy tính của những mục tiêu này bị nhiễm spyware thông qua các email giả mạo hoặc các thiết bị USB mà ai đó cố ý đánh mất (để nạn nhân nhặt được và đem về sử dụng), hoặc thậm chí là đột nhập vào nơi ở của nạn nhân và cài đặt các phần mềm độc hại lên máy tính của họ.

Ai đã chế tạo và chịu trách nhiệm về Flame? Có phải tình báo của Israeli không?

Hiện chúng ta không biết được nhưng cũng sẽ đặt nghi ngờ về khả năng này. Có một điều chắc chắn rằng Flame được phát triển bởi các chuyên gia siêu hạng, một nhóm làm việc chuyên tâm. Ngoài ra, có vẻ như Flame lập lại tình huống của Stuxnet khi nó xuất hiện chủ yếu ở vùng Trung Đông với trọng tâm là Iran.

Flame thường được nhắc tới là có cùng đặc điểm với Stuxnet. Vậy thực sự có một mối liên kết nào giữa chúng không?

Cả 2 chương trình này đều có xu hướng sử dụng là nhằm mục đích theo dõi và tình báo nhưng khi phân tích sâu về mặt kỹ thuật thì giữa chúng có rất ít điểm tương đồng. Mặc dù có nhiều chức năng nhưng Stuxnet nổi lên là một chương trình phá hoại có chủ đích nhắm vào các máy ly tâm hạt nhân của Iran. Còn Flame lại là một chương trình gián điệp rất mạnh, bao quát và hơi cồng kềnh khi kích thước của nó lên tới 20MB. Các chuyên gia về vi-rút máy tính mà đã phân tích Flame không tìm thấy bất cứ đoạn mã giống nhau nào giữa chúng và có nhiều lý giải cho việc tại sao hai chương trình này lan truyền thành công một phần là nhờ khai thác các lỗ hổng tương tự nhau.

Flame là điển hình của một “cyber weapon” tân tiến?

Công việc của Flame phải làm là gián điệp thay vì đi phá hoại. Vì vậy mà nên gán cho nó mác “cyber wiretap” hơn là một thứ vũ khí.

Đâu thực sự là điểm đặc biệt về Flame?

Chương trình gián điệp này dường như đã được sử dụng nhiều năm rồi mà không hề bị phát hiện. Tình huống này một lần nữa cho thấy các phần mềm diệt vi-rút thông thường là không thích hợp để bảo vệ các hệ thống quan trọng trước các mối đe dọa từ các cuộc tấn công có chủ đích. Các phần mềm diệt vi-rút thường chỉ tập trung vào việc bảo vệ máy tính chống lại các mã độc có tính lan tràn cao và hầu hết là bất lực trước các phần mềm chuyên sâu, cao cấp như Flame.

Ngoài ra, các nhà nghiên cứu bảo mật hôm 6/6 đã khám phá rằng một số thành phần của Flame được ký số bởi một chứng chỉ giả mạo được chính CA của Microsoft cấp phát. Có được chứng chỉ này, Flame có thể lây nhiễm một cách êm xuôi sang các máy tính khác thông qua tính năng Windows Update. Phương thức lan truyền qua các bản cập nhật cho hệ thống lẫn kỹ thuật giả mạo chứng chỉ này đều không mới nhưng nó thể hiện một điều rằng Flame được thiết kế bởi các chuyên gia giàu kiến thức và được hỗ trợ từ những nguồn lực mạnh.

manthang - HVA News
(Theo H-Online.com)

Tham khảo:
http://www.h-online.com/security/features/FAQ-Flame-the-super-spy-1587063.html

Xem thêm phân tích và nhận định từ chuyên gia tại Kaspersky Lab:
http://www.securelist.com/en/blog/208193522/The_Flame_Questions_and_Answers

Sau sự cố rò rỉ dữ liệu mật khẩu người dùng xảy ra với LinkedIn và eHarmony trong vài ngày trước thì hôm nay tới lượt website Last.fm, cộng đồng âm nhạc phổ biến trên Internet là nạn nhân của vụ việc nghiêm trọng này.

Một danh sách vừa được đăng tải lên Internet chứa vài triệu mật khẩu thuộc về người dùng của Last.fm. Ngay sau đó, đại diện của Last.fm đã ra thông cáo chính thức [1] nói rằng hiện công ty đang tiến hành điều tra, làm rõ vụ rò rỉ này và khuyến cáo tất cả người dùng của họ nên thay đổi mật khẩu ngay lập tức.

Theo trang The H Security thì họ đang có trong tay một danh sách chứa khoảng 2,5 triệu MD5 hash của mật khẩu của Last.fm. Và cũng giống với trường hợp của LinkedIn và eHarmony, tất cả đều là các giá trị hash được tạo ra mà không áp dụng salt. Điều này khiến cho việc giải mã mật khẩu trở nên dễ dàng hơn nhờ các công nghệ phần cứng nhanh mạnh và sử dụng kỹ thuật như rainbow table. Đã có ít nhất một triệu hash bị giải mã thành công và mật khẩu tương ứng được cũng được gửi lên Internet.

Người dùng Last.fm nên thay đổi mật khẩu ngay và cần nhớ là chọn mật khẩu nên đủ phức tạp, khó đoán và không dùng chung mật khẩu giữa các tài khoản khác nhau.

manthang - HVA News

(Theo H-Online.com)

Tham khảo:
[0] http://www.h-online.com/security/news/item/Millions-of-Last-fm-passwords-leaked-1613641.html
[1] http://www.last.fm/passwordsecurity

Mình có nghi vấn là liệu trọn bộ CSDL trên có phải là của LinkedIn không?

Đã có vài người dùng xác nhận mật khẩu LinkedIn của họ có trong CSDL trên (xác nhận điều này bằng cách so sánh hash), và mật khẩu ở LinkedIn của họ là duy nhất (không dùng chung cho các tài khoản khác).
https://twitter.com/thorsheim/status/210333610702675968

Như vậy, rõ ràng là phần nào đó (không dám chắc toàn bộ) CSDL trên chứa các mật khẩu của LinkedIn. Ngoài ra, chính LinkedIn cũng đã xác nhận rằng "We can confirm that some of the passwords that were compromised correspond to LinkedIn accounts."
Tại sao lại nói "some of the passwords" mà không phải tất cả 6.5 triệu hash đều có trong DB của LinkedIn?

Tay hacker này gửi CSDL hash password trên lên forum của Nga để nhờ các cracker ở đó crack giùm. kết quả là có gần 300 ngàn password đã cracked thành công. Một câu hỏi đặt ra là tại sao tay hacker không lấy được username và email? hoặc có khi nào hắn có được username/email nhưng lại giấu đi để hưởng lợi 1 mình?

Tay hacker gửi lên 6.5 triệu hash này nói là DB của LinkedIn. Còn LinkedIn tuy có xác nhận là có hash của nhiều user trong DB đó nhưng lại nói rằng chưa phát hiện thấy dấu hiệu data breach nào xảy ra trên hệ thống của họ:
http://news.cnet.com/8301-1009_3-57448231-83/linkedin-we-see-no-security-breach..-so-far/

Nếu không phải của LinkedIn thì tại sao hacker phải mất công tạo DB lớn như vậy rồi loan báo rằng đó là của LinkedIn?

bolzano_1989 wrote:

manthang wrote:

bolzano_1989 wrote:

Một trang kiểm tra password khác anh chị em có thể dùng là:
http://leakedin.org/

Một kết quả kiểm tra tham khảo:

Looks like your password was not leaked. Hooray!

Danh sách trên không chứa các hash password bị trùng lắp. LinkedIn có hơn 161 triệu người dùng, nên khả năng đây không phải là trọn bộ CSDL tài khoản của LinkedIn. Nhưng cũng không thể biết được liệu hacker còn giấu phần nào đó của CSDL hash này mà chưa tung lên không. Và cũng không chắc được là hệ thống của LinkedIn còn bị xâm nhập hay không.

Vì vậy việc xác minh qua trang LastPass.com hay leakedin.org nói trên cũng không đảm bảo là tài khoản của mình vẫn an toàn.
Cách tốt nhất là đổi lại mật khẩu LinkdeIn và các tài khoản quan trọng khác dùng chung mật khẩu này.

Theo tìm hiểu của mình thì không phải là do danh sách trên "không chứa các hash password bị trùng lắp" nên không phủ được tất cả các password hash đâu manthang. Tay hacker này cũng chẳng phải có lòng muốn chia sẻ danh sách hash cùng tên tài khoản Linkedin tương ứng với cộng đồng cracker, chẳng qua là hắn đang tìm sự trợ giúp từ cộng đồng password cracking này.

Mình đã tìm được file dump các password hash tay hacker đã gửi lên diễn đàn hacker Nga đó rồi.
Sự thật là nếu hash của password bạn dùng ở Linkedin xuất hiện trong danh sách của hacker gửi lên đó nghĩa là password của bạn là một trong những password mà tay hacker này không tìm được password tương ứng từ thông tin hash SHA1 và hắn phải tìm sự trợ giúp từ các tay hacker khác trong cộng đồng password cracker này.

Những password dễ crack mà tay hacker này đã crack được từ các tài khoản Linkedin đều không được post lên diễn đàn trên, cho nên nếu password hash của bạn không được tìm thấy trong 2 trang kiểm tra mà bolzano_1989 gửi trên thì không có nghĩa là password của bạn an toàn mà còn có khả năng là password của bạn đã bị crack quá dễ dàng và tay hacker không buồn gửi lên mạng.

à, ý mình là danh sách được hacker gửi lên chứa gần 6.5 triệu hash khác nhau tương ứng với gần 6.5 triệu tài khoản, trong khi tổng số tài khoản của Linkedin là 161 triệu. Nếu tính ra thì chỉ chưa tới 5% người dùng LinkedIn bị ảnh hưởng.

Nhưng vì như bolzano (và mình) cũng có nói là có thể hacker "không buồn gửi lên mạng" phần còn lại của CSDL tài khoản mà hắn đánh cắp được nên con số thực tế có thể lớn hơn 5%.
Vậy nên mình mới nói là việc kiểm tra ở 2 site trên cũng không đảm bảo là tài khoản của người dùng không bị ảnh hưởng.

Thread mà tay hacker này gửi danh sách lên forum Nga đã bị xóa, những vẫn còn trong cache của Google. Mình cũng đã coi qua nhưng attachment chứa danh sách cũng bị xóa rồi.

Cập nhật thêm là LinkedIn sẽ gửi 2 email tới các tài khoản bị ảnh hưởng để hướng dẫn người dùng thay đổi mật khẩu. Đồng thời họ cũng nâng cấp CSDL mật khẩu bằng cách hỗ trợ thêm salt trong việc tạo hash. Xem: http://blog.linkedin.com/2012/06/06/linkedin-member-passwords-compromised/

Tham khảo thảo luận về sự cố này ở đây:
http://news.ycombinator.com/item?id=4073309

bolzano_1989 wrote:

Một trang kiểm tra password khác anh chị em có thể dùng là:
http://leakedin.org/

Một kết quả kiểm tra tham khảo:

Looks like your password was not leaked. Hooray!

Danh sách trên không chứa các hash password bị trùng lắp. LinkedIn có hơn 161 triệu người dùng, nên khả năng đây không phải là trọn bộ CSDL tài khoản của LinkedIn. Nhưng cũng không thể biết được liệu hacker còn giấu phần nào đó của CSDL hash này mà chưa tung lên không. Và cũng không chắc được là hệ thống của LinkedIn còn bị xâm nhập hay không.

Vì vậy việc xác minh qua trang LastPass.com hay leakedin.org nói trên cũng không đảm bảo là tài khoản của mình vẫn an toàn.
Cách tốt nhất là đổi lại mật khẩu LinkedIn và các tài khoản quan trọng khác dùng chung mật khẩu này.

6,5 triệu mật khẩu LinkedIn đang bị phơi bày trên mạng

Các diễn đàn, trang tin trên Internet hiện đang loan báo về một danh sách chứa khoảng 6,5 triệu chuỗi băm (hash) của mật khẩu được cho là của mạng xã hội nổi tiếng LinkedIn. Hiện có khoảng 300 nghìn mật khẩu đã giải mã được công bố.

Danh sách này không bao gồm tên người dùng và địa chỉ email mà chỉ chứa các giá trị băm SHA-1 của mật khẩu. Vậy nên nếu chỉ có trong tay mật khẩu được giải mã thì cũng không dễ dàng gì có thể truy cập tới một tài khoản thích hợp. Tuy nhiên, không loại trừ trường hợp kẻ xấu tóm được chuỗi băm cùng với địa chỉ email tương ứng.

Các mật khẩu đã được giải mã thường chứa từ "linked" và "linkedin", ví dụ, "lawrencelinkedin". Điều này gợi lên rằng mật khẩu rất có thể được dùng cho tài khoản LinkedIn, tuy điều này vẫn chưa được xác nhận.

Một thực tế đáng lo ngại là ngay cả với các mật khẩu khá phức tạp và khó đoán như "parikh093760239", "a06v1203n08" và "376417miata?" cũng bị bẻ khóa thành công. Nguyên nhân là do các chuỗi băm được tạo ra mà không đi kèm giá trị salt nên có thể sử dụng kỹ thuật rainbow table để giải mã chỉ sau vài giờ. Để ngăn chặn nguy cơ này, xem thêm bài viết sau [1] tại The H Security.

Dù gì chăng nữa, nếu bạn có tài khoản LinkedI thì tốt nhất là đổi mật khẩu ngay lập tức. Nếu có dùng chung mật khẩu ở LinkedIn với các tài khoản quan trọng khác như ngân hàng, thư điện tử thì cũng nên đổi luôn mật khẩu cho các tài khoản đó.

Vào hôm qua (6/6), LinkedIn đã xác nhận trên trang Twitter rằng họ đang xem xét các bản báo cáo về sự cố hàng triệu mật khẩu bị đánh cắp này. Cùng lúc đó, theo các nguồn đáng tin cậy thì họ đã tìm thấy các mật khẩu của LinkedIn trong danh sách. Vì vậy mà khả năng cao là hệ thống của LinkedIn đang thực sự có vấn đề.

Ngoài ra, trên Internet đang xuất hiện các trang web yêu cầu cung cấp mật khẩu LinkedIn hiện tại để giúp bạn xác minh xem mật khẩu đó có nằm trong danh sách kia không. Đây thực chất là những website lừa đảo. Các chuyên gia cũng lo ngại rằng sẽ có làn sóng thư rác gửi tới người dùng để mời gọi họ đổi mật khẩu thông qua một đường dẫn (URL) tới một trang web mạo danh LinkedIn.

Vậy nên, để an toàn thì người dùng cần truy cập trực tiếp tới trang chủ tại linkedin.com và thực hiện đổi mật khẩu. Lưu ý, khi đổi mật khẩu nên chọn một mật khẩu ngẫu nhiên hoặc không trùng với các mật khẩu quan trọng khác.

manthang - HVA News

Tham khảo:
[0] http://www.h-online.com/security/news/item/LinkedIn-passwords-in-circulation-Update-1612022.html
[1] http://www.h-online.com/security/features/Storing-passwords-in-uncrackable-form-1255576.html

Lỗ hổng bảo mật trong sản phẩm Seagate BlackArmor NAS

Máy chủ BlackArmor NAS của Seagate đang có một lỗ hổng nghiêm trọng khi mà bất kỳ ai được phép truy cập tới nó sử dụng một URL đặc biệt đều có khả năng đặt lại mật khẩu cho tài khoản quản trị.

BlackArmor là dòng sản phẩm thiết bị lưu trữ được gắn vào mạng (network attached storage – NAS) với dung lượng lưu trữ từ 1TB tới 12TB, dành cho các doanh nghiệp nhỏ, cung cấp các giải pháp lưu trữ và sao lưu cho các máy tính Windows và Mac OS X.

Lỗ hổng an ninh này được US-CERT ghi nhận và thông báo tại đây [1]. Theo đó thì kẻ tấn công chỉ cần truy cập trực tiếp (mà không cần trải qua bước xác thực) vào địa chỉ

http://Địa_chỉ_IP_của_thiết_bị/d41d8cd98f00b204e9800998ecf8427e.php

là có cơ hội đặt lại mật khẩu cho tài khoản có quyền quản lý thiết bị.

Hiện vẫn chưa có giải pháp khắc phục và US-CERT chỉ khuyến cáo rằng cần thực hiện việc giới hạn khả năng truy cập từ xa tới thiết bị qua giao diện web, ví dụ, chỉ cho phép một vài IP trong mạng nội bộ. Hãng Seagate cũng được thông báo về vấn đề này nhưng chưa cung cấp một bản vá chính thức nào. Trang tải về firmware cho thiết bị NAS của Seagate được cập nhật mới nhất vào ngày 17/2/2011 [2].

manthang – HVA News

Tham khảo:
[1] http://www.kb.cert.org/vuls/id/515283
[2] http://knowledge.seagate.com/articles/en_US/FAQ/217171en?language=en_US
[3] http://www.h-online.com/security/news/item/Critical-hole-in-Seagate-BlackArmor-NAS-1585283.html

Yahoo để lộ khóa bí mật trong extension Axis cho Google Chrome

(HVA News) – Dù chỉ mới thông báo phát hành một trình duyệt mới có tên Axis vào hôm nay (24/5), thì gần như ngay lập tức một nhà nghiên cứu bảo mật đã phát hiện ra một lỗi nghiêm trọng khi tập tin mã nguồn của chương trình này có chứa khóa bí mật (private key) của Yahoo. Điều này cho phép kẻ tấn công có thể tạo ra một phần mở rộng (extension) độc hại mà trình duyệt lại tin tưởng vì nó được ký số (signing) bởi khóa bí mật hợp lệ của Yahoo!

Axis là một trình duyệt chạy độc lập trên các thiết bị di động như iPhone, iPad và cũng có các phiên bản dạng phần mở rộng cho Firefox, Chrome, Safari và Internet Explorer. Tính năng nổi bật được Yahoo quảng cáo là khi người dùng đang gõ vào ô tìm kiếm thì nó sẽ cố gắng đoán trước những từ khóa mà người dùng có thể muốn tìm và hiển thị các hình ảnh thu nhỏ của những kết quả tương ứng.

Nhưng điều đáng chú ý nhất lại là chỉ trong vài giờ sau khi Axis được phát hành, một cây viết và cũng là một hacker có tên Nik Cubrilovic đã thông báo rằng trong tập tin mã nguồn của phiên bản mở rộng cho Chrome có chứa khóa bí mật PGP được Yahoo dùng để ký lên tập tin này. Khóa cần được giữ bí mật tuyệt đối này đi cặp với một khóa công khai (public key) khác được trình duyệt sử dụng để kiểm tra chữ ký số của extension đều có trong tập tin chứng chỉ số (với định dạng .PEM) đi kèm với gói extension.

“Tập tin chứng chỉ số này được Yahoo! dùng để tạo chữ ký số cho extension cũng là tập tin được trình duyệt Chrome và Web Store https://chrome.google.com/webstore/) sử dụng để xác thực rằng extension đó do chính Yahoo! phát hành. Nếu có được tập tin chứng chỉ số bí mật này thì kẻ xấu có thể tạo ra một extension giả mạo nhưng lại được Chrome tin cậy.” Cubrilovic viết trong một bài phân tích trên blog của mình [1]. Vì không có mật khẩu nào bảo vệ việc truy cập tới khóa bí mật nên việc ký số diễn ra dễ dàng.

Cubrilovic sau đó đã chứng minh và khai thác lỗ hổng này bằng cách tạo thử một extension giả mạo Axis được ký bởi khóa bí mật của Yahoo vừa tìm được ở trên và cài đặt thành công nó lên Chrome mà không gặp phải vấn đề gì. Anh ta cũng gửi lên trang GitHub mã nguồn của extension gốc của Axis và bản extension giả để mọi người so sánh [2].

“Ngụ ý dễ thấy nhất ở đây là với tập tin chứng chỉ số bí mật, bạn có thể tạo một extension giả mạo nhằm ghi nhận lại toàn bộ lưu lượng web, bao gồm các mật khẩu, cookie, v.v. Cách dễ dàng nhất để khiến nạn nhân cài đặt lên máy gói extension giả này là giả mạo DNS đối với đường dẫn (URL) cập nhật cho extension gốc. Vào lần cập nhật kế tiếp cho extension gốc, nó sẽ lặng lẽ cài đặt và chạy extension giả này.” Cubrilovic giải thích thêm.

Trước sai lầm ngớ ngẩn này, một thành viên của nhóm phát triển Axis là Ethan Batraski phản hồi trên một vài website rằng Yahoo! đã gỡ bỏ extension trên Chrome, thu hồi chứng chỉ bị lộ và sẽ sớm phát hành extension mới thay thế.

manthang

Tham khảo:
[1] http://nikcub.appspot.com/posts/yahoo-axis-chrome-extension-leaks-private-certificate-file
[2] https://github.com/nikcub/yahoo-spoof
[3] http://threatpost.com/en_us/blogs/yahoo-includes-private-key-source-file-axis-chrome-extension-052412
[4] http://www.h-online.com/security/news/item/Yahoo-released-private-certificate-with-new-extension-1583522.html

ZTE thừa nhận có backdoor trong thiết bị Android của họ

Hôm 18/5, ZTE - hãng sản xuất thiết bị cầm tay của Trung Quốc thừa nhận rằng tồn tại một lỗ hổng an ninh trong mẫu điện thoại thông minh ZTE Score M chạy Android được bán tại Mỹ [1].

Thiết bị này được cài sẵn ứng dụng sync_agent nằm trong thư mục /system/bin với một mật khẩu được lập trình cứng (hard-coded) mà người dùng không thể thay đổi được. Ứng dụng này có bit SUID được bật nên khi được chạy với tham số là mật khẩu trên nó sẽ trao cho người dùng bình thường quyền hạn truy cập của tài khoản root. Điều này có thể bị kẻ xấu lợi dụng để chiếm trọn quyền điều khiển thiết bị của người dùng [2].

Theo ZTE, ứng dụng (mang đặc điểm của backdoor) này chỉ có trong mẫu Score M được bán tại Mỹ thông qua nhà cung cấp MetroPCS và hãng đang “tích cực làm việc” để sớm cung cấp bản vá lỗi cho các thiết bị bị ảnh hưởng. Mặc dù các báo cáo trước đó chỉ ra rằng một mẫu thiết bị cầm tay khác là ZTE Skate cũng có backdoor này nhưng hãng đã phủ nhận tin này [3].

Chuyên gia bảo mật Dmitri Alperovitch, người đã phát hiện ra lỗ hổng này nói rằng ứng dụng trên hoàn toàn được cài vào thiết bị một cách có chủ đích vì ZTE đang sử dụng nó để phân phối các bản cập nhật phần mềm tới điện thoại của người dùng. Nhưng ông không thể chắc chắn rằng liệu backdoor là ứng dụng độc hại hay chỉ đơn giản là một lỗi lập trình mà ZTE sơ ý mắc phải.

Thông tin về lỗ hổng này đã bắt đầu lan rộng vào tuần trước sau khi một người dùng nặc danh tiết lộ nó trên Pastebin vào hôm 10/5 [4]. ZTE, nhà sản xuất thiết bị cầm tay lớn thứ tư thế giới cùng với Huawei đang được săm soi kỹ lưỡng tại Mỹ vì lo ngại có backdoor và các lỗ hổng an ninh khác trong các sản phẩm, đặc biệt là các thiết bị hạ tầng viễn thông quan trọng được cung cấp bởi các nhà sản xuất Trung Quốc này.

manthang - HVA News ( Tổng hợp từ Reuters, SANS ISC, Threatpost, H-Online ) [5]

Tham khảo:
[1] http://www.reuters.com/article/2012/05/18/us-zte-phone-idUSBRE84H08J20120518
[2] http://isc.sans.edu/diary/ZTE+Score+M+Android+Phone+backdoor/13252
[3] http://threatpost.com/en_us/blogs/report-zte-score-m-android-phone-found-have-backdoor-installed-051812
[4] http://pastebin.com/wamYsqTV
[5] http://www.h-online.com/security/news/item/ZTE-admits-to-backdoor-in-one-of-its-Android-devices-1580108.html

Xuất hiện mã khai thác từ xa lỗi 0-day mới của PHP 5.4.3 trên Windows

Vào hôm qua 18/05, một thành viên có nickname là 0in đã gửi lên trang packetstormsecurity.org một mã khai thác từ xa (remote exploit) lợi dụng lỗ hổng trong hàm com_print_typeinfo của PHP phiên bản 5.4.3 dành cho nền tảng Windows. Trong phần ghi chú, 0in là tác giả của mã khai thác này cho biết, anh ta đã thử nghiệm thành công trên máy Windows XP SP3 được cập nhật đầy đủ các bản vá. Và kết quả là PHP engine sẽ thực thi bất kỳ shellcode nào được chứa trong mã khai thác này.

Hiện vẫn chưa có thông báo và bản vá lỗi chính thức nào từ nhóm phát triển PHP cho lỗi 0-day mới nhất này, nhưng dưới đây là một số biện pháp để hạn chế các rủi ro khác:

• Chặn tất cả các chức năng upload file trong các ứng dụng PHP.
• Sử dụng IPS để lọc các shellcode đã được biết đến, ví dụ các shellcode có trong Metasploit.
• Cập nhật PHP lên phiên bản mới nhất để phòng chống các lỗ hổng khác như CVE-2012-2336 được công bố vào đầu tháng này.
• Sử dụng Host-IPS để chặn bất kỳ các lỗi buffer overflow có thể có trong hệ thống.

(Theo Internet Storm Center (ISC))

Manthang - HVA News

Tham khảo:
http://isc.sans.edu/diary/PHP+5+4+Remote+Exploit+PoC+in+the+wild
http://packetstormsecurity.org/files/112851

Ky0 wrote:

rubick wrote:

Chào các anh em là thành viên mới,hiện đang học năm nhất ngành quảng trị mạng trường cao đẳng kỹ thuật Cao Thắng.Em được thầy giao về làm đề tài đồ án môn học nghiên cứu về các mối đe dọa trên mạng.Các anh nào biết vào có tài liệu cho em xin về tham khảo làm bài tập.Và cũng muốn tìm hiểu về hacker và muốn tập làm 1hacker nghiệp dư mong các anh chỉ bảo....Thanks.

=> Xem lại phần trình bày của anh Nguyễn Lê Thành Tại Tetcon 2012
=> Bạn có thể xem lại tất cả các bài viết trong phân mục "Thảo luận việc định hướng"

- Ky0 -

slide và video của anh Nguyễn Lê Thành tại Tetcon 2012 không được cung cấp trên trang chủ của hội thảo, anh Ky0 ơi. em cũng muốn coi lại bài keynote này của anh Thành.

Tổ chức Wikimedia đang cảnh báo hàng triệu người dùng của họ rằng nếu thấy các hình ảnh quảng cáo xuất hiện trên bất kỳ trang web nào của họ thì rất có thể máy tính của người dùng đó đã bị nhiễm mã độc.

Vào thứ 2, Wikimedia đã đưa ra một tuyên bố trên blog [1] rằng họ chưa bao giờ cho phép chạy các quảng cáo trên các trang web như Wikipedia – thư viện bách khoa toàn thư trực tuyến lớn nhất trên Internet. Vì vậy, nếu người dùng truy cập vào một bài viết nào đó trên Wikipedia mà thấy các hình ảnh quảng cáo cho các công ty thì khả năng họ đã là nạn nhân của một cuộc tấn công Web, bao gồm các plug-in độc hại được cài đặt vào trong trình duyệt.

Nhiều extension độc hại (như “I want this”) được thiết kế để làm nhiệm vụ hiển thị các quảng cáo trên các trang web được mở bằng các trình duyệt như Chrome, Firefox và Internet Explorer, Philippe Beaudette, Giám đốc Vận động Cộng đồng của Wikimedia giải thích. Các quảng cáo được chèn theo cách này có thể bị giới hạn trên một vài website, như chỉ hiển thị trên Wikipedia hoặc có khi được hiển thị trên bất kỳ website nào mà bạn ghé thăm.

Ngoài ra, còn một lý do khác khiến bạn thấy các hình ảnh quảng cáo là nhà cung cấp dịch vụ Internet đã cố tình chèn thêm chúng vào các trang web mà bạn truy cập. Điều này dễ xảy ra đối với các nơi cung cấp kết nối Internet miễn phí như quán cà phê.

Việc tắt các add-ins khả nghi trong trình duyệt hoặc duyệt web thông qua các một kết nối an toàn (HTTPS) có thể làm biến mất các quảng cáo nhưng không thực sự giải quyết tận gốc vấn đề vì mã độc có thể đã tác động sâu trong hệ điều hành. Vì vậy, người dùng cũng nên sử dụng các công cụ giúp dò tìm và loại bỏ mã độc sẵn có trên máy hoặc thử qua các giải pháp miễn phí như Ad-Adware, Malwarebytes.

Cảnh báo từ Wikimedia xuất hiện trong lúc nhiều bản báo cáo khác cho biết sự lan rộng của các cuộc tấn công có nguồn gốc từ các webiste bị chiếm quyền điều khiển. Ví dụ, mới đây công ty bảo mật zScaler đã thông báo rằng có tới 621 trong tổng số một triệu website phổ biến nhất (được thống kê bởi Alexa) đang ẩn chứa các nội dung độc hại. Nhiều trong số này là các website đáng tin cậy nhưng bị tấn công và điều khiển bởi các nhóm tội phạm và lừa đảo trên mạng.

(Theo Threatpost) [2]

Tham khảo:
[1] http://blog.wikimedia.org/2012/05/14/ads-on-wikipedia-your-computer-infected-malware
[2] http://threatpost.com/en_us/blogs/those-wikipedia-ads-they-mean-youre-infected-malware-051612

ITbaby wrote:

manthang wrote:

lỗ hổng này đã được nhóm PHP khắc phục.
người dùng cần nâng cấp lên các phiên bản mới nhất là PHP 5.4.3 và PHP 5.3.13

Chi tiết xem tại: http://www.php.net/archive/2012.php#id2012-05-08-1

Diễn đàn của em sử dụng php 5.3.8 khi em nhập các đối số thì không thấy ra source . Vậy có phải cần thiết liên hệ bên cung cấp nâng cấp php lên không anh ạ !

Lỗi này chỉ xảy ra nếu bạn cài đặt PHP trong chế độ CGI-based mà thôi.
Còn như trong link trên có đề cập: "mod_php and php-fpm are not vulnerable to this attack."
--> Cài theo dạng mod_php và php-fpm thì không bị ảnh hưởng bởi lỗi này.

Dẫu sao thì bạn vẫn nên cập nhật ngay PHP nên phiên bản mới nhất nếu việc cập nhật này không làm ảnh hưởng hay gián đoạn quá nhiều tới hoạt động của hệ thống của bạn.

Xem thêm bài này:
http://www.digitalbond.com/tools/basecamp/schneider-modicon-quantum/

Có đề cập đến:
-- 3 Metasploit modules giúp exploit các lỗ hổng trong thiết bị Schneider Modicon Quantum PLC gồm gửi stop command, dowload/upload ladder logic và password recovery.
-- các port & service được kích hoạt mặc định
-- các backdoor account.

chiro8x wrote:

Đọc xong không biết là lỗi hay backdoor .

Việc thiếu cơ chế authentication khi liên lạc với PLC là một lỗ hổng, còn mật khẩu của nhiều tài khoản backdoor được vendor cố tình hardcoded trong thiết bị mà không được mã hoá cũng là một lỗ hổng khác.

Còn trong bài viết này không có nhắc đến chi tiết kẻ tấn công để lại backdoor trên hệ thống PLC.

Mới đây tổ chức Fraunhofer Institute for Secure Information Technologoy (SIT) [1] đã thực hiện kiểm tra và đánh giá độ an toàn của 7 nhà cung cấp dịch vụ lưu trữ trên nền Cloud. Bản báo cáo kết quả của nghiên cứu này được công bố rộng rãi tại địa chỉ
http://www.sit.fraunhofer.de/content/dam/sit/en/studies/Cloud-Storage-Security_a4.pdf

Các tác giả của bản báo cáo trên đã tìm thấy các lỗ hổng trong các chức năng như đăng ký và đăng nhập tài khoản, mã hóa và truy cập tới dữ liệu được chia sẻ của một số dịch vụ.

7 nhà cung cấp dịch vụ lưu trữ trên nền cloud được kiểm tra là CloudMe, CrashPlan, Dropbox, Mozy, TeamDrive, Ubuntu One và Wuala, các dịch vụ đều có thể được truy cập trực tiếp thông qua các phần mềm được cài đặt trên máy của người dùng. Các nhà nghiên cứu đã không xem xét các dịch vụ như Amazon S3 vì nó chỉ có thể truy cập được thông qua API, và cũng khẳng định rằng trong tương lai, họ sẽ có kế hoạch nghiên cứu thêm các nhà cung cấp lớn khác.

Các chức năng được khảo sát bởi Fraunhofer là sao chép, sao lưu, đồng bộ và chia sẻ. Chỉ có TeamDrive và Wuala là cung cấp đầy đủ cả 4 chức năng này. CrashPlan và Mozy chỉ cung cấp dịch vụ sao lưu, nhưng dịch vụ này lại không được cung cấp bởi CloudMe, Dropbox và Ubuntu One.

Về các khía cạnh bảo mật thì qua kiểm tra, CloudMe được đánh giá là kém nhất so với các nhà cung cấp còn lại, nó không thực hiện mã hóa trước và trong suốt quá trình truyền tải dữ liệu. Các nhà nghiên cứu cũng phê bình CrashPlan, TeamDrive và Wuala vì họ sử dụng giao thức mã hóa không được công bố của riêng họ thay vì sử dụng chuẩn SSL/TLS.

CloudMe, Dropbox và Ubuntu One cũng bị mất điểm khi không áp dụng mã hóa ở phía người dùng, điều này khiến cho các nhà cung cấp dịch vụ lưu trữ có thể đọc được dữ liệu. Wuala thì cung cấp tính năng này, nhưng họ sử dụng cơ chế mã hóa xác định (deterministic encryption) [2] để có thể nhận dạng được các tập tin bị trùng lắp.

Nghiên cứu cũng dành ra một chương để nói về các vấn đề liên quan tới tính hợp pháp. Các tác giả lưu ý rằng đạo luật Patriot được Quốc hội Mỹ thông qua đồng nghĩa với việc dữ liệu được lưu trữ bởi các công ty Mỹ không được hưởng cùng một mức độ bảo vệ như dữ liệu được lưu trữ bởi các công ty ở các nước thuộc Liên minh châu Âu (EU). Trong số các công ty được kiểm tra, chỉ có OnlyMe (Thụy Điển), TeamDrive (Đức) và Wuala (Thụy Sĩ) là không bị chi phối bởi đạo luật này.

(Theo H-Online) [3]

Tham khảo:
[1] http://www.sit.fraunhofer.de/en.html
[2] http://en.wikipedia.org/wiki/Deterministic_encryption
[3] http://www.h-online.com/security/news/item/Fraunhofer-Institute-finds-security-vulnerabilites-in-cloud-storage-services-1575935.html

chiro8x wrote:

quocbao9996 wrote:

2. Nếu ISP mà theo dõi DNS traffic để chặn website mà mình truy cập thì rõ ràng họ đã vi phạm quyền riêng tư của người dùng -> ném đá ngay. Do đó họ chắc chắn không dám làm chuyện này (nếu họ làm được)

Một khi ta đã xài OpenDNS có traffic được mã hoá thì ISP không thể chặn được website của mình nữa. Thông thường, thông tin người dùng gửi đến DNS server sẽ có dạng như "ê mày dịch dùm tao facebook.com", ISP biết thế và sẽ chặn kết nối của mình, nhưng khi đã mã hoá traffic rồi, thông tin được gửi đi sẽ dạng như "ê mày dịch dùm tao 4htg9hd", mấy bác ISP có nước nhìn nhau mà cười, không biết đường nào mà chặn. Nếu ISP muốn chặn thì chỉ có cách liên hệ với hết tất cả các nhà quản lí DNS server thôi (cái này nghe hơi ảo, hehe)

mà sao bạn không trực tiếp hỏi ISP nhỉ, có lẽ họ sẽ cho bạn câu trả lời đầy đủ hơn (hoặc sẽ né đi vì sợ lộ mánh)

Client có hổ trợ encrypt cái DNS query không bồ tèo ?.

--> Chắc ở đây, ý của quocbao9996 là phải cài thêm công cụ DNSCrypt trên Windows/MAC kết hợp dùng DNS server của OpenDNS để có thể mã hoá query.

http://www.opendns.com/technology/dnscrypt

chủ thớt này cung cấp thông tin chưa đầy đủ như dùng switch của hãng nào, model là gì nên mình chỉ phỏng đoán là hàng Cisco và đưa ra hướng dẫn ở trên.
cũng chưa thấy chủ thớt lên thông báo lại là đã làm được chưa.