25/02/2017

Đã có website giúp kiểm tra tài khoản của bạn có thể bị ảnh hưởng từ vụ hack CloudFlare

Rất có thể hacker đã biết mật khẩu tài khoản mà bạn đang sử dụng hằng ngày.

Vừa qua, cộng đồng mạng đã dậy sóng nghe nghe tin công ty mạng CloudFlare đã bị lộ dữ liệu. Hiện có khoảng hơn 5,5 triệu website sử dụng CloudFlare, và khả năng cao bạn đang sử dụng những website này hằng ngày, ví dụ như FitBit, Yelp, Medium, CodePen, OKCupid hay Uber. Hiện các dữ liệu của CloudFlare đã bị rò rỉ trong nhiều tháng, nên rất có thể một vài tài khoản của chúng ta đã bị rò rỉ mật khẩu.
Đối với những người dùng thông thường, việc truy cập vào kho dữ liệu bị ăn cắp như này không dễ. Nhưng đối với những người dùng chuyên nghiệp thì việc này dễ như trở bàn này. Travis Ormandy, nhân viên Google đã phát hiện ra lỗ hổng, cho biết:
"Sau khi phát hiện ra điều này, chúng tôi đã tìm được cách thâm nhập vào kho dữ liệu. Nếu một trang web có sử dụng CloudFlare và có sử dụng những tổ hợp tag không cân bằng (unbalanced tags), máy chủ proxy sẽ rải các trang bộ nhớ chưa định hình (pages of uninitialized memory) vào dữ liệu đầu ra. Chúng tôi đã thử và nhận thấy lỗ hổng này khai thác quá dễ dàng, nên chúng tôi liên hệ với bên an ninh của CloudFlare ngay lập tức".
Theo CloudFlare cho biết, chỉ có khoảng 0,00003% số trang HTTP bị rò rỉ. Giờ đây nó đã được vá lỗi, nhưng các hacker vẫn có thể tìm dữ liệu đó qua cache, tuy nhiên nhà nghiên cứu an ninh Ryan Lackey cho rằng sự việc này không phải là tận thế.
Như vậy để đảm bảo an toàn cho tài khoản của mình, chúng ta nên đổi mật khẩu những tài khoản trên trang web có sử dụng CloudFlare. Does it use CloudFlare là trang web để kiểm tra xem website nào đó có sử dụng CloudFlare, và liệu nó có ảnh hưởng bởi vụ tấn công hay không. Hãy thực hiện việc này càng sớm càng tốt để cho các hacker không có cơ hội lấy những thông tin cá nhân cho mục đích tống tiền.
Tham khảo The Next Web

24/02/2017

Lỗ hổng nghiêm trọng rò rỉ thông tin của hàng triệu website sử dụng CloudFlare


Thứ sáu tuần trước, Tavis Ormandy từ Project Zero của Google đã liên lạc với CloudFlare để báo cáo một vấn đề an ninh với các máy chủ của CloudFlare.


Cloudflare dịch vụ CDN rất nổi tiếng và thông dụng vừa có 12h căng thẳng để khắc phục một lỗi Memory Leak trên hệ thống CDN của họ (nguyên do là module HTML Parser của họ có lỗi), lỗi này khiến hacker có thể đọc được 1 phần dữ liệu của các request đang được Reverse Proxy (Nginx) của Cloudflare xử lý trong bộ nhớ, dễ hiểu là user đăng nhập vào website A có dùng dịch vụ CDN của Cloudflare thì có thể bị hacker lấy được session cookie hay dữ liệu text nhạy cảm của trang mà họ đang coi.

Lỗ hổng mới có tên Cloudbleed gần giống với lỗ hổng Heardbleed được phát hiện vào năm 2014 nhưng có mức độ nguy hiểm cao hơn. Lỗ hổng không chỉ ảnh hưởng tới website trong mạng CloudFlare mà còn cả trên ứng dụng di động.

Cloudbleed là gì ?
Cloudbleed là một lỗ hổng nghiêm trong trong mạng Cloudflare khiến rò rỉ khóa riêng tư, các thông tin nhạy cảm của website sử dụng Cloudflare.
Cloudflare đóng vai trò như một proxy giữa người dùng và máy chủ web, làm bộ đệm cho các website trong mạng,  giúp tăng tốc và đảm bảo an toàn cho các website. Ormandy đã phát hiện một lỗ hổng tràn bộ đệm tại một máy chủ Cloudflare, trả về kết quả bộ nhớ chứa thông tin riêng tư như HTTP cookie, token xác thực, HTTP POST và một số dữ liệu khác.


CloudFlare đã xử lý lỗ hổng nhưng không hề thông báo tới người dùng, do đó Ormandy đã công bố phát hiện của mình theo đúng chính sách của Project Zero. CloudFlare xác nhận lỗ hổng và đảm bảo rằng khóa riêng tư SSL của người dùng không hề bị rò rỉ. Ngoài ra CloudFlare còn cho biết từ ngày 13/2 đến 18/2 chỉ có 1 trong 3,300,000 HTTP request có nguy cơ bị rò rỉ bộ nhớ, chiếm 0.00003%.

Cloudbleed ảnh hưởng trên cả ứng dụng di động

