Có thể đánh cắp token OAuth của tài khoản Microsoft thông qua lỗ hổng open redirect trong ứng dụng Harvest

 (eval.blog)
1 điểm bởi GN⁺ 2023-10-23 | 1 bình luận | Chia sẻ qua WhatsApp
  • Trong luồng kết nối Outlook Calendar OAuth của Harvest, URL callback lại chuyển hướng tiếp tới đích trong giá trị state, gây ra open redirect; khi kết hợp với luồng cấp quyền ngầm định, token có thể bị lộ sang URL bên ngoài
  • Vấn đề không nằm ở Microsoft mà ở phía tích hợp của Harvest; OAuth redirect_uri đã đăng ký trở thành một điểm trung chuyển chuyển hướng đưa người dùng tới tên miền do kẻ tấn công chỉ định
  • state là JSON được mã hóa URI, và nếu chèn một tên miền bên ngoài có dấu gạch chéo như example.com/ vào subdomain, luồng sẽ chuyển tới dạng example.com/.harvestapp.com/...
  • PoC cho thấy trong URL authorize OAuth của Microsoft, khi dùng client_id=0dcef4db-36d8-4aed-9cc5-ab43e1814884, response_type=id_token, response_mode=fragment, scope=openid, mảnh #id_token=... sẽ được gắn vào đích chuyển hướng
  • Lỗ hổng được báo cáo ngày 23/8/2020, bản vá được xác nhận ngày 1/8/2023, và đến 22/10/2023 Harvest đã xin lỗi vì sự chậm trễ do human error

Luồng rò rỉ token trong callback OAuth

  • Harvest là phần mềm theo dõi thời gian cho phép người dùng kết nối Outlook Calendar qua OAuth
  • Khi cấp quyền thành công, người dùng sẽ được chuyển hướng tới https://outlook-integration.harvestapp.com/auth/outlook-calendar/…
  • Callback này lại tiếp tục chuyển người dùng tới URL được cung cấp trong state, và trong quá trình đó phát sinh open redirect
  • Giá trị state trong URL callback được xác nhận ban đầu là JSON mã hóa URI
    • Khi giải mã sẽ có dạng {"return_to":"/","subdomain":"hackerone295"}
    • Giá trị subdomain được dùng để suy ra không gian ứng dụng Harvest như hackerone295.harvestapp.com
  • Nếu thêm dấu gạch chéo vào subdomain như example.com/, URL callback sẽ chuyển sang một tên miền bên ngoài
  • URL callback này là redirect_uri đã đăng ký cho ứng dụng OAuth, nên khi kết hợp open redirect với luồng cấp quyền ngầm định, token có thể bị lộ tới đích chuyển hướng
  • URL authorize PoC dùng các giá trị sau
  • Cuối cùng người dùng sẽ bị chuyển hướng tới dạng sau
  • Đây không phải là lỗ hổng ở phía Microsoft

Thời gian từ lúc báo cáo đến khi vá

  • Trong quá trình công bố lỗ hổng và vá lỗi, nhóm Harvest phản hồi rất ít và dù đã xác nhận lỗ hổng ở bước triage, việc sửa lỗi vẫn mất rất nhiều thời gian
  • Lỗ hổng được báo cáo ngày 23/8/2020, và đến 16/10/2020 Harvest mới liên hệ lần đầu
  • Ngày 27/11/2020, báo cáo được chuyển sang trạng thái triaged
  • Ngày 28/4/2022, công ty cho biết đang sửa và ước tính mất 2 tuần, nhưng trên thực tế phải mất thêm khoảng 1 năm nữa mới hoàn tất
  • Ngày 1/8/2023 xác nhận lỗ hổng đã được vá
  • Ngày 21/10/2023, báo cáo được công khai qua một bài viết công bố
  • Tính đến cùng ngày đó, báo cáo vẫn ở trạng thái triage; dù chính sách bug bounty có đề cập phần thưởng, không có bounty hay điểm HackerOne nào được trao
  • Sau khi bài viết thu hút chú ý vào ngày 22/10/2023, Harvest đã giải thích và xin lỗi rằng sự chậm trễ là do human error

Bài viết liên quan

