Bổ sung làm rối thời điểm gõ phím vào ssh(1)

 (undeadly.org)
3 điểm bởi GN⁺ 2023-08-30 | 1 bình luận | Chia sẻ qua WhatsApp
  • Damien Miller đã commit tính năng làm rối nhằm che giấu thông tin thời gian giữa các lần nhấn phím vào client ssh(1)
  • Với lưu lượng tương tác có ít dữ liệu được gửi, tính năng này dùng truyền theo khoảng cố định, với khoảng mặc định là 20ms
  • Sau lần nhấn phím thật cuối cùng, hệ thống gửi các lần nhấn phím chaff giả trong một khoảng thời gian ngẫu nhiên để làm mờ thêm mẫu thời gian
  • Hoạt động được điều khiển bằng từ khóa ssh_config mới là ObscureKeystrokeTiming
  • Việc triển khai sử dụng mở rộng PING/PONG mới của tầng truyền tải SSH, và sau đó có thể sẽ được đưa sang các hệ thống khác thông qua openssh-portable

Che giấu thời điểm gõ phím của client ssh(1)

  • Damien Miller đã commit hỗ trợ làm rối thời điểm gõ phím cho ssh(1)
  • Tính năng này cố gắng truyền lưu lượng tương tác có ít dữ liệu gửi đi theo khoảng cố định để che giấu khoảng thời gian giữa các lần nhấn phím
    • Khoảng truyền mặc định là 20ms
    • Sau lần nhấn phím thật cuối cùng, hệ thống gửi các lần nhấn phím chaff giả trong một khoảng thời gian ngẫu nhiên
  • Hành vi được điều khiển bằng từ khóa ssh_config mới là ObscureKeystrokeTiming

Mở rộng giao thức SSH và lộ trình phân phối

  • Việc triển khai sử dụng hai thông điệp tầng truyền tải mới được thêm vào giao thức SSH
    • SSH2_MSG_PING
    • SSH2_MSG_PONG
  • Các thông điệp này dùng không gian số local extensions, và được quảng bá bằng thông điệp "ping@openssh.com" ext-info cùng chuỗi phiên bản "0"
  • Thay đổi này được giới thiệu như một ví dụ của “security by trickery”, đồng thời được xem là một lý do để mong đợi bản phát hành OpenBSD tiếp theo
  • Các hệ thống khác có thể sớm thấy tính năng này thông qua openssh-portable

Bài viết liên quan