Trong một phân tích thực hiện bởi NowSecure, hơn 200 ứng dụng iOS được phát hiện sử dụng dịch vụ của CloudFlare trong hơn 3,500 ứng dụng phổ biến được lấy mẫu. Một số khách hàng lớn của CloudFlare bị ảnh hưởng bao gồm Uber, 1Password, FitBit, và OKCupid
Danh sách các webiste có nguy cơ bị ảnh hưởng được đăng tải bởi người dùng trên GitHub bao gồm CoinBase, 4Chan, BitPay, DigitalOcean, Medium, ProductHunt, Transferwise, The Pirate Bay, Extra Torrent, BitDefender, Pastebin, Zoho, Feedly, Ashley Madison, Bleeping Computer, The Register, …
Người dùng được khuyến cáo thiết đặt lai toàn bộ mật khẩu trong trường hợp bạn dùng chung mật khẩu trên nhiều website.


Chi tiết tại: https://blog.cloudflare.com/incident-report-on-memory-leak-caused-by-cloudflare-parser-bug/


22/02/2017

TeamViewer bị hack ? Những gì người dùng cần làm ngay!

Nếu bạn đã cài đặt phần mềm điều khiển từ xa TeamViewer, rất có khả năng hệ thống của bạn sẽ bị truy cập bởi tin tặc nhằm đánh cắp thông tin cá nhân, bao gồm cả tài khoản ngân hàng, tài khoản PayPal…
Theo báo cáo gần đây của người dùng trên Reddit và Twitter, phần mềm điều khiển từ xa TeamViewer dường như đã bị hack. Teamviewer là phần mềm kết nối giữa 2 hay nhiều máy tính với nhau giúp người dùng có thể điều khiển máy tính khác, gửi file, video, chat…
Chỉ trong vòng vài ngày, một lượng lớn người dùng trên các diễn đàn Internet đã báo cáo về việc tin tặc chiếm kiểm soát máy tính của họ thông qua tài khoản TeamViewer và trong một vài vụ việc, tin tặc đã cố đánh cắp tiền từ các dịch vụ như eBay hay PayPal.
Theo báo cáo của một chuyên gia bảo mật IBM Nick Bradley cho biết : “Trong khi chơi trò chơi, tôi đã bị mất kiểm soát chuột và cửa sổ TeamView hiển thị dưới góc phải màn hình. Ngay sau khi nhận ra tôi đã tắt ứng dụng và phát hiện ra có một thiết bị khác sử dụng tài khoản TeamViewer của tôi”

Vậy điều gì thực sự đã xảy ra với TeamViewer ?
Đến thời điểm hiện tại, vẫn chưa có câu trả lời cho câu hỏi trên. Không có bằng chứng cho thấy xảy ra hệ thống bảo mật của TeamViewer bị xâm nhập trên diện rộng cho phép tin tặc backdoor truy cập vào máy tính người dùng. TeamViewer cũng phản ứng mạnh mẽ bằng cách phủ nhận hoàn toàn việc bị xâm nhập dẫn đến mạng của TeamViewer bị hack.
Cùng thời điểm người dùng báo cáo bị xâm nhập, TeamViewer cũng bị tấn công từ chối dịch vụ khiến một vài máy chủ bị sập nhưng công ty đã đưa chúng hoạt động trở lại trong vài giờ. TeamViewer nhắc tới các vụ tấn công rò rỉ dữ liệu gần đây để lộ 642 triệu mật khẩu. Người dùng đầu cuối thường xuyên sử dụng chung mật khẩu cho nhiều tài khoản. Công ty đưa ra khuyến cáo sau:
  • Sử dụng mật khẩu khác nhau cho mỗi tài khoản
  • Sử dụng xác thực hai nhân tố
  • Sử dụng công cụ quản lý mật khẩu
  • Không cho ai biết mật khẩu của bạn
TeamViewer cũng thông báo đưa hai tính năng mới nhằm nâng cao bảo mật của người dùng đó là :
  1. Trusted Devices: Tính năng đặc biệt ngăn chặn hacker chiếm kiểm soát tài khoản TeamViewer của người dùng. Tính năng cho phép người dùng kiểm duyệt một thiết bị mới trước khi truy cập bằng tài khoản TeamViewer lần đầu tiên.
  2. Data Integrity: Tính năng hoạt động tự động bằng cách theo dõi hành vi người dùng. Nếu phát hiện hành vi bất thường, dịch vụ sẽ buộc người dùng phải reset mật khẩu.
THN

21/02/2017

Tấn công hệ thống vệ tinh viễn thông Iridium


Tấn công hệ thống mạng viễn thông gồm 66 vệ tinh Iridium đang hoạt động trên quỹ đạo Trái Đất, mạng lưới vệ tinh cung cấp dịch vụ điện thoại vệ tinh trên toàn cầu. Cơ chế của hệ thống Iridim không phải là bảo mật kém, mà chính xác là nó hoàn toàn không bảo mật dữ liệu.
Xem Video bài tường thuật Tấn công hệ thống vệ tinh Iridium: https://download.visudo.info/IoT/Iridium-Hacking/

17/02/2017

Yahoo lần thứ 3 công bố rò rỉ thông tin người dùng


Vận đen vẫn tiếp tục đeo bám Yahoo khi mới đây công ty này đã công bố vụ rò rỉ thông tin người dùng lần thứ 3 chỉ trong vỏn vẹn 5 tháng. Thông qua việc sử dụng cookie giả, kẻ xấu đã truy cập vào tài khoản Yahoo mà không cần nhập mật khẩu. Tạm thời vẫn chưa biết có bao nhiêu tài khoản bị ảnh hưởng bởi đợt rò rỉ thông tin này.