1 bình luận

 
GN⁺ 2023-10-23
Ý kiến trên Hacker News

  • Với tư cách là người phụ trách chương trình bug bounty, tôi sẽ giải thích chuyện gì đã xảy ra nội bộ. Tôi đã xin lỗi @0xcrypto và giải thích nội bộ rồi, nhưng tôi nghĩ cũng nên tóm tắt lại ở đây
    Ngay từ đầu chúng tôi đã không thể tái hiện hoàn toàn vấn đề này, và cũng không thể đóng lại vì sợ đã bỏ sót điều gì đó. Ngay sau lần cuối cùng trả lời rằng “sẽ tìm giải pháp”, chúng tôi đã gần đi đến kết luận là không thể tái hiện; rồi khi có một báo cáo liên quan đến OAuth tương tự được gửi đến, nội bộ đã bị nhầm lẫn và tôi tưởng rằng vấn đề này đã được xử lý và chuyển tiếp rồi
    Do thiết lập thông báo, tôi đã bỏ lỡ các tin nhắn tiếp theo, và issue bị để ở trạng thái Triage vô thời hạn mà không có cập nhật. Đây không phải là lời bào chữa; tôi từng làm bug bounty hunter trong thời gian dài nên hiểu rất rõ việc phải chờ cập nhật từ công ty khó chịu đến mức nào. Bảo mật khách hàng là ưu tiên hàng đầu, và những gì ghi trên trang bảo mật là sự thật

    • Sai sót thì có thể xảy ra, nhưng việc trong suốt 3 năm đã liên hệ với HackerOne nhiều lần mà HackerOne vẫn không liên lạc được với Harvest thì vẫn chưa được giải thích
      Hơn nữa, hiện cũng chưa rõ sẽ xử lý thế nào với một báo cáo không còn tái hiện được nữa. Tôi muốn thảo luận thêm trên HackerOne, nhưng sau tin nhắn xin lỗi thì có vẻ lại không phản hồi
    • Tôi tò mò liệu cuối cùng bạn có tin rằng lỗ hổng đó thực sự hoạt động đúng như cách được mô tả hay không; nếu có, tại sao lại thất bại khi tái hiện
    • Rất vui vì được nghe giải thích trực tiếp. Dù không tái hiện được, chẳng phải chỉ cần xem mã nguồn là có thể dễ dàng xác nhận liệu có thể open redirect hay không sao
    • Ít nhất việc đăng một bài cho thấy họ đang xem xét nghiêm túc cũng là điều đáng mừng. Ai cũng có thể mắc sai lầm, nhưng nếu không chịu trách nhiệm khi sai lầm xảy ra thì sự việc sẽ lớn chuyện hơn
    • Tôi vẫn dùng Harvest khá tốt, nhưng mong họ cũng sửa ứng dụng di động mới trên iOS. Có quá nhiều vấn đề nhỏ đến mức tôi đã thôi báo cho bộ phận hỗ trợ
      Trạng thái ứng dụng thường xuyên lệch với trạng thái máy chủ; thay đổi trên máy chủ chỉ hiện ra sau khi buộc làm mới, hoặc thay đổi trên client sau khi lưu lại bị hoàn tác. Trải nghiệm theo dõi thời gian cũng bất tiện: nút phải cuộn mới thấy, hoặc vị trí các nút bắt đầu/dừng/khởi động lại/xóa cứ thay đổi theo trạng thái của mục. Ứng dụng cũ tuy không đẹp nhưng chạy không vấn đề gì

  • Khá đáng lo. Khi tôi dùng Harvest, bộ phận hỗ trợ thật sự tuyệt vời, phản hồi nhanh, hiểu rất chi tiết cách khách hàng dùng sản phẩm, và còn giải thích cặn kẽ cách tận dụng sáng tạo các tính năng hiện có
    Với tính năng chưa được triển khai, câu trả lời là “sẽ đưa vào backlog nhưng không đảm bảo”. Họ ghi có 30 người ở mảng kỹ thuật [1], nhưng tôi không rõ lực lượng đó được dùng vào đâu, vì tôi cũng không thấy các tính năng khác ra mắt nhanh
    Tôi bắt đầu nhận spam với tư cách “người dùng Harvest” nên nghi ngờ họ đã bán danh sách khách hàng; các lãnh đạo công ty lập tức kết nối, phủ nhận mạnh mẽ và xử lý nghiêm túc đến mức điều tra ngay. Điều đó thì tốt
    Nhưng rốt cuộc đây cũng có vẻ là vấn đề kỹ thuật. Tôi phát hiện một cách khá dễ để ước tính số khách hàng đang hoạt động, và việc này cũng được đưa vào “backlog” rồi nhiều tháng vẫn chưa sửa. Bản sửa trông có vẻ rất nhỏ. Ngoài ra, MFA chỉ được cung cấp khi đăng nhập bằng Google [2]. Dù vậy, bản thân ứng dụng làm rất tốt việc nó cần làm
    1: https://www.getharvest.com/about/meet-the-team
    2: https://support.getharvest.com/hc/en-us/articles/36005266713...

    • Cảm ơn đánh giá tốt. Tôi hoàn toàn đồng ý rằng đội hỗ trợ rất tuyệt. Dù là một đội nhỏ, họ xử lý mọi vấn đề rất nghiêm túc, và cũng trực tiếp tham gia cuộc điều tra đã nói ở trên
      Việc giao tiếp bị lệch với người báo cáo trong thread này hoàn toàn là lỗi của tôi, và như đã giải thích trong phản hồi phía trên, tôi sẽ đảm bảo chuyện này không tái diễn
    • Không rõ là bạn thích hay ghét nữa. Đang mỉa mai à?
    • Chất lượng hỗ trợ chắc chắn là tốt. Các yêu cầu luôn được những người rất thành thạo xử lý, và thường tôi nhận được phản hồi chỉ trong vài phút
      Một số yêu cầu tính năng thậm chí đã được đưa vào sản phẩm thật. Có thể không phải do ảnh hưởng của tôi, nhưng ít nhất có vẻ chúng tôi có cùng suy nghĩ về một công cụ theo dõi thời gian tốt

  • Tiêu đề có vẻ khá bất công với Microsoft. Nó tạo cảm giác đang tận dụng việc Microsoft bị chú ý vì các sự cố xác thực gần đây; vừa thấy tiêu đề tôi đã nghĩ “lại là một vụ xâm nhập MS nữa à”
    Thực tế đó là token của Harvest, và do lỗ hổng injection trong mã của Harvest nên chỉ quyền truy cập ứng dụng Harvest bị lộ sai cách. Nếu nó nằm sau bất kỳ nhà cung cấp định danh nào khác thì cũng sẽ dễ bị tấn công y như vậy

    • Tôi là tác giả bài blog. Tôi hiểu lo ngại đó và đã muốn bỏ tên Microsoft khỏi tiêu đề, nhưng không nghĩ ra cách diễn đạt phù hợp
      Lý do là lỗ hổng này chỉ ảnh hưởng đến triển khai OAuth dùng để liên kết tài khoản Microsoft. Tiêu đề ban đầu là “Microsoft OAuth token leak via open redirect in Harvest App”, sau đó tôi đổi thành “Microsoft Account's OAuth tokens leaking via open redirect in Harvest App”. Tôi vẫn sẵn sàng đổi tiếp và hoan nghênh đề xuất
    • Tôi cũng nghĩ vậy. Thậm chí tôi còn tự hỏi liệu bài viết có thật sự hiểu cách OAuth hoạt động mà vẫn gọi đây là token của MS hay không

  • RFC 6749 trình bày chi tiết cách máy chủ ủy quyền ngăn chặn kiểu tấn công này
    Máy chủ ủy quyền bắt buộc phải yêu cầu đăng ký URI chuyển hướng đối với public client, và cũng nên yêu cầu với confidential client. Nếu yêu cầu có cung cấp URI chuyển hướng, máy chủ ủy quyền phải kiểm tra bằng cách đối chiếu với giá trị đã đăng ký
    Vậy thì hẳn ứng dụng Harvest không đăng ký redirect_uri độc hại, nên tôi thắc mắc chuyện này có thể xảy ra như thế nào. Có phải máy chủ OAuth của Microsoft bỏ qua các tham số URL bên trong redirect_uri khi so sánh với URI chuyển hướng đã đăng ký của OAuth client không?

    • Có vẻ họ chồng thêm lần chuyển hướng thứ hai lên trên và đặt nó vào tham số state. Có lẽ mục đích là để chuyển hướng đến bất cứ đâu
      Luồng dự định có lẽ là đi tới URL xác thực của Harvest → chuyển hướng sang URL xác thực của Microsoft kèm redirect_uri=registered_uri và state=some_encoded_final_uri → người dùng nhập thông tin đăng nhập → chuyển hướng về URI đã đăng ký → đọc state rồi lại chuyển hướng tới URI bên trong đó
      Cuộc tấn công này vẫn chuyển hướng về URI được cho phép, nhưng endpoint đó đọc state và chuyển tiếp nguyên phản hồi/token. Có ba sai lầm: lạm dụng state, nếu đã lạm dụng thì lại không mã hóa và xác minh state, và bật implicit grant. Nếu cần, lẽ ra họ phải tạo một đăng ký riêng cho mục đích hạn chế
    • redirect_uri của Harvest đã được đăng ký với Microsoft. Sau khi máy chủ OAuth của Microsoft chuyển hướng về Harvest, Harvest triển khai cơ chế chuyển hướng riêng dựa trên dữ liệu trong state

  • Implicit grant khá tệ vì những lý do như bài viết này cho thấy
    Nhân tiện, nó dự kiến sẽ bị loại bỏ trong đặc tả OAuth 2.1 sắp tới: https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-09.htm...

    • Chẳng phải nó đã được lên kế hoạch loại bỏ từ khoảng 6 năm trước rồi sao? CORS đã thay thế mục đích sử dụng đó, nên không có lý do gì để giữ nó trong đặc tả mới

  • Ý là mất 3 năm để sửa lỗ hổng à? Từ tháng 8/2020 đến tháng 8/2023, tôi không biết quy mô đội Harvest thế nào nhưng dù sao cũng có vẻ quá vô lý

    • Có lẽ như thường thấy ở nhiều công ty, nó bị đưa vào backlog với mức ưu tiên thấp, trải qua vài lần dọn dẹp Jira và tái cơ cấu tổ chức, rồi cuối cùng sau này được phát hiện lại và sửa
    • Tôi thuộc đội bảo mật Harvest. Như đã trả lời ở bình luận khác, về cơ bản chúng tôi không tái hiện được và cũng không có bản sửa rõ ràng nào. Tuy nhiên, do lỗi con người của tôi, một issue đáng lẽ phải được đóng lại vẫn nằm ở trạng thái Triage

  • Mong có chuyên gia OAuth giải thích vấn đề này chi tiết hơn một chút. Tôi đã đọc blog vài lần nhưng vẫn chưa hiểu lỗ hổng thực sự
    Với kiến thức OAuth rất hạn chế của tôi, chẳng phải ứng dụng Harvest yêu cầu Microsoft xác minh người dùng, Microsoft xác minh xong người dùng, rồi nếu thành công thì chuyển hướng về callback URL và truyền access token trong phần thân phản hồi sao?
    Trong trường hợp này, chẳng phải tác giả blog chỉ tạo một URL tự chế khiến URL trả về đi tới example.com thay vì URL trả về thực tế thôi sao?

    • Đúng vậy. Tác giả blog đã tạo một URL tự chế như thế. Tuy nhiên, callback URL trong URL tấn công là domain harvestapp, còn phần kẻ tấn công kiểm soát nằm trong state, thứ gần như mờ đối với máy chủ OAuth
      Dùng URL đó, có thể gửi cho ai đó một liên kết login.microsoftonline.com, hiển thị lời nhắc đăng nhập “đăng nhập vào Harvest”, rồi kẻ tấn công có thể nhận được quyền liên quan đến tài khoản Harvest thật
      Thông thường thì điều này là không thể. Kẻ tấn công có thể đăng ký một ứng dụng mới chuyển hướng tới example.com, nhưng khi đó sẽ không lấy được access token chứa quyền liên quan đến Harvest nên vô dụng
      Ứng dụng OAuth phía Microsoft có danh sách cho phép chuyển hướng hợp lệ, nên các thử như login.microsoftonline.com/authorize?client_id=$harvestAppID&redirect_uri=attacker.com sẽ bị Microsoft báo lỗi. Cuộc tấn công khả thi vì URL outlook-integration.harvestapp.com hợp lệ nhận access token, rồi lại chuyển hướng sang trang của kẻ tấn công và chuyển cả access token theo
    • Lỗ hổng xuất phát từ outlook-integration.harvestapp.com. Sau khi callback OAuth2 thành công, họ dùng một đối tượng JSON chứa chỉ dẫn cần thực hiện làm state
      Thuộc tính subdomain được dùng để chuyển hướng trình duyệt tới một subdomain của harvestapp.com kèm #id-token. Vấn đề là giá trị subdomain được chèn nguyên xi vào URL bên dưới
      https://${subdomain}.harvestapp.com/...#id-token=...
      Nếu đặt subdomain trong payload JSON thành một giá trị có dấu gạch chéo ở cuối như attacker-controlled.com/, URL sẽ trở thành https://attacker-controlled.com/.harvestapp.com/...#id-token=.., và khi trình duyệt chuyển sang domain khác, token sẽ bị rò rỉ
    • Microsoft kiểm tra rằng URL trả về có nằm trong danh sách cho phép do Harvest chỉ định hay không. Có lẽ Harvest đã thêm cơ chế chuyển hướng riêng phía trên để hỗ trợ nhiều instance của phần mềm, nhưng không làm sạch đúng cách giá trị đầu vào chuyển hướng
      Vì vậy đây không phải là vấn đề ngầm định của bản thân OAuth, mà là triển khai kém
    • Tôi không biết chính xác, nhưng tôi nghĩ vấn đề là Harvest đã cho phép mọi URL làm callback URL. Họ phải báo cho Microsoft chỉ cho phép các URL cụ thể làm callback
      Khi thiết lập workflow, thay vì tạo danh sách thực tế các callback URL đáng tin cậy, có khả năng họ đã dùng wildcard trong danh sách cho phép callback URL. Tôi cũng có thể hoàn toàn sai

  • Không hiểu vì sao lại chờ tới 3 năm. Thời gian gia hạn trước khi công khai chỉ cần 90 ngày là đủ

    • Nếu cần thay đổi cực kỳ lớn, và một đội khá lớn phải dành phần lớn thời gian làm việc cho vấn đề này, thì có thể lâu hơn 90 ngày. Hoặc có thể đã có giải pháp nhưng do phải thông báo cho khách hàng nên cần triển khai theo một lịch trình cụ thể và tương đối ngắn
      Tuy nhiên, việc gia hạn thêm như vậy phải được nhà nghiên cứu hoặc luật sư/đại diện của họ cho phép. Đây là kiểu yêu cầu mà công ty có thể thiện chí đưa ra đối với những vụ việc lớn hơn bình thường

  • Nếu HackerOne để các công ty ngâm những việc như thế này tới 3 năm, thì có vẻ họ không làm đúng vai trò của mình

    • HackerOne phụ thuộc vào các công ty vận hành chương trình bug bounty. Mức độ họ tham gia phụ thuộc rất nhiều vào dịch vụ được cung cấp, chẳng hạn có xử lý phân loại hay không
      Ở mức cơ bản nhất, họ chỉ cung cấp một nền tảng công khai lỗ hổng và các điều khoản pháp lý tiêu chuẩn để nhà nghiên cứu không bị đội pháp lý kiện
      Trong hầu hết trường hợp, các công ty từ chối yêu cầu công khai. Nếu nhà nghiên cứu công khai mà không được phép, họ vi phạm thỏa thuận với HackerOne và công ty, đồng thời đối mặt với trách nhiệm pháp lý. Trong trường hợp này, có vẻ công ty đã đồng ý công khai, và dù phản hồi rất chậm, tôi nghĩ điểm đó cũng đáng ghi nhận
      Cá nhân tôi cũng từng nhiều lần gặp các lỗi có mức thưởng bốn chữ số nhưng không được sửa trong hơn một năm, nhưng tôi không nghĩ đó là lỗi của HackerOne
    • Tôi từng xử lý vấn đề HackerOne ở phía công ty, và một người tham gia HackerOne liên tục vi phạm chính các quy tắc của HackerOne. Có cả vi phạm lịch công khai, đăng bài sai sự thật trên mạng xã hội về lỗi, thậm chí đe dọa nhân viên
      HackerOne không quan tâm. Dù đã nhiều lần thông báo rằng người đó vi phạm quy tắc của họ, họ nói không thể làm gì
      Cảm giác như một công ty từng được đưa vào trạng thái vận hành bình thường rồi bị cắt giảm chỉ còn nhân sự tối thiểu, với các nhân viên hỗ trợ không có thẩm quyền trả lời câu hỏi. Chuyện đã khá lâu nên giờ có thể đã khác, nhưng ấn tượng lúc đó là vậy
    • Trong ba bên, tức HackerOne, công ty và nhà nghiên cứu tìm ra lỗi, thì công ty nắm toàn bộ đòn bẩy
      Nếu các công ty cảm thấy HackerOne vượt quá giới hạn và quyết định “cho phép” họ phải làm gì, họ sẽ đơn giản rời HackerOne và xây dựng giải pháp nội bộ
    • Có lẽ cần có đánh giá công ty, để có thể tránh những công ty tệ kéo dài nhiều năm mà cũng không trả thưởng

  • Không hiểu vì sao vấn đề này không được chuyển cho Microsoft. Microsoft lẽ ra có thể thu hồi quyền truy cập của ứng dụng OAuth này cho đến khi vấn đề được khắc phục
    Tuy nhiên, có lẽ trên Microsoft có hàng nghìn triển khai tệ tương tự được kết nối bằng OAuth

    • Tôi không biết là có thể làm như vậy. Cá nhân tôi chắc chắn sẽ không bao giờ nghĩ tới chuyện đó