1 bình luận

 
GN⁺ 2023-08-30
Ý kiến trên Hacker News

  • Thời điểm nhấn phím đã là một vấn đề đáng lo ngại trong I/O terminal từ thập niên 1980, và ngay cả khi đó, các môi trường mã hóa sơ khai như stelnet hay Kerberos cũng đã để ý đến nó
    Hầu hết ứng dụng terminal dùng I/O có đệm khi nhập mật khẩu, và đây vẫn là một tính năng bảo mật quan trọng
    Ở chế độ này, không có gì được gửi sang phía bên kia cho đến khi người dùng nhấn Enter, nên nếu có padding thì kẻ tấn công trung gian khó mà suy ra được ngay cả độ dài mật khẩu
    Trong một thời gian, các ứng dụng nhận mật khẩu ở chế độ không đệm để hiển thị * mỗi khi người dùng gõ từng là mục tiêu ngon ăn
    Trông thì hay và có phản hồi, nhưng lại làm lộ tốc độ gõ phím, thứ cần được che giấu nhất khi nhập mật khẩu
    Tôi mong I/O có đệm vẫn tiếp tục được duy trì cho việc nhập mật khẩu, và cho rằng cách này tốt đến mức SSH khó theo kịp dù có làm rối
    Dù vậy, việc SSH thêm tính năng này là điều tốt, và nó giúp bảo vệ những nội dung không thể đệm như nhập liệu trong shell hay trình soạn thảo

    • Cách hiện nay là hiển thị một số dấu sao cố định không phụ thuộc vào độ dài mật khẩu, khá dễ gây nhầm lẫn cho người dùng
      Họ có thể nghĩ “độ dài sai nên chắc là không đúng”, làm mất lợi ích của mật khẩu đã lưu và cố tự nhập lại mật khẩu “đúng”
      Trước đây hình như cũng có cách hiển thị hash trực quan như hash 2 chữ số và biểu tượng mặt cười, nhưng điều đó có thể lại giúp ích cho kiểu tấn công nhìn trộm qua vai
    • Vào thập niên 1990, với một addon AI dựa trên Visual Basic, chỉ cần gõ vài phút là có thể dựa vào mẫu gõ phím để biết ai đang gõ bàn phím, và như vậy quy trình đăng nhập về cơ bản trở nên vô nghĩa
      Ngày nay có thể áp dụng điều này cả với đăng nhập bằng màn hình cảm ứng, bằng cách liên kết áp lực ngón tay, diện tích tiếp xúc và hình dạng với người dùng
      Nếu tính cả thao tác vuốt hay chuyển động chuột trong ngữ cảnh hệ điều hành desktop, cũng có thể có ứng dụng bảo mật khóa hệ thống khi người đang dùng không phải chủ thiết bị hoặc tài khoản
      Ít nhất thì cũng có thể ghi lại thời điểm người yêu lục điện thoại của tôi
    • Xác thực SSH bằng mật khẩu gần như tuyệt đối không nên dùng
    • Tôi tự hỏi có SSH client nào đệm đầu vào theo từng dòng không
      Tức là nội dung đã nhập sẽ không được gửi đi cho đến khi nhấn Enter hoặc nút gửi
      Trước đây khi còn chơi MUD nhiều, tôi từng dùng các Telnet client như vậy, nhưng sau đó chưa thấy SSH client nào làm thế
      Đây có vẻ là một biện pháp phòng vệ ổn để ngăn rò rỉ timing phím trong SSH, và trong một số kịch bản sử dụng còn có thể tốt hơn cách trì hoãn 20ms được nói trong bài
      Tuy nhiên nghĩ lại thì sẽ lý tưởng hơn nếu cả lúc nhấn Tab để tự hoàn thành trong shell Linux cũng được gửi
    • Nếu “hầu hết ứng dụng terminal dùng I/O có đệm khi nhập mật khẩu”, tôi tự hỏi việc bản vá này tồn tại có nghĩa là OpenSSH không hoạt động như vậy hay không

  • Làm tôi nhớ đến Bridge chuyên nghiệp
    Họ chia đội bằng một bức tường và đồng thời đưa bài qua một ô cửa, để ngăn giao tiếp thông qua timing
    https://youtube.com/watch?v=RVZLNRmO3vo

    • Dù vậy vẫn gian lận qua tấm màn
      https://en.wikipedia.org/wiki/Blue_Team_(bridge)#Cheating_an...
      https://en.wikipedia.org/wiki/Fantoni_and_Nunes_cheating_sca...
      https://en.wikipedia.org/wiki/Fisher_and_Schwartz_cheating_s...
      Và đó chỉ là những vụ chúng ta biết
      Trước đây tôi từng thực sự áp dụng Bridge trong một buổi phỏng vấn
      Trong Bridge có quy tắc Active Ethics: nếu đối tác đưa gợi ý bằng cách khác ngoài việc đấu giá, khi về mặt logic có thể thì bạn bắt buộc phải chọn hướng ngược lại
      Trong một buổi phỏng vấn debug, người phỏng vấn cố kéo tôi đến đáp án quá lộ liễu, nên trước khi làm theo điều anh ta nói, tôi dừng lại và kiểm tra mọi thứ mình nghĩ ra
      Sau buổi phỏng vấn tôi nói lý do vì sao mình làm vậy, và bảo rằng nếu cần giải thích thêm thì hãy tìm Active Ethics
      Và tôi đã đỗ
    • Nếu con người chỉ phải thực hiện một automaton định sẵn như những máy trạng thái người, và bị phạt khi đi lệch, thì thà tung đồng xu để chọn người thắng rồi bỏ qua trò chơi còn hơn
      Điều này giống như nói rằng catcher không được ra tín hiệu cho pitcher
      Truyền đạt thông tin là một kỹ năng mang tính con người, bổ sung thêm chiều sâu cho trò chơi, và cứ để bên làm tốt nhất giành chiến thắng
    • Nhìn từ góc độ red team, ở đây có quá nhiều độ bất quy tắc của con người có thể bị khai thác
      Có vẻ không quá khó để truyền khoảng 1~2 bit thông tin
    • Bridge đúng là một trò chơi rất lạ
      Giao tiếp bí mật với đối tác là cốt lõi, nhưng việc giao tiếp đó lại không được phép bí mật
      Kiểu như được giao tiếp nhưng không được giao tiếp, nên rất kỳ quặc
    • Có vẻ vẫn còn khả năng truyền thông tin
      Ví dụ có thể đẩy chiếc bàn nhỏ qua rào chắn một cái thật nhanh hoặc đẩy chậm để biểu thị điều gì đó
      Người ở góc trên bên phải video đã chuyển bài như vậy ở lần thứ nhất và thứ hai

  • Có một bài viết năm 2008 giới thiệu bài báo năm 2001 về các tấn công timing như thế này: https://lwn.net/Articles/298833/
    Bài báo được trích dẫn là “Timing analysis of keystrokes and timing attacks on SSH”, phân tích rằng thông tin timing của phím bấm làm rò rỉ thông tin về chuỗi phím đã nhập
    Trong phân tích chi tiết hơn, mỗi cặp phím bấm làm lộ khoảng 1 bit thông tin về nội dung, và vì entropy của mật khẩu vào khoảng 4~8 bit mỗi ký tự, lượng thông tin này có thể khá đáng kể
    Tôi đã nghĩ vấn đề này đã được sửa từ lâu, và tưởng rằng bản sửa đã được đưa vào khoảng năm 2012, nên khá ngạc nhiên khi biết nó vẫn chưa được giải quyết

  • Một ngày nào đó có thể sẽ phải dùng các gói tin được điền sẵn bằng dữ liệu ngẫu nhiên để che giấu thao tác gõ phím.
    Không hẳn là steganography, nhưng cũng khá gần, và có vẻ cũng có thể dùng để khiến việc phân tích lưu lượng trở nên khó hơn hoặc bất khả thi.

    • NSA và các cơ quan tương tự đã dùng những cách như vậy từ hàng chục năm trước.
      Nếu là đường truyền chuyên dụng, không quá khó để luôn đẩy dữ liệu mã hóa hoàn toàn qua đường truyền ở mức sử dụng tối đa, rồi chỉ chèn dữ liệu thật vào khi cần.
    • Cách này cũng có thể dùng cho steganography.
      Có nghiên cứu cho mô hình ngôn ngữ viết lại một văn bản vỏ bọc vô hại, nhưng thay đổi phân phối xác suất dùng để lấy mẫu từ theo một độ méo entropy tối thiểu được suy ra từ khóa.
      Phía nhận dùng cùng mô hình và khóa thì có thể giải mã văn bản vỏ bọc trở lại thành bản mã; cách này cũng áp dụng được cho hình ảnh.
      https://openreview.net/forum?id=HQ67mj5rJdR
    • Làm tôi nhớ đến number station.
      Chúng liên tục phát các con số ra khắp thế giới, và chỉ khi những con số đó có ý nghĩa với ai đó thì chúng mới trở nên có nghĩa.
      Họ làm vậy dù biết rõ các cơ quan tình báo trên thế giới vẫn đang nghe.
    • Một số giao thức nhắn tin hoạt động theo cách này.
    • Lưu lượng SSH đã được mã hóa, nên với người quan sát, các gói tin vốn đã trông như dữ liệu ngẫu nhiên.

  • Làm tôi nghĩ đến các trình giả lập terminal hiện đại như Warp trên macOS.
    Ví dụ tôi tự hỏi liệu chúng có nhận toàn bộ đầu vào cục bộ rồi gửi thành một khối sang host từ xa không.
    Làm vậy có thể khiến một số đầu vào ở chế độ raw thực thi trên host từ xa bị hỏng, nhưng có lẽ cũng có thể phát hiện các tình huống đó rồi chuyển sang luồng phím thô.
    [1]: https://warp.dev

    • Thông thường khi kết nối bằng SSH, bản thân kết nối luôn ở chế độ raw, còn host từ xa xử lý pty theo cách thông thường.
      pty từ xa có thể ở chế độ theo dòng, hoặc cũng có thể ở chế độ raw.
      Các terminal có tích hợp shell đặc biệt thường cũng cần cài phần tích hợp đó trên host từ xa, và một số xử lý việc này khá trong suốt.
      Vì vậy mosh có thể hoạt động tốt hơn SSH thuần trên các kết nối có độ trễ lớn.
      Tuy nhiên tính năng này có lẽ sẽ không áp dụng cho mosh.
    • Khó tưởng tượng một ứng dụng quảng bá là “AI cho terminal” lại an toàn và riêng tư hơn các công cụ Unix tiêu chuẩn.
      Một số tính năng bảo mật cụ thể, chẳng hạn phòng chống tấn công timing, có thể được công cụ mới xử lý tốt hơn và không có trong các công cụ tiêu chuẩn cũ.
      Nhưng khả năng cao hơn nhiều là công cụ mới sẽ thiếu các tính năng bảo mật khác, và thêm “AI” thì bề mặt tấn công cũng tăng lên rất nhiều.
      Nói thật, các tuyên bố về quyền riêng tư của Warp cũng khó tin.
      Các công cụ xử lý ngôn ngữ tự nhiên ngày nay gần như đều nghiêng về giải pháp cloud, và như vậy khả năng bảo vệ quyền riêng tư gần như lập tức tiến về 0.
    • Nếu nó được thiết kế để nhận dữ liệu ở một tốc độ baud nhất định, thì liệu đầu vào gửi thành một khối cũng sẽ được đưa vào theo đúng tốc độ đó không?

  • Tôi tò mò mối đe dọa mà tính năng này giảm thiểu là gì.

    • Kẻ nghe lén không thể thấy nội dung phím gõ, nhưng trước đây có thể thấy thời điểm từng phím được gửi đi.
      Nếu biết mẫu gõ phím của mục tiêu, có thể dùng dữ liệu đó để khôi phục nội dung.
      Có thể thu thập mẫu bằng cách khiến mục tiêu nhập vào một website do tôi kiểm soát trên trình duyệt bật JavaScript, hoặc ghi âm tiếng gõ phím.
      Gần đây, một số streamer trực tuyến còn bị tấn công đánh cắp mật khẩu bằng mô hình AI học tiếng gõ bàn phím.
    • Nếu tôi nhớ đúng thì khoảng năm 2005 có một bài báo, cho thấy có thể suy ra nội dung nhập bằng cách tương quan thời điểm gói tin trong phiên SSH được mã hóa với thống kê gõ phím của con người đã thu thập.
      Tính năng này có vẻ thêm nhiễu để ngăn điều đó.
    • Mối lo ban đầu về lỗ hổng là việc dùng thuật toán Viterbi.
      http://www.cs.berkeley.edu/~dawnsong/papers/ssh-timing.pdf [2001]
      Khi thêm machine learning, độ chính xác giải mã từ âm thanh đã cải thiện đáng kể, nên ở những nơi không an toàn về mặt vật lý thì nên dùng bàn phím yên tĩnh.
      https://arstechnica.com/gadgets/2023/08/type-softly-research...
    • Về cơ bản có thể phân tích tốc độ gõ để đưa ra một số suy đoán.
      Ví dụ, người dùng thường gõ mật khẩu nhanh hơn các đầu vào khác, nên trong các thao tác như sudo, có thể nhìn vào số lượng phím được gửi dồn một lần để đoán độ dài mật khẩu.
    • Gần đây đã có nghiên cứu dùng thời điểm gõ phím và deep learning để định danh người dùng như dấu vân tay, và bài này dùng nó cho xác thực: https://www.usenix.org/system/files/usenixsecurity23-piet.pd...
      Trường hợp sử dụng trong chính bài báo này không phải là mối đe dọa bảo mật, nhưng có thể diễn giải là rò rỉ thông tin.

  • Tôi tò mò nó thêm bao nhiêu độ trễ.
    Đặc biệt, độ trễ khó dự đoán là một trong những yếu tố gây căng thẳng lớn nhất trong công việc phát triển phần mềm.

    • Trong bài có nói ngay rồi.
      Khi chỉ truyền một lượng nhỏ dữ liệu, lưu lượng tương tác được gửi theo khoảng thời gian cố định, mặc định là 20ms.
    • Có vẻ phần nói về độ trễ ở trên là nói độ trễ trong trải nghiệm người dùng, tức khoảng thời gian từ khi nhấn phím đến khi thấy kết quả.
      [1]
      Các công cụ như Mosh giúp giảm độ trễ cảm nhận khá nhiều.
      Mosh hiển thị ngay khi phím của người dùng được ghi nhận cục bộ, và hiển thị màu mờ để cho biết vòng khứ hồi chưa kết thúc.
      Lần cuối tôi xem thì là như vậy, hoặc có lẽ là gạch chân.
      Khi vòng khứ hồi kết thúc, ký tự được hiển thị bình thường.
      [1] Nếu yếu tố gây căng thẳng lớn nhất trong phát triển phần mềm là độ trễ gõ phím thì nghe như bạn khá may mắn.
      [2]: https://mosh.org
    • Độ trễ này chẳng phải là dự đoán được theo thiết kế sao?

  • Liên kết commit thực tế: https://github.com/openssh/openssh-portable/commit/7603ba712...

  • Có vẻ một số bên đo timing của packet để phát hiện shell hands-on-keyboard trên mạng; tôi tò mò thay đổi này sẽ cản trở kiểu phát hiện đó đến mức nào

    • Tôi mong những cách làm như vậy sẽ đi vào cùng vết xe đổ với các nỗ lực kiểu doanh nghiệp khác nhằm phá mã hóa hoặc cài backdoor nhân danh “bảo mật”
      Tôi thật sự nghĩ đó là một cách tiếp cận bảo mật sai lầm
      Biết được một script tự động có đăng nhập vào thiết bị hay không thì cũng hữu ích, nhưng một thiết kế tốt hơn có thể khiến thông tin đó không còn quan trọng
    • Có trường hợp sử dụng không ác ý nào cho việc này không?