Trên thực tế, Yahoo đã nhận được báo cáo về những hoạt động làm giả cookie từ tháng 11 năm ngoái. Tuy nhiên có khả năng báo cáo này đã bị lướt qua vì cách đó không lâu hãng vừa công bố đợt rò rỉ thông tin ảnh hưởng đến hơn 1 tỷ tài khoản. Và phải đến tuần này thì Yahoo mới chính thức thức đưa ra cảnh báo đến người dùng.


Hiện tại Yahoo đã vô hiệu hóa các cookie giả, tuy nhiên từ 2015 đến 2016 đã có rất nhiều tài khoản đã bị truy cập trái phép.


Yahoo cho biết cả 3 đợt tấn công khiến rò rỉ thông tin người dùng đều là do một nhóm hacker làm, dưới sự tài trợ của "chính phủ". Tuy nhiên đến thời điểm này thì vẫn chưa có bằng chứng xác thực.


Verizon hạ giá mua lại Yahoo thấp hơn 250 - 350 triệu đô do 2 vụ rò rỉ thông tin người dùng. Không biết vụ thứ 3 này Yahoo sẽ ra sao?!

16/02/2017

Windows Trojan phát tán mã độc MIRAI nhằm tấn công nhiều thiết bị IoT

MIRAI –  mã độc nền tảng Internet of Thing (IoT – mạng lưới vạn vật kết nối Internet) đang được phát tán thông qua một mã độc khác trên Windows. MIRAI có khả năng tấn công từ chối dịch vụ khiến các thiết bị đồng loạt ngừng hoạt động trong tháng 10/2012.

Các nhà nghiên cứu đến từ công ty bảo mật Nga Dr.Web đã phát hiện ra một loại Trojan mới trên Windows. Trojan này được thiết kế nhằm mục đích giúp tin tặc phát tán mã độc Mirai sang nhiều thiết bị khác nhau.
Mirai là một phần mềm độc hại nền tảng Linux trên thiết bị IoT. Mã độc rà soát các thiết bị kém an toàn, biến chúng thành mạng ma botnet, rồi sử dụng trong tấn công DDoS, và phát tán thông qua Telnet .
Sau khi cài đặt trên thiết bị Windows, Trojan sẽ kết nối đến máy chủ điều khiển (C&C) rồi tải về một tệp tin cấu hình chứa một dải IP kết nối thông qua một số cổng như 22 (SSH), 23 (Telnet), 135, 445, 1433, 3306, 3389. Trong trường hợp của hệ thống Linux kết nối thông qua giao thức Telnet, mã độc tải về một tệp tin binary trên thiết bị rồi tải về Linux.Mirai.
Bên cạnh đó, mã độc còn có khả năng nhận diện và tấn công dịch vụ cơ sở dữ liệu trên các cổng khác nhau, bao gồm MySQL và Microsoft SQL để tạo ra các tài khoản quản trị rồi đánh cắp cơ sở dữ liệu.
Theo: THN

13/02/2017

Lỗ hổng bảo mật trên Beat.vn ảnh hưởng tới hàng triệu người dùng.

