Hãy cùng chia sẻ với Ixij

Vụ việc gây xôn xao dư luận: Công ty Việt Mỹ đòi FPT Telecom bồi thường 1 triệu USD chưa kịp lắng xuống, mới đây, lại được thổi bùng lên bởi những “tình tiết” mới. Phía công ty Việt Mỹ cho biết, Website - cổng thương mại điện tử www.vietmy.vn của họ đã bị hacker tấn công ba lần, xoá sạch dữ liệu, gây hậu quả nghiêm trọng. Theo quan điểm của công ty này, trong ba lần website “bị đánh”, FPT Telecom là người phải chịu trách nhiệm.

Còn nhớ, ngày 27/10/2005, Công ty cổ phần quảng cáo thương mại Việt Mỹ (Công ty Việt Mỹ), trụ sở tại Q.4, TP.HCM đã ký hợp đồng thuê dịch vụ hosting của Công ty cổ phần viễn thông FPT (FPT Telecom). Đây là dịch vụ lưu trữ website và sử dụng email theo tên miền và những thông tin của khách hàng trên mạng Internet.


Giao diện website www.vietmy.vn ở thời điểm bị hack lần thứ 3

Ngày 6/2/2007, toàn bộ hệ thống email của Công ty Việt Mỹ bị kẹt mạng và ngày hôm sau khi truy cập mạng, tất cả thông tin dữ liệu của 10 email bị mất sạch. Theo ông Phan Quý Ngà, Tổng giám đốc Công ty Việt Mỹ, những thông tin lưu trữ trên email của công ty bị mất đã làm công việc kinh doanh gián đoạn, ngoài việc mất uy tín với khách hàng, mức thiệt hại về kinh tế là rất lớn. Ông Ngà cho biết thêm, sau khi sự cố xảy ra, Công ty Việt Mỹ đã yêu cầu nhà cung cấp dịch vụ khôi phục những thông tin dữ liệu trên 10 email đã bị mất, nếu không khôi phục được phải bồi thường 1 triệu USD.

Không thể thương lượng thành công, công ty này đã gửi đơn đến TAND TP.HCM để kiện FPT Telecom.



Khi vụ kiện 1 triệu USD còn chưa có hồi kết, Công ty Việt Mỹ lại tiếp tục lên tiếng đòi FPT Telecom phải có trách nhiệm với khách hàng của mình. Đặc biệt, mới đây, website cũng là cổng thương mại điện tử của công ty này liên tục bị hack, theo quan điểm của Việt Mỹ, FPT Telecom là người phải chịu trách nhiệm cho những lần hacker tấn công trang web này.

Trong công văn gửi đến các cơ quan báo chí “cầu cứu”, Công ty Việt Mỹ đã nhấn mạnh: “Công ty chúng tôi đã ký hợp đồng thuê hosting của Công ty FPT vào ngày 27 tháng 10 năm 2005 mã số hợp đồng..002482/FPTHCM-NOC. Trong thời gian hợp đồng Công Ty FPT đã làm cho hosting của wesite vietmy.vn bị hacker phá hoại”.

“Từ 16h00 ngày 21/06/07 đến lúc 19h00 ngày 24/06/07 Công ty FPT đã để cho Hacker tấn công vào cổng thương mại điện tử www.vietmy.vn gây ảnh h ư ởng đến hoạt động kinh doanh của công ty Việt Mỹ đồng thời làm ảnh h ư ởng dữ liệu của cổng thương mại điện tử www.vietmy.vn. Và đây cũng là chương trình hỗ trợ doanh nghiệp thành công trong quá trình hội nhập WTO đã có khoản gần 2000 khách hàng và gần 200.000 lược truy cập”.

Trước động thái mới của Công ty Việt Mỹ, FPT Telecom cho biết họ sẽ có công văn làm rõ vụ việc.

Hoàng Chi


Theo VTV

(Quantrimang) - 13/5/2007 12h:50