Lỗ hổng bảo mật trên Beat.vn ảnh hưởng tới hàng triệu người dùng.
Beat.vn là một mạng xã hội có số lượng thành viên cũng như lượng truy cập khá lớn tại Vietnam. Nổi tiếng với các tin tức hot, hóng biến, bóc phốt,… rất thu hút người xem. Với những đặc điểm như vậy, có lẽ rằng vấn đề bảo mật sẽ được quan tâm hàng đầu tuy nhiên với những thông tin đưa ra trong bài viết này, đơn vị chủ quản của Beat.vn nên có những hành động để đảm bảo an toàn cho ứng dụng, cũng chính là bảo vệ các thông tin của những người dùng đã đăng ký tài khoản.
Lỗ hổng được tìm thấy là một lỗi đã quá kinh điển trong lập trình phần mềm – SQL Injection. Tuy nhiên lỗi xảy ra khi thực hiện insert/update DB – điều mà theo kinh nghiệm trong quá trình audit source code trên các ngôn ngữ – framework ,tôi thấy khá ít gặp phải bởi hầu hết các framework phát triển ứng dụng đều đã hỗ trợ sẵn các hàm insert/update dữ liệu an toàn với tham số truyền vào là một object hoặc một param.
Đây là một lỗi Error Based SQL Injection, điều này cũng chỉ ra rằng việc xử lý với các error/exception của ứng dụng là chưa tốt. Trong phát triển ứng dụng, việc xử lý khi gặp lỗi hay các exception sẽ hạn chế việc để lộ lọt các thông tin nhạy cảm có thể có ích cho cuộc tấn công của hacker.
Với trường hợp insert/update dữ liệu nhưng không view được lại các dữ liệu đó, kỹ thuật Time Based có thể sử dụng để trích xuất dữ liệu từ DB. Tuy nhiên với việc không kiểm soát thông báo lỗi trên, khai thác tấn công sẽ dễ dàng hơn với kỹ thuật Error Based/ Double query. Ví dụ Payload lấy thông tin version:
Dựa vào thông báo lỗi từ server, tôi có thể lấy được toàn bộ dữ liệu từ DB, trong đó bao gồm cả thông tin của hàng trăm nghìn tài khoản người dùng bao gồm email, mật khẩu, các thông tin liên quan đến Facebook người dùng,…
Vấn đề của Beat.vn không phải chỉ là lỗ hổng về lập trình an toàn SQL injection này mà còn liên quan đến giải pháp:
Việc tôi có thể dễ dàng inject các câu query mà không hề gặp phải một filter nào cho thấy ứng dụng chưa có hệ thống bảo vệ vòng ngoài – ví dụ như 1 WAF chẳng hạn. Một ứng dụng với số lượng người dùng và truy cập lớn như vậy nên có những giải pháp chặn/lọc để đảm bảo security hơn.
Tiếp theo, vấn đề nữa mà tôi nghĩ khá quan trọng là giải pháp về cơ chế mã hóa thông tin mật khẩu của ứng dụng. Mã băm của mật khẩu người dùng được tạo theo thuật toán hashedPassword = MD5(password) – khá bất ngờ khi đó là MD5 và không Salt. Điều này dẫn đến nguy cơ rất lớn đối với người dùng:
Nếu như hàng trăm ngàn thông tin tài khoản người dùng Beat.vn bị leak thì số lượng mật khẩu có thể crack là không nhỏ. Và trong số đó cũng sẽ không ít người dùng sử dụng mật khẩu của beat.vn giống với mật khẩu email, mật khẩu Facebook,.. của họ. (Chưa kể DB còn lưu trữ các thông tin liên quan đến Facebook người dùng đăng ký như FbId, FbToken). Và như vậy, từ việc hack được tài khoản beat.vn, kẻ tấn công có thể chiếm thêm các tài khoản email, facebook. Tất nhiên một khả năng nữa dẫn tới việc tài khoản người dùng cũng có thể bị leak là bởi chính từ nội bộ của beat.vn – tại sao lại không bởi con người luôn là mắt xích yếu nhất trong vấn đề an toàn thông tin. Chính vì vậy, người phát triển ứng dụng cần bảo vệ tốt nhất cho người dùng bằng cách sử dụng 1 thuật toán mạnh hơn và có kèm với random Salt trong việc hash mật khẩu. Ví dụ:
hashedPassword = SHA512(password + randomSalt)
Lỗ hổng bảo mật này ảnh hưởng trực tiếp tới toàn bộ tài khoản đăng ký và những phân tích trên cho thấy vấn đề security của ứng dụng là chưa tốt, vì vậy khuyến nghị Beat.vn nên có một số hành động cần thiết sau:
  • Gửi thông báo khuyến cáo người dùng đổi mật khẩu mới (khuyến cáo thêm với người dùng nào dùng chung mật khẩu cho beat.vn lẫn email, facebook thì nên đổi cả mật khẩu vào các ứng dụng khác này)
  • Thực hiện pentest và audit lại toàn bộ các ứng dụng (web app, mobile app,…)
Rất hoan nghênh việc khắc phục lỗ hổng khá kịp thời của BeatTeam kể từ khi nhận được cảnh báo của Nightst0rm vào ngày 07/2/2016. Hi vọng tiếp theo các bạn có thể tiếp tục thực hiện sửa đổi về mặt lập trình an toàn, bổ sung thêm giải pháp an toàn dựa vào một số vấn đề được chỉ ra trong bài viết này để đảm bảo security cho ứng dụng cũng như cho các tài khoản người dùng.
Nhật ký lỗ hổng
06/02/2017: Hóng biến, link 18+ trên Beat. Sau một hồi xem chán chê, thử một vài truy vấn thì phát hiện lỗ hổng
07/02/2017: Thông báo lỗi cho Beat
08/02/2017: Beat khắc phục lỗi, bạn mrcool8x – đại diện BeatTeam gửi lời cảm ơn NightSt0rm. NightSt0rm xác nhận lỗi đã fix và đưa ra dự định sẽ công bố lỗ hổng trong 2 ngày tới.
Theo: nightst0rm

10/02/2017

HTTPS hoạt động như thế nào?

Chữ ký điện tử là cơ chế bao gồm 3 thuật toán:
  • Thuật toán chọn một khóa bí mật (private key) từ 1 tập các khóa một cách ngẫu nhiên
  • Thuật toán ký. Đầu vào là 1 thông điệp và khóa bí mật. Đầu ra là một chữ ký.
  • Thuật toán kiểm tra chữ ký. Đầu vào là một thông điệp, khóa công khai, và chữ ký. Đầu ra là đồng ý hay từ chối tính thẩm quyền của thông điệp