Các chuyên gia IT thường mất rất nhiều thời gian để suy nghĩ về bảo mật. Họ cố gắng tìm ra những cách nhanh nhất có thể để đảm bảo cho hệ thống của mình được vá và update kịp thời nhất. Tuy nhiên những gì diễn ra trước khi các quản trị viên này nghe nói đến lỗ hổng hầu như vẫn là bức màn bí ẩn. Để có được bức tranh rõ ràng hơn, chúng ta hãy lắng nghe ý kiến của Mark Cox, đội trưởng đội phản ứng bảo mật của Red Hat về xu hướng trong bảo mật Linux, những ai thường khám phá ra các lỗ hổng bảo mật, tốc độ phát triển của chúng và những biện pháp tối thiểu vấn đề gặp phải có thể thực hiện.

Trước tiên là đôi chút về Mark Cox, chuyên gia bảo mật hàng đầu của Red Hat. Thú vui bảo mật bắt đầu làm Cox hứng thú từ 12 năm trước đây, khi anh phát hiện ra một số vấn đề bảo mật ở Web Server HTTPd của National Center for Supercomputing Aplications (NCSA) - Trung tâm quốc gia về các ứng dụng siêu máy tính. “Nhanh chóng sau đó tôi thấy rằng tổ chức hoạt động C2Net châu Âu, nơi tôi phát triển sever Web Stronghold đặc biệt nằm bên ngoài nước Mỹ. Bởi vậy chúng tôi có thể phân phối cơ chế mã hoá SSL mạnh nhất ra toàn thế giới. Red Hat mua lại C2Net và giờ thì tôi ở đây”, Mark Cox tâm sự. Ngoài thời gian chính làm việc cho Red Hat, Cox còn tham gia đội bảo mật của Apache Software Foundation và nhóm OpenSSL những lúc rảnh rỗi.

Vậy, công việc của một thành viên đội phản ứng bảo mật là gì? Theo Cox, đội của anh chịu trách nhiệm đảm bảo cho các lỗ hổng bảo mật phải được xử lý. “Đó là quá trình bao gồm rất nhiều công đoạn, từ làm việc với các nhà nghiên cứu đến giám sát để tìm ra vấn đề tác động, thông qua chọn lựa xử lý và thanh tra để giám sát quá trình phát hành”.

Ngoài ra, mỗi thành viên của đội còn phải tư vấn, trả lời câu hỏi của khách hàng về lỗ hổng. “Trong năm ngoái, chúng tôi đã đáp ứng được 98% nhu cầu hỏi đáp mỗi ngày của khách hàng”, theo Mark.

Một thắc mắc thường đến với những người quan tâm là có bao nhiêu người làm việc trong lĩnh vực bảo mật ở các hãng lớn như Red Hat? Con số chính xác không được tiết lộ nhưng vị đội trưởng này bật mí là số lượng kỹ sư được phân bổ tuỳ thuộc vào từng lỗ hổng.

“Số lượng kỹ sư hoạt động full-time phân bổ trên khắp thế giới cho phép chúng tôi kiểm soát tốt dịch vụ bao quát trên khắp các vùng, bất chấp sự sai khác về múi giờ, và chúng tôi luôn không ngừng tìm kiếm thêm các kỹ sư tài năng. Khi gặp sự cố, chuyên viên ở mỗi vùng sẽ nhanh chóng được cử đến để xử lý giải quyết vấn đề. Vì thế, số lượng nhân viên Red Hat làm việc trong lĩnh vực bảo mật thay đổi theo mỗi tuần”.

Thành viên của đội bảo mật thường truy cập và biết về thông tin lỗ hổng trước khi chúng được công bố ra ngoài. Nhưng đó mới chỉ là “một nửa”, tức là Red Hat có thời gian xử lý vấn đề nếu một lỗ hổng phát sinh trước khi nó trở thành kiến thức chung cho mọi người. Nhưng điều đó không phải lúc nào cũng đúng. “Phát hiện được vấn đề nhanh chóng giúp chúng tôi có khả năng làm việc với đối tác để cung cấp bản vá kịp thời, tìm kiếm các vấn đề tương tự ở những vùng mã tương tự, thực hiện thêm các kiểm tra và phối hợp với các phân phối bị tác động khác”.

Ngay từ khi lỗ hổng chưa được công bố, đội bảo mật đã phải luôn tìm cách xử lý càng nhanh càng tốt. Hai năm trở lại đây, thời gian từ lúc bắt đầu phát hiện lỗ hổng đến khi đưa ra biện pháp xử lý ở Red Hat được quy định trong vòng 7 ngày. Đối với những vấn đề cực kỳ nghiêm trọng, thành viên của đội bảo mật phải làm việc liên tục để tìm ra giải pháp trong vòng 2 ngày.

“Cha ơi, lỗ hổng đến từ đâu?”

Đứa bé ngây thơ hỏi cha mình, một chuyên gia bảo mật. Và chúng ta cũng vậy, những người dùng nghiệp dư, chỉ như một đứa trẻ bi bô trước thế giới bảo mật bí hiểm. Chính xác, lỗ hổng bảo mật được khám phá như thế nào? Trên website của mình, Mark Cox phân tích nguồn thông tin bảo mật của Red Hat từ tháng 3 năm 2005 đến tháng 3 năm 2007. Điểm anh đặc biệt nhấn mạnh là liệu Red Hat có nhận được thông tin trước khi lỗ hổng trở nên phổ biến hay không.

Nguồn thông tin hàng đầu lại đến từ các hãng FLOSS khác, như nhiều báo cáo của hãng đối thủ FireFox. Trong nhiều trường hợp, Red Hat biết đến vấn đề từ phía các hãng FLOSS khác, hay từ những dự án phân tích ngược trước khi chúng trở nên phổ biến.

Nhưng ai là những người thường tìm ra lỗ hổng khi chúng bắt đầu xuất hiện và tìm ra như thế nào? Với Red Hat thì có một số cách, có thể là kiểm tra ngay khi mới phát hành sản phẩm và đôi khi lại là tìm ra từ kết quả của các bản báo cáo lỗi về vấn đề khác. “Các dự án phân tích ngược và các phân phối đôi khi thực hiện kiểm định hoặc chạy công cụ phân tích mã. Một số vấn đề bảo mật được phát hiện từ đó, và nhiều khi chính khách hàng là người ghi nhận và thông báo cho chúng tôi các lỗi bất cập để cuối cùng chúng tôi có kết quả bảo mật hoàn chỉnh”.

Hãy ngăn chặn vấn đề trước khi để nó xảy ra

Sửa chữa các vấn đề bảo mật sau khi đã diễn ra được ví như việc dập tắt ngọn lửa sau khi nó đã thiêu rụi căn nhà, chỉ là sự xác nhận tổn thất chứ không phải cách giải quyết vấn đề hiệu quả. Đó là lý do vì sao Red Hat và các hãng Linux khác sử dụng nhiều công nghệ “phòng hơn chống” nhằm giảm thiểu các vấn đề bảo mật. Ví dụ như SELinux và Exec-Shield, có thể bảo vệ hệ thống bằng cách ngăn chặn một số kiểu cụ thể.

Trong bài viết đưa lên hồi tháng 4, Cox mô tả một số thành phần bảo mật khác nhau trong phiên bản Red Hat Enterprise Linux (RHEL) 3 và 4 và các kiểu lỗ hổng chúng có thể xử lý.

Ví dụ như về “double-free”, là lỗ hổng trong đó hàm free() được gọi tới hai lần cho cùng một địa chỉ bộ nhớ, có thể dẫn đến lỗi tràn bộ đệm. Theo bài báo, lỗi này là nguyên nhân dẫn đến “những lỗ hổng cao hơn của các dịch vụ như wu-ftpd và CVS pserver” trong năm 2003, trước khi các đội bảo mật có thể xử lý được vấn đề.

Năm 2004, một lỗi double-free đã được tìm thấy và công bố ở Trung tâm Phân phối MIT Kerberos 5 Key Distribution Center. Tuy nhiên, RHEL 4 đã tích hợp được khả năng chống lại lỗ hổng nên “chúng tôi giảm được đáng kể tính nguy hiểm của vấn đề vì kỹ thuật glibc hardening đã hoàn toàn ngăn chặn được các hoạt động khai thác lỗ hổng double-free”.

Không phải tất cả các lỗ hổng đều giống nhau