Do vậy để có chữ ký điện tử, ta cần có thuật toán cho phép  và kiểm tra chữ ký.
Chuyện gì sẽ xảy ra khi browser truy cập 1 site có https
Quá trình browser truy cập 1 site https có thể được mô tả bằng hình ảnh dưới đây (copy từ http://stackoverflow.com/questions/470523/how-does-ssl-really-work)
  1. Browser sẽ truy cập 1 trang web https. Ở đây là https://payment.com
  2. Server hay Load Balancer (LB) của payment.com sẽ trả về certificate để chứng thực rằng website user đang truy cập là website chính thức. Trong certificate là một public key PK, dùng để mã hóa K ở bước 4.
  3. Browser sẽ kiểm chứng certificate (bằng cách chạy thuật toán kiểm tra chữ ký). Quá trình này giúp browser xác định https://payment.com là thật hay giả.
  4. Sau khi kiểm chứng được certificate, browser sẽ tự sinh ra 1 khóa K. Khóa K sẽ được dùng để mã hóa tất cả các liên lạc giữa browser và payment.com sau này. Do quá trình mã hóa các gói tin dùng mã đối xứng, khóa K cần được gửi trở lại payment.com vì nếu không có K, server (LB) không thể nào giải mã được gói tin.
  5. Khóa K được gửi trả lại cho payment.com. Phía payment.com sẽ dùng private key (được bảo vệ) để giải mã gói tin này và qua đó có được thông tin về K.
  6. payment.com và browser dùng khóa K để mã hóa toàn bộ dữ liệu liên lạc sau này.
Certificate là một khối dữ liệu bao gồm rất nhiều thông tin về payment.com. Các thông tin này bao gồm:
  • Tên domain
  • Tên công ty sở hữu
  • Thời gian certificate được cấp
  • Thời hạn certificate
  • Public key PK
Làm thế nào browser kiểm chứng được certificate ở bước 3
Bất cứ người nào đứng giữa browser và payment.com đều có thể làm giả certificate và public key. Bằng cách làm giả certificate, người đứng giữa có thể giả dạng payment.com. Bằng cách giả public key, người đứng giữa có thể dùng khóa private của mình để xem thông tin truyển tải giữa 2 bên. Vậy làm thế nào để ngăn chặn cách tấn công này. Cách giải quyết là: CA (Certificate Authority).
CA là gì? Làm gì?
Trong thực tế, để chứng minh một ai đó trình độ đại học, trường đại học nơi người đó học sẽ cấp cho họ một tấm bằng. Do tấm bằng đó có thể bị làm giả, ta cần một đơn vị chứng minh đó là bằng thật. CA chính là người chứng minh certificate mà payment.com cung cấp là thật! CA bán dịch vụ chứng thực đó bằng cách ký chứng minh rằng certificate của payment.com là thật
Certificate chứng thực cho payment.com sẽ được CA  bằng khóa bí mật của CA. Khóa này chỉ có CA biết và do vậy việc chữ ký là an toàn. payment.com sẽ gửi cho user certificate đã được ký bởi CA cùng với khóa công khai PK2 của khóa bí mật CA dùng để ký certificate. Browser sẽ tiến hành kiểm tra certificate này như bình thường dùng khóa công khai PK2 của CA.
Đến đây vấn đề chưa thực sự được giải quyết vì, khóa công khai của CA cũng hoàn toàn có thể bị làm giả và do vậy certificate hoàn toàn có thể là giả! Giống như thực tế người chứng minh cho tấm bằng đại học cũng có thể bị làm giả. Để chắc chắn việc này, ta có thể ký chứng thực certificate do CA ký là thật. Cách làm có thể hoàn toàn tương tự là dùng khóa bí mật nào đó và ký tiếp và đính kèm khóa công khai PK3 với certificate sau khi được ký. Cứ thế ta có một dãy các certificate và khóa công khai mà certificate sau chứng thực cho certificate trước. Do bản chất đệ quy, ta cần điểm dừng là một certificate mà ta hoàn toàn tin tưởng. Đến đây ta có khái niệm root certificate.
Root certificate
Root certificate là certificate mà ta hoàn toàn tin tưởng. Khi có certificate này, ta có thể tin tưởng những certificate mà được chứng thực bởi certificate này là hoàn toàn hợp lệ (giống trong thực tế là cơ quan công chứng!). Mỗi OS và browser có một danh sách các certificate mà OS và browser đó tin tưởng.
Firefox tin tưởng các certificate có danh sách tại: https://wiki.mozilla.org/CA:IncludedCAs
RHEL có danh sách các certificate tin tưởng tại: /etc/pki/tls/certs/
Do root certificate là certificate cuối cùng dùng để chứng thực các certificate trong chuỗi, khóa bí mật của certificate này cần được bảo vệ nghiêm ngặt. Bất cứ công ty cung cấp dịch vụ CA nào bị tấn công và bị mất khóa bí mật của root certificate đều rất nguy hiểm, bởi vì hackers có thể dùng khóa đó để ký certificate ở bước cuối cùng. Do browser và OS tin tưởng certificate này nên tất cả certificate, không nhất thiết do CA bị hack cung cấp, đều có thể bị làm giả. Các CA do vậy dùng rất nhiều công sức để bảo vệ thật kín đáo khóa bí mật này. Kinh doanh chứng thực CA là kinh doanh về mặt lòng tin, CA hứa sẽ đảm bảo tốt nhất khóa bí mật của họ và ta trả tiền để họ dùng khóa bí mật của họ ký.
Xem certificate chain trong thực tế
Đến đây ta chắc đã hiểu phần nào về cơ chế chứng thực cũng như cách hoạt động của HTTPS. Ta sẽ cùng xem chuỗi certificate trong thực tế.
alt text

Facebook certificate được ký bởi DigiCert High Assurance CA-3. Bản thân CA-3 được chứng thực bởi EV RootCA.
Các vấn đề liên quan đến https / certificate
Nguyên tắc hoạt động là như vậy, trong thực tế để duy trì và vận hành một hệ thống https cần tốn khá nhiều công sức. Dưới đây là một số case-studies mình gặp trong quá trình vận hành một website. Qua một số case-studies này hy vọng bạn sẽ hiểu tầm quan trọng của mỗi sự kiện và ý nghĩa của nó.
Heartbleed
Sự kiện heartbleed là sự kiện đình đám của năm 2014. Heartbleed là lỗi bảo mật nằm trong bộ thư viện OpenSSL, bộ thư viện chủ đạo xử lý mã hóa trên Linux. Các webserver đều được build sử dụng OpenSSL nếu muốn phục vụ https.
Heartbleed xảy ra khi openssl không kiểm tra độ dài trả về của một chuỗi ký tự và vô tình trả về thông tin nằm sau chuỗi ký tự này trên bộ nhớ. Vô tình phần bộ nhớ này bao gồm khóa bí mật được dùng để ký certificate ban đầu. Bằng cách hỏi máy chủ cho xem chìa khóa bí mật này, hacker có thể dùng nó để giải mã khóa mã hóa liên lạc ở bước 5 và do đó đọc được toàn bộ nội dung của phiên liên lạc.
Heartbleed nguy hiểm bởi việc tấn công này hoàn toàn không để lại dấu vết.
Các công ty cung cấp dịch vụ qua https đã phải xử lý vấn đề này bao gồm các bước sau:
  • Nâng cấp phiên bản openssl
  • Khởi động lại máy chủ web (apache, nginx)
  • Tạo một khóa bí mật mới, certificate mới và yêu cầu CAs ký lại

Diginostar

Diginostar là hãng CAs của Hà Lan bị hacker tấn công và lấy được khóa bí mật. Từ đó tất cả các root certificate của Diginostar đều bị xóa bỏ khỏi browser, do lo sợ hacker sẽ dùng khóa bí mật này làm giả certificate. Điều này dẫn đến sự phá sản của CA.
Qua đấy mới thấy việc bảo vệ khóa bí mật an toàn là vấn đề sống còn của các CAs.

Superfish

Hãng máy tính Lenovo khi bán máy tính đã cài thêm một phần mềm hiển thị quảng cáo đến người dùng. Khi người dùng lướt net, phần mềm này sẽ tự thêm một quảng cáo nhỏ trên browser. Để có thể thêm quảng cáo vào bất cứ chỗ nào, phần mềm này tự ý cài một root certificate vào máy lenovo bán đi. Root certificate này lại là một certificate tự ký, bất cứ ai có máy lenovo đều có thể có được khóa bí mật ký certificate này. Điều này vô tình biến tất cả người dùng máy lenovo thành đối tượng bị làm giả certificate. Tất cả các liên lạc https đều có thể bị làm giả, do vậy việc làm này đã tạo ra một lỗi bảo mật rất nghiêm trọng.
Hãng Lenovo sau đó đã phải xin lỗi người dùng và đưa ra phần mềm gỡ bỏ tool này.
OS quá cũ
Các root certificate đi kèm với máy chủ không phải có thời hạn mãi mãi mà được làm mới qua mỗi lần release một phiên bản của OS. Do vậy việc update OS thường xuyên là điều nên làm. Tuy vậy đối với các máy chủ làm việc bận rộn, việc nâng cấp nhiều khi là điều khó khăn. Từ đây nảy sinh một vấn đề như sau.
Máy chủ thỉnh thoảng hay phải gọi các https thông qua curl, ví dụ gọi twitter api qua https, hay gọi một dịch thanh toán nào đó qua Https. Giống như browser, curl dùng root certificate đi kèm để chứng thực các certificate phía dịch vụ gửi về. Tuy vậy khi root certificate hết hạn, việc chứng thực này sẽ thất bại, kéo theo việc app của bạn sẽ không chạy đúng nữa. Những lúc này việc update root certificate là việc cần phải làm.
Kết luận
Bài viết trình bày khái quát nguyên tắc hoạt động của https cũng như các vấn đề xoay quanh liên lạc dùng https. Hy vọng qua bài viết bạn hiểu rõ hơn về https cũng như lý giải được tầm nghiêm trọng của những vấn đề và sự kiện xoay quanh https.

Re-learning Linux - Permission


Có lẽ hầu hết những người sử dụng Linux đều biết quyền hạn của 1 file hay folder được đại diện bởi r (read), w (write), x (execute) như hình dưới đây:
alt text

Và ta có thể biểu diễn 9 kí tự cuối trong hình trên bằng số theo luật
  • Read = 4
  • Write = 2
  • Execute = 1
  • No Permission = 0
Vậy như hình trên, giá trị số sẽ là: 744 (r + w + x = 7, r = 4, r = 4)
Chúng ta cùng thử kiểm tra quyền của file /usr/bin/passwd :
ls -l /usr/bin/passwd
Và đây là kết quả:
-rwsr-xr-x. 1 root root 27832 Jun 10  2014 /usr/bin/passwd
Điều tôi chú ý là phần permission của file rws's' là gì?
Xét thêm một lệnh nữa:
ls -l -d /tmp # option -d là để hin ththông tin quyền hn ca mt thư mc
Kết quả
drwxrwxrwt. 8 root root 4096 Apr 15 04:44 /tmp
Cũng trong phần permission của thư mục tmp, 't' là gì
Vậy 2 kí tự 's' và 't' là gì?

SUID

Ta cùng quay lại với kết quả của đoạn lệnh ls -l /usr/bin/passwd
Kết quả là -rwsr-xr-x. 1 root root 27832 Jun 10 2014 /usr/bin/passwd
Với passwd là lệnh để thay đổi password của người dùng hiện tại. Khi thực thi lệnh passwd sẽ cố gắng để thay đổi nội dung của 2 file dưới đây:
  • /etc/passwd: File chứa thông tin về username, user id, password đã mã hoá hay chưa...
  • /etc/shadow: File chứa thông tin về password của người dùng và thời gian hiệu lực của password
Như vậy, rõ ràng để chạy được lệnh passwd, user thực thi phải chạy passwd dưới quyền của super user bằng cách thêm sudo vào trước.
foo là một người dùng trên linux. Ta dễ dàng tạo người dùng foo bằng lệnh useradd foofoo có quyền hạn rất hạn chế. Dĩ nhiên foo cũng không có quyền ghi vào file /etc/passwd hay /etc/shadow. Tuy nhiên, foo có thể chạy được lệnh passwd để thay đổi password của chính mình mà không cần thiết phải thêm sudo vào phía trước. Điều này thực hiện được là nhờ SUID, được thể hiện bởi chữ 's' ở phần quyền hạn của owner.
SUID = Set owner User ID up on execution. Người thực thi file sẽ được mượn quyền hạn của người sở hữu tại thời điểm thực thi.
Có hai cách để thực hiện SUID cho file
  • Theo kí hiệu (Symbolic way) chmod u+s file1
  • Theo chữ số (Numberic way) chmod 4750 file1
Tuy nhiên, sau khi chạy lệnh trên, đôi khi bạn sẽ thấy xuất hiện kí tự 'S' chứ không phải 's' như hình dưới đây.
-rwSrw-r--. 
Lý do là do bạn chưa cấp quyền thực thi file1 cho người sở hữu. Thêm đoạn lệnh dưới đây, ta sẽ thấy kí tự 'S' thành 's'
sudo chmod u+x file1
*Utils:
  • Xóa SUID cho file đã set chmod u-s file1
  • Tìm tất cả các file có SUID find / -perm +4000

SGID

SGID = Set Group ID up on execution. Nhóm thực thi file sẽ được mượn quyền hạn của nhóm sở hữu tại thời điểm thực thi.
SGID hoàn toàn giống với SUID, chỉ khác cái là ta set quyền thực thi cho một nhóm. Tương tự như SUID, ta có thể thực hiện SGID theo hai cách như dưới đây:
  • Theo kí hiệu (Symbolic way) chmod g+s file1
  • Theo chữ số (Numberic way) chmod 2750 file1
Xóa SGID
chmod g-s file1

Sticky Bit

Linux là một môi trường đa người dùng đồng thời, vì vậy bên cạnh việc giới hạn quyền nhằm đảm bảo tính an toàn cho hệ thống, Linux cần phải có cơ chế để chia sẻ tài nguyên giữa các người dùng với nhau. Sticky Bit được sinh ra như một công cụ giúp giải quyết vấn đề chia sẻ file hay folder giữa các người dùng.
Quay lại ví dụ với folder tmp. Khi thực thi đoạn lệnh ls -l -d /tmp, ta được kết quả drwxrwxrwt. 8 root root 4096 Apr 15 04:44 /tmp. Kí tự 't' trong phẩn permission drwxrwxrw*t* chính là Stickybit.
Sticky bit được áp dụng cho folder. Nội dung trong folder (file, thư mục con) chỉ được xóa (hoặc đổi tên) bởi người tạo ra chúng hoặc root user.
Có hai cách để thực hiện set Sticky bit cho file
  • Theo kí hiệu (Symbolic way) chmod o+t /opt/dump/
  • Theo chữ số (Numberic way) chmod 1750 /opt/dump/
Remove sticky bit cho folder
chmod o-t /opt/dump/

Tổng kết

Linux là một môi trường đa người dùng đồng thời, vì vậy, việc giới hạn quyền và chia sẻ tài nguyên là một việc hết sức cần thiết nhằm đảm bảo tính an toàn nhưng vẫn linh hoạt của hệ thống. SUID, SGID, Sticky bit sẽ giúp đảm bảo những điều nêu trên một cách rõ ràng và chặt chẽ hơn:
  • SUID = Set owner User ID up on execution - Đại diện bởi 4000
  • SGID = Set owner Group ID up on execution - Đại diện bởi 2000
  • Sticky Bit - Đại diện bởi 1000

Hi vọng bài viết này giúp ích cho những bạn muốn tìm hiểu thêm về permission trong Linux.

07/02/2017

6 dấu hiệu cho thấy smartphone đang bị theo dõi

Chỉ với vài thao tác đơn giản, kẻ gian có thể dễ dàng cài đặt phần mềm gián điệp lên smartphone nhằm đánh cắp thông tin, nghe lén cuộc gọi, giả mạo email...
Hiện nay, vấn đề nghe lén trên điện thoại đang ngày càng trở nên phổ biến, đơn cử như vợ theo dõi chồng, cha mẹ theo dõi con cái, doanh nghiệp đánh cắp thông tin lẫn nhau, gây ảnh hưởng nghiêm trọng đến công việc.
Virus, mã độc và phần mềm gián điệp có thể xâm nhập vào smartphone bằng nhiều cách, chưa kể đến việc người dùng có thể vô tình nhấp vào các liên kết lạ và tự rước phần mềm độc hại về máy, đặc biệt là các thiết bị đã root hoặc jailbreak.
Dưới đây là 6 dấu hiệu cho thấy smartphone của bạn có khả năng đang bị theo dõi mà chúng tôi tổng hợp lại:
1. Hao pin
Đầu tiên, bạn hãy kiểm tra tình trạng và thời gian sử dụng pin trên máy bằng cách vào Settings (cài đặt) > Battery (pin) > Detail recording (bản ghi chi tiết). Lưu ý, vị trí và tên gọi các tùy chọn có thể thay đổi tùy vào thiết bị bạn đang sử dụng.
Tại đây sẽ có một biểu đồ nhỏ thể hiện tình trạng sử dụng pin, phần bạn cần quan tâm chính là On Screen (màn hình bật), nếu khoảng thời gian này thấp hoặc biểu đồ có sự sụt giảm bất thường thì nhiều khả năng đang có phần mềm chạy ngầm trên smartphone.

2. Dữ liệu di động tăng cao hoặc mau hết
Phần mềm gián điệp sẽ luôn chạy ngầm trên hệ thống và gửi dữ liệu liên tục về máy chủ mỗi khi bạn kết nối Wi-Fi hoặc 3G/4G. Đó là lí do tại sao nhiều người thường phải đối mặt với các hóa đơn điện thoại lên đến tiền triệu đồng mỗi tháng hoặc các gói dữ liệu di động hết nhanh hơn so với bình thường.
Nếu đang sử dụng MobiFone, bạn có thể soạn tin nhắn KT Data và gửi đến 999 để kiểm tra lưu lượng 3G/4G còn lại. Ngược lại, đối với các thuê bao Viettel, người dùng chỉ cần cài đặt ứng dụng My Viettel tại địa chỉ https://goo.gl/GXCv08, sau đó, đăng kí tài khoản bằng số điện thoại đang sử dụng.
Bên cạnh đó, bạn cũng nên cài đặt thêm ứng dụng Opera Max cho smartphone tại địa chỉ https://goo.gl/ENfAks, sau đó, nhấp vào menu ở góc trên bên trái và chọn Quản lý ứng dụng. Tại đây, bạn có thể ngăn chặn/cho phép một ứng dụng bất kỳ truy cập Wi-Fi, 3G/4G hoặc chạy nền.
3. Quảng cáo xuất hiện dày đặc
Nếu thấy quảng cáo xuất hiện dày đặc trên các trang web thường hay truy cập, nhiều khả năng thiết bị của bạn đã bị nhiễm phần mềm độc hại. Phổ biến và nổi trội nhất hiện nay chính là trojan Hummer, phần mềm này có nguồn gốc Trung Quốc.

Theo thống kê, trojan Hummer có tốc độ lây lan rất nhanh trên khắp thế giới, đặc biệt ở những nước như Ấn Độ, Indonesia, Thổ Nhĩ Kỳ và Trung Quốc. Dưới đây là danh sách 25 quốc gia hàng đầu bị ảnh hưởng bởi các biến thể trojan Hummer trong sáu tháng đầu năm 2016, trong đó Việt Nam đứng ở vị trí thứ 10 với gần 30.000 thiết bị Android bị lây nhiễm.
4. Hiệu suất thiết bị giảm
HummingBad là một loại trojan tương tự Hummer, sẽ xâm nhập vào thiết bị khi người dùng vô tình tải về các tập tin cài đặt giả mạo (.apk) của những phần mềm nổi tiếng từ các trang web không rõ ràng, đơn cử như Pokemon GO, YouTube, WhatsApp…
Đa phần các phần mềm gián điệp, độc hại thường âm thầm thu thập dữ liệu, đánh chặn nội dung và liên tục gửi về máy chủ do tội phạm mạng chỉ định. Điều này sẽ khiến hiệu suất thiết bị giảm đi đáng kể và hoạt động chậm chạp.
5. Xuất hiện các tin nhắn lạ
Nếu hộp thư đến xuất hiện các tin nhắn có chứa nhiều chữ số, kí tự và biểu tượng thì nhiều khả năng đây là lỗi của phần mềm gián điệp. Ngoài ra, đây cũng có thể là dữ liệu của bạn đã được mã hóa để gửi về máy chủ.
Để hạn chế lây nhiễm, người dùng không nên nhấp vào các liên kết không rõ nguồn gốc, kể cả khi người gửi là bạn bè, cha mẹ hoặc người thân, hãy liên lạc với họ để xác minh lại vấn đề.
6. Chuyển hướng trang web
Dấu hiệu này tương đối khó nhận biết, tuy nhiên, nếu cảnh giác bạn vẫn có thể phát hiện được. Về cơ bản, phần mềm độc hại có thể hoạt động như một proxy, chặn thông tin liên lạc giữa bạn và trang web bạn đang cố truy cập. Sau đó, chuyển hướng người dùng đến một trang web giả mạo và yêu cầu điền thông tin cá nhân, mật khẩu, tài khoản ngân hàng…
Làm thế nào để hạn chế và gỡ bỏ phần mềm độc hại?
- Hạn chế tải và cài đặt các phần mềm bên ngoài Google Play, App Store để giảm thiểu rủi ro.
- Truy cập vào phần Settings (cài đặt) > Apps (ứng dụng) và gỡ bỏ các phần mềm lạ, hãy xác minh thật kĩ và cẩn trọng khi thực hiện việc này.
- Ngoài ra, việc khôi phục cài đặt gốc cũng có thể giúp bạn thoát khỏi tình trạng bị theo dõi. Tuy nhiên, một số loại phần mềm độc hại có thể chiếm được quyền hạn cao nhất trên thiết bị. Do vậy, bạn nên cài đặt phần mềm diệt virus để bảo đảm an toàn cho điện thoại của mình.
Minh Hoàng