Khi Red Hat thông báo về một lỗ hổng, bao giờ hãng cũng đính kèm mức độ nguy hiểm mà nó có thể gây ra. Chúng được đánh giá dựa trên nguyên tắc bốn điểm, từ những lỗ hổng nghiêm trọng cho phép một kẻ tấn công từ xa xâm nhập hệ thống mà không cần bất kỳ tương tác người dùng nào (mức nghiêm trọng) cho đến một số kiểu tác động bảo mật nguy hiểm nhưng rất khó thực thi hoạt động khai thác trên một hệ thống hay những lỗ hổng không để lại hậu quả nguy hiểm gì (mức thấp).

Red Hat không thay đổi kiểu phân loại bảo mật dựa trên khả năng kiểm soát nó. Mà thay vào đó: “Chúng tôi định nghĩa mức độ nguy hiểm đối với người dùng dựa trên khả năng của cả lỗ hổng và mức độ đe doạ. Tỷ lệ chúng tôi cung cấp cho các tư vấn viên chỉ hoàn toàn dựa trên lỗ hổng và được điều chỉnh để khớp với các hãng khác như Microsoft và Apache. Do mức độ đe doạ thay đổi theo thời gian và dựa chủ yếu trên cấu hình, sự sử dụng của người dùng cuối, chúng tôi không thông báo về nó nữa”.

Linux đang ngày càng có nhiều lỗ hổng hơn?

Vài năm trở lại đây, Linux ngày càng trở nên phổ biến. Và danh sách những lỗ hổng đặc biệt chỉ có ở Linux cũng dài thêm. Đội trưởng Mark cho hay Red Hat vừa mới ngừng quá trình tìm kiếm lỗi có thể khai thác ở RHEL 4 trong hai năm đầu phát hành nhưng mọi sự dường như không chỉ có vậy. “Có nhiều cách khai thác phổ biến cho 37 lỗ hổng được phát hiện. Nhiều trong số chúng được tìm thấy theo những sáng kiến bảo mật khác nhau, nhưng một số là do cấu hình không phù hợp và số khác thì hoạt động không như mong đợi. Với một lỗ hổng ở nhân kernel, người dùng cục bộ có thể giành được đặc quyền root trên một máy chưa được update bản vá kịp thời. Và một số lỗ hổng còn hoạt động chống lại các trình duyệt Web không được vá lỗi”.

“Ngoài các lỗi trình duyệt Web, thực ra ngày nay không có nhiều lỗ hổng từ xa cho kẻ tấn công có thể khai thác. Ví dụ như trường hợp cài đặt mặc định Enterprise Linux 4 AS chỉ gây ra ba vấn đề bảo mật nghiêm trọng trong hai năm đầu tiên phát hành”.

T.Thu (Theo Linux)

Ứng dụng đa phương tiện được dùng rất phổ biến Winamp hiện đang trở thành mục tiêu tấn công của tin tặc. Mã độc tấn công một lỗ hổng bảo mật chết người trong ứng dụng này đã được tin tặc tung lên mạng.

Lỗ hổng bảo mật đang bị lợi dụng là một lỗi trong tính năng giải mã chuẩn định dạng tệp tin MP4 của Winamp. Lỗi này có thể bị lợi dụng để tuồn thêm nhiều mã độc hơn vào trong hệ thống mắc lỗi.

Lỗi chỉ tồn tại duy nhất trên phiên bản Winamp 5.34.

Tuy nhiên, để khai thác thành công lỗi bảo mật này là một điều không dễ dàng. Chính vì thế mà nguy cơ người dùng bị tấn công sẽ không cao.

"Để thành công tin tặc phải tìm được hệ thống có cài đặt bản Winamp mắc lỗi và được chỉ định là ứng dụng mặc định chạy các tệp tin MP4. Nhưng thường Winamp không tự động mở các tệp tin MP4 nhúng trong các website," Trung tâm máy tính Viện nghiên cứu SANS cho biết.

Người dùng chỉ có thể bị tấn công nếu họ mở tệp tin MP4 độc hại do tin tặc gửi cho họ.

Các chuyên gia bảo mật khuyến cáo người dùng nên loại bỏ chỉ định Winamp là ứng dụng mặc định chạy các tệp tin MP4 và chờ đợi bản vá lỗi từ nhà cung cấp sản phẩm.

Hoàng Dũng

Theo Register, VnMedia