Camera và cuộc sống quanh ta

Camera an ninh hiện nay là một thiết bị rất phổ biến được sử dụng ở rất nhiều nơi. Nó nắm khá nhiều thông tin nhạy cảm của người dùng. Tuy vậy chưa nhiều người quan tâm tới vấn đề bảo mật của các thiết bị này lắm. Vì vậy, nhiều kẻ xấu đã lợi dụng vấn đề này để tấn công chuộc lợi cá nhân.

Ở bài viết này chúng tôi sẽ chia sẻ về quá trình tìm hiểu, nghiên cứu về một chiếc camera không tên, là khởi đầu cho việc nghiên cứu những thiết bị khác khó hơn và nhiều người dùng hơn sau này. Thực ra chúng tôi chọn camera này vì là được một người anh cho để nghiên cứu thử chứ cũng không có ý định target nó từ đầu. Việc này đã được chúng tôi làm từ trước đây rất lâu nhưng bây giờ mới có cơ hội chia sẻ lại với các bạn. Tuy nhiên sau một thời gian ngắn nghiên cứu thì chúng tôi đã làm chết con camera này dẫn đến không thể nghiên cứu sâu hơn cũng như không thể thực hiện lại một số thao tác để có một bài viết đầy đủ và chi tiết hơn. Chính vì vậy nếu bài viết này còn nhiều thiếu xót hoặc chưa đủ hấp dẫn và chi tiết thì tôi xin phép hẹn các bạn vào một bài viết khác, về một thiết bị camera khác.

Một camera không tên tuổi

Tiếp cận thiết bị

Với một camera chưa biết gì thì chúng ta có thể tiến hành dump firmware. Nhưng việc đó cần nhiều hiểu biết về phần cứng, là một người mới bắt đầu tôi không chọn phương án này vì cần phải hàn mạch. Hướng tiếp cận đầu tiên là kết nối thiết bị vào mạng LAN rồi thực hiện dò xét các cổng mở để tìm được hướng tấn công tiếp  theo.

Để thực hiện việc này, đầu tiên sau khi kết nối vào cùng mạng wifi của camera tôi dùng công cụ nmap để quét ra ip của camera, sau đó tìm hiểu các cổng mở cũng như các thông tin liên quan:

Kết quả nmap vùng mạng chứa thiết bị

Sau bước này, ta sẽ xác định được địa chỉ ip của camera là 192.168.50.92. Các port mở là 554, 5000 thường được mở ở các thiết bị camera. Như vậy, không có các cổng thông dụng như HTTP, SSH, …

Tiếp tục thực hiện các lệnh nmap thông dụng :

Kết quả nmap thiết bị

Ta lại biết thêm được một thông tin thú vị về chiếc camera này. Có vẻ như nhà sản xuất là Shenzhen. Lên google search một hồi thì công ty này có các sản phẩm về camera. Lục tìm trong các sản phẩm xem có cái nào giống cái của mình đang nghiên cứu hay không.

Sau một thời gian dài kiên nhẫn, cuối cùng tôi cũng tìm được một con có vẻ khá giống loại mình đang nghiên cứu. Tìm các sản phẩm trên thị trường Việt Nam thì ra rất nhiều loại tương tự. Camera này có số hiệu YOOSEE 720P Z06H được bán với giá 350k trên shopee. Từ đây, mình cũng tìm được app điều khiển loại camera này. Đồng thời mở ra nhiều hướng để nghiên cứu thêm.

Nghiên cứu các cổng mở

Sau bước đầu tiên, tôi phát hiện được 2 cổng TCP đang mở. Các cổng này sẽ được dùng với mục đích gì? 

Cổng 554 được nmap gán với nhãn rtsp (Real Time Streaming Protocol), là một giao thức thường xuyên được sử dụng trong camera. Từ đây, tôi tìm một số công cụ để xem stream với rtsp.

Công cụ đầu tiên thành công xem được video là ONVIF Device Manager. Nó thực hiện các giao tiếp với camera qua cổng 5000 để nhận biết được các thông tin thông số kĩ thuật cũng như luồng stream. Tại thời điểm này, camera đang ở trạng thái không xác định nên tôi không thể dựng lại để viết được. Tool tiếp theo dùng được là  VLC media player. Chọn Open Network Stream  Url. Trong trường hợp này, luồng stream video nằm tại rtsp://192.168.50.92:554/onvif1. Tiến hành bắt request để xem cách thức tool giao tiếp với camera như thế nào

Một số gói tin được trao đổi giữa thiết bị và người quản trị

Đúng như mong đợi, công cụ thực hiện các request tới camera qua cổng 554, tuân theo chuẩn của rtsp.

Sau khi nghiên cứu hai ứng dụng này, tôi chưa phát hiện ra cơ chế xác thực nào của ứng dụng. Chả lẽ chúng ta có thể xem video từ camera một cách tự do thế sao?

Nghiên cứu ứng dụng Yoosee

Camera này có một ứng dụng quản lí trên điện thoại : Yoosee. Chúng ta có thể tải ứng dụng về, tạo tài khoản, đăng nhập và thực hiện các tác vụ quản lí camera trên ứng dụng này. Ứng dụng này cho phép chúng ta thêm thiết bị qua mạng lan, nó sẽ tự động dò quét ip để tìm ra camera, tiếp đến chỉ cần nhập password của camera là có thể quản lí thiết bị. Password mặc định là 123 có vẻ như là phổ biến cho tất cả các thiết bị.

Sau khi thêm thiết bị vào, các ứng dụng tại bước hai sẽ không thể xem video được nữa. Cũng không thể có 1 lúc 2 thiết bị cùng thêm một camera. Vậy là đã có câu trả lời cho bước trước tại sao không cần xác thực mà vẫn xem được video. Tuy nhiên, bằng ứng dụng ONVIF Device Manager, chúng ta vẫn có thể thực hiện các lệnh làm cho camera chuyển động. Tức là vẫn có những hành động mà chúng ta có thể tác động lên con camera này. Điều này mở ra nhiều hi vọng tìm kiếm những chức năng tương tự.

Thực hiện bắt request trên thiết bị android :

Ứng dụng giao tiếp với camera bằng giao thức UDP thông qua cổng 51880. Hmm có vẻ như là một cổng khá lạ, quét bằng nmap không ra. Các gói tin gửi đi cũng khá là vô nghĩa, nên ta khó có thể phân tích được nhiều.

Nghiên cứu firmware

Qua các bước trên, tôi đã có được cái nhìn sơ bộ về cách hoạt động của camera. Nhưng muốn nghiên cứu sâu hơn, cần phải có được mã nguồn firmware của camera. Lượn lờ trên google một hồi tôi cũng tìm được link thú vị này.

Nó cho phép chúng ta update firmware của camera đồng thời đi kèm là các bản firmware.

That’s all we need. Tiến hành upgrade thử một firmware. Tôi lại phát hiện ra một chức năng không cần xác thực nữa. Nếu không cần xác thực thì chúng ta có thể nghĩ cách inject backdoor vào trong firmware rồi update bản cập nhật. Tuy nhiên, dù không xác thực nhưng nó vẫn check MD5 ở đâu đó, nên khả năng chúng ta có thể động vào bản update là không thể.

Đến đây, tôi lại có một câu hỏi : điều gì xảy ra nếu ta thực hiện update các phiên bản chính của nhà phát hành nhưng là phiên bản cũ hơn phiên bản hiện tại. (⊙_⊙)?Phiên bản hiện tại camera mà tôi đang nghiên cứu là 21.00.00.95. Tôi lặng lẽ thử downgrade xuống phiên bản 14.00.00.00. Và rip chiếc camera die luôn. Nhấn nút reset cũng không thấy có phản hồi gì. Rip.

Tại đây, cũng mở ra nhiều hướng tấn công khác như là tìm một phiên bản chứa lỗ hổng bảo mật đã được khai thác, rồi downgrade firmware xuống, thực hiện tấn công trên các lỗ hổng đã có.

Extract firmware

Tiếp đến, extract firmware ra và xem chương trình thực hiện những gì. Extract bằng binwalk ta thu được:

File 23B964.elf là file update firmware. Thư mục jffs2-root chứa một phần firmware update. Tôi sẽ tập trung vào thư mục jffs2-root/fs_1

Trong thư mục này có chứa các file cấu hình của camera cũng như các file .xml dùng cho Onvif. File cần lưu ý nhất là file npc. Nó là chương trình chính điều khiển camera.

Phân tích sơ bộ file npc

File này là một file khá lớn, bị stripped hết nên sẽ tốn rất nhiều thời gian để dịch ngược toàn bộ chức năng của chương trình. Như hình trên có chức năng ẩn là thực hiện mở telnetd , tuy nhiên tôi chưa tìm ra cách để kích hoạt nó. Tôi xem qua ứng dụng cũng không thấy có các chức năng để mở cổng telnetd này. Đây có vẻ là một chức năng ẩn. Câu hỏi đặt ra là chức năng này được tạo ra để làm gì \(〇_o)/

Tiếp đến, tôi sẽ tập trung để tìm các hàm mở các cổng 5000, 554, 51880. Bằng cách lần theo các hàm để tạo socket như bind, connect, recv, send, ….

UDP 8899

Trong bài viết này tôi sẽ tập trung vào tính năng unauthen upgrade đã tìm hiểu ở bước trên. Tôi đã dịch ngược được hai hàm xử lí của 2 port TCP đã mở. Và không có hàm nào xử lí việc upgrade cả. Sau khi bắt request, tôi phát hiện ra tool upgrade giao tiếp với camera qua cổng 8899.

Hàm xử lí request tới cổng 8899 nằm tại địa chỉ 0x18EE64.

Chúng ta có thể chọn các lệnh để thực hiện chức năng thông qua bytes đầu tiên của request. Tại đây, chúng ta cũng có rất nhiều các chức năng unauthen nhưng có khá nhiều tham số mà khó có thể kiểm soát. Bộ nhớ được kiểm soát cũng rất tốt nên không có hàm nào bị buffer overflow ở đây.

Tiếp đến, phân tích request mà tool upgrade gửi tới camera sẽ sử dụng option 7. Đoạn xử lý được thực thi như sau:

Từ đó, ta có thể truyền vào request để xác lập port sẽ nhận bản cập nhật từ server và phương thức upgrade. Hàm xử lí chính của upgrade nằm tại địa chỉ 0x191B70.

Tại đây, ta thấy có rất nhiều lựa chọn upgrade chứ không chỉ upgrade mỗi firmware.

Việc upgrade các file hệ thống không có check md5. Ta hoàn toàn có thể tự tạo request và khiến cho hệ thống này cập nhật những thứ không mong muốn.

Tôi đã tiến hành dựng lại để thiết lập được một tính năng tấn công làm cho camera tự khởi động lại.

Đầu tiên thực hiện gửi request tới cổng 8899 để chọn option 7 cho tính năng upgrade. Thiết lập port và option upgrade. Tôi chọn port 21200 và option 0x2.

Sau đó, tạo server bind cổng 21200 để gửi bản cập nhật. Set các tham số tương ứng để thỏa mãn điều kiện:

Nếu các điều kiện trên đều được thỏa mãn, ta sẽ đến được đoạn:

Như vậy, hàm main sẽ thoát khỏi vòng lặp trên và tiến tới thực thi switch case:

Case 8 sẽ là thực hiện upgrade firmware từ file /mnt/ramdisk/tempRsUpg.bin . Sau đó thiết bị sẽ tiến hành reboot.

Với tính năng này, chúng ta có thể thực hiện reboot liên tục thiết bị gây ra một cuộc tấn công DOS camera.

Kết luận

Qua đây ta có thể thấy chiếc camera này mở rất nhiều cổng dịch vụ khác nhau, trong đó nhiều chức năng không yêu cầu xác thực. Thậm chí nó cho phép chúng ta downgrade phiên bản, tự động reboot,…. Làm hư hại nghiệm trọng tới thiết bị. Mở ra nhiều hướng tiếp cận có thể exploit được. Tuy nhiên do việc làm die con camera quá sớm dẫn đến còn nhiều thứ chưa được thử trên con camera để confirm nên chúng tôi không chia sẻ thêm ở đây. Cuối cùng tôi hi vọng bài viết đơn giản này có thể giúp mang lại cho các bạn cái nhìn khách quan hơn về tìm kiếm lỗ hổng trên các thiết bị camera.

Credit: @hacmao of Zepto Team

Nghiên cứu lỗ hổng bảo mật trên thiết bị IoT – Ảo hóa thiết bị bằng QEMU

Mở đầu

Xin chào, chúng tôi lại quay trở lại rồi đây.

Trong bài viết trước của nhóm, có lẽ nhiều bạn đọc vẫn còn thắc mắc là tại sao một thiết bị Router, Access Point, Camera IP lại có thể bị thỏa hiệp và biến thành một máy trạm trong một hệ thống Botnet. Có thể bài viết này và một số bài viết sau của chúng tôi sẽ giúp bạn đọc có cái nhìn khách quan hơn về lỗ hổng bảo mật trong các thiết bị IoT, đó là một trong những nguyên nhân chính dẫn đến việc các thiết bị IoT bị tấn công và trở thành một phần của mạng Botnet.

Trong bài viết dưới đây, mình sẽ chia sẻ về kỹ thuật sử dụng QEMU trong việc ảo hóa các thiết bị Router, Access Point, Camera IP nhằm đơn giản hóa quá trình nghiên cứu. Qua đó giúp quá trình tìm kiếm, phát hiện các lỗ hổng bảo mật trở nên đơn giản và hiệu quả hơn.

Những nghiên cứu này nhằm mục đích tìm và phát hiện các lỗ hổng bảo mật trên các nhóm thiết bị nêu trên, qua đó giúp cho nhà cung cấp có thể sửa đổi, khắc phục để nâng cao chất lượng cũng như đảm bảo an toàn thông tin cho người dùng.

Tại sao tôi lại chọn ảo hóa thiết bị mà không phải là nghiên cứu trên các thiết bị thật?

Với những dòng thiết bị tôi đang nghiên cứu thông thường có giá bán trên thị trường cao hoặc không tìm mua được ở Việt Nam mà phải đặt mua ở nước ngoài về, đó chính là những rào cản trong việc sở hữu một thiết bị thật để nghiên cứu. Chính vì thế tôi chọn việc ảo hóa thiết bị để có thể thực hiện được công việc của mình, và đây là những ưu điểm mà tôi thấy được từ việc sử dụng ảo hóa:

  • Tiết kiệm chi phí nghiên cứu
  • Tiết kiệm thời gian không phải chờ mua thiết bị
  • Tương tác với môi trường ảo hóa dễ dàng hơn tương tác với thiết bị thật

Ngoài ra ảo hóa cũng có những nhược điểm nhất định như sau:

  • Không giống hoàn toàn thiết bị thực tế
  • Một số thiết bị khó ảo hóa và tốn nhiều thời gian để thực hiện hoặc không thể thực hiện được ảo hóa

Ảo hóa thiết bị

Cài đặt môi trường?

Ở đây tôi sử dụng những công cụ sau:

  • Một máy ảo linux (nên dùng ubuntu server)
  • QEMU
  • binwalk
  • squashfs-tools
  • jefferson
  • pwndbg
  • gdb-multiarch

Đầu tiên cần phải cài một máy ảo linux, ở đây tôi khuyến khích mọi người sử dụng ubuntu server 16.04.

Lưu ý đối với cấu hình máy ảo cần được tích chọn “Enable hypervisor application in this virtual machine”.

Yêu cầu cấu hình máy ảo:

  • MEMORY: >= 1GB
  • CORES: >= 2
  • HARD DISK: >= 30GB
Cấu hình được dùng cho máy ảo linux

Sau khi cài đặt thành công máy ảo, download file cài đặt setup.sh và khởi chạy.

Ảo hóa thiết bị như nào?

Trong phần này tôi sẽ làm một ví dụ cụ thể để mọi người có cái nhìn cụ thể hơn về hướng mà tôi đã làm để có thể ảo hóa thiết bị. Ở đây tôi chọn Router DIR-882 của nhà cung cấp D-Link bởi tôi thấy nó có đầy đủ các thông tin cũng như các bước cần thiết để có thể thực hiện được ảo hóa đối với nhiều thiết bị khác.

Việc đầu tiên cần làm là tải về firmware của thiết bị đó về.

Bước 1: Phân tích tìm rootfs của thiết bị

Sau đó thực hiện extract firmware vừa tải được để lấy được rootfs của thiết bị. Tôi xin phép không nói cụ thể về việc này bởi việc này đã được hướng dẫn trong một blog của ZDI từ những kỹ thuật mà tôi đã đính kèm trong những báo cáo lỗ hổng bảo mật. Mọi người có thể tham khảo thêm thông tin tại blog của zdi.

Bước 2: Xác định kiến trúc của thiết bị

Sau khi có được rootfs của thiết bị, cần kiểm tra xem thiết bị sử dụng kiến trúc nào? Thông thường tôi thực hiện chạy lệnh $ file rootfs/bin/busybox để xem xem file này thuộc kiến trúc nào.

Có thể thấy thiết bị sử dụng kiến trúc mipsel (little endian)

Sau khi biết được thiết bị sử dụng kiến trúc gì, ta cần chạy một máy ảo chạy kiến trúc đó bằng QEMU. Ở đây tôi sử dụng một máy ảo mipsel được build sẵn và chia sẻ ở trên mạng.

Mình có viết một script hỗ trợ việc chạy máy ảo mipsel, mọi người có thể tải file cài đặt emumipsel.sh về và chạy chúng.

Lần đầu chạy file emumipsel.sh

Sau khi máy ảo QEMU đã chạy thành công, mọi người có thể thực hiện đăng nhập với username/password là root/root.

Bước 3: Đưa rootfs vào trong máy ảo QEMU

Ở bước 1 chúng ta đã có được rootfs của thiết bị này. Ở bước này chúng ta thực hiện đưa toàn bộ file trong này lên máy ảo QEMU.

Đầu tiên nén rootfs thành một tập tin bằng câu lệnh sau:

  • tar -czvf rootfs.tar.gz rootfs/

Sử dụng scp trong máy ảo QEMU để đưa rootfs vào trong máy ảo QEMU:

Giải nén tập tin tại máy ảo QEMU bằng câu lệnh sau:

  • tar -xvf rootfs.tar.gz

Bước 4: Ảo hóa nvram

Lưu ý: Với những thiết bị không sử dụng nvram thì không cần làm bước này.

Nhận thấy thiết bị có sử dụng nvram tuy nhiên máy ảo QEMU không hỗ trợ nvram, chính vì thế cần phải có một công cụ giúp hỗ trợ ảo hóa nvram cho trường hợp này. Sau khi tìm kiếm trên mạng và phát hiện được một công vụ giúp hỗ trợ ảo hóa nvram khá ổn là libnvram của firmadyne.

Thiết bị có sử dụng nvram

Để tạo được một libnvram ta cần phải sử dụng cross compiler để có thể build được một libnvram với kiến trúc mipsel để sử dụng được bên trong máy ảo QEMU. Các bạn có thể tải về cross compiler phù hợp từ đường dẫn sau:

Sau khi build được libnvram thì đưa chúng vào trong máy ảo QEMU bằng câu lệnh scp.

Bước 5: Chỉnh sửa cấu hình để chạy ảo hóa.

Ở bước này chúng ta cần phải chỉnh sửa một số nội dung các file khởi chạy ban đầu để phù hợp với điều kiện chạy trong máy ảo. Cần có một số chú ý như sau:

  • Thiết bị sẽ sử dụng các device có sẵn của máy ảo QEMU và việc mount hay unmount các device khác là không phù hợp và có thể không tương thích dẫn đến máy ảo bị crash và dừng lại.
  • Thiết bị sử dụng card mạng của máy ảo QEMU, chính vì thế các cấu hình mạng mặc định của thiết bị có thể làm hỏng cấu hình mạng của máy chủ dẫn đến việc kết nối từ máy ảo QEMU (guest) đến máy ảo linux (host) bị hỏng.

Từ những lưu ý trên, chúng ta cần phải sửa những câu lệnh có ảnh hưởng đến các device hoặc các cấu hình liên quan đến card mạng. Trước tiên cần tìm được file khởi chạy ban đầu của thiết bị, đọc nội dung trong file inittab cho thấy file /etc_ro/rcS được khởi chạy ngay sau khi thiết bị được bật.

Cấu hình khởi động của thiết bị

Đọc nội dung của file rcS và các file được rcS gọi tới chúng tôi phát hiện tập tin makedevlinks.sh trong đó có chạy các lênh mount, mknod. Để không ảnh hưởng đến máy ảo QEMU trong quá trình chạy ảo hóa thiết bị, tôi đã thực hiện comment dòng lệnh này.

Nội dung file khởi động của thiết bị

Bước 6: Bắt đầu chạy ảo hóa

Việc đầu tiên cần làm là thực hiện chia sẻ tài nguyên giữa máy ảo QEMU với thiết bị sẽ được ảo hóa bằng các lệnh mount:

  • mount -o bind /proc rootfs/proc/
  • mount -o bind /dev rootfs/dev
  • mount -o bind /sys rootfs/sys

Sau đó thực hiện đưa libnvram vào thư mục rootfs và cấu hình ảo hóa nvram:

  • mv path/libnvram.so rootfs/libnvram.so
  • mkdir rootfs/firmadyne

Thực hiện ảo hóa bằng câu lệnh chroot:

  • chroot rootfs /bin/sh

Bên trong môi trường chroot thực hiện chạy những câu lệnh sau:

  • export LD_PRELOAD=/libnvram.so
  • /etc_ro/rcS

Chờ câu lệnh chạy xong và xem các kết quả hiển thị ra để xác định các lỗi có thể gặp phải.

Kết quả chạy ảo hóa thiết bị

Bước 7: Fix các lỗi gặp phải khi chạy (nếu có)

Kiểm tra các tiến trình đã được chạy của thiết bị ảo hóa thì không thấy có dịch vụ lighttpd (dịch vụ web service).

Các tiến trình được chạy bởi ảo hóa thiết bị

Tìm kiếm dựa vào những gì hiển thị sau khi chạy /etc_ro/rcS tôi tìm được dịch vụ lighttpd được chạy bởi /bin/init_system

lighttpd được chạy bởi init_system

Thực hiện dịch ngược file init_system tôi tìm được nguyên nhân dẫn đến lighttpd không được chạy là do file /var/run/nvramd.pid không tồn tại trong hệ thống.

Dịch ngược file init_system

Sau khi dịch ngược tập tin init_system tôi thấy để chạy được lighttpd chỉ cần chạy câu lệnh được sử dụng trong file: lighttpd -f /etc_ro/lighttpd/lighttpd.conf -m /etc_ro/lighttpd/lib

Chạy lighttpd

Thực hiện chạy câu lệnh trên và xem kết quả nhận được, có thể thấy lỗi xảy ra do một số cấu hình của lighttpd chưa được đẩy đủ. Để khắc phục vấn đề này, tôi thực hiện comment hết những dòng không cần thiết trong file /etc_ro/lighttpd/lighttpd.conf để có thể khởi chạy được lighttpd.

Những nội dung cần comment lại
lighttpd server đã được chạy thành công
Truy cập vào web page

Có thể thấy dịch vụ lighttpd đã chạy thành công tuy nhiên không hoàn chỉnh được như một thiết bị thật. Dẫu vậy ta vẫn có thể sử dụng phiên bản emulator này để debug dịch vụ lighttpd hoặc các dịch vụ khác đang được chạy trên thiết bị.

Do bài viết đã dài nên tôi xin phép không chia sẻ thêm về cách cài đặt để có thể debug được ứng dụng mà sẽ nói trong bài viết tiếp theo.

Kết Luận

Như vậy có thể thấy được để ảo hóa một thiết bị bằng QEMU không quá khó, tuy nhiên nó đòi hỏi nhiều kiến thức cũng như am hiểu về các thiết bị mà mình muốn ảo hóa. Thông thường lần đầu tiên thực hiện sẽ tốn nhiều thời gian còn những lần tiếp theo sẽ tốn ít thời gian hơn.

Chúng tôi sẽ còn chia sẻ thêm nhiều những bài viết, những chia sẻ về kỹ thuật hữu ích đến các bạn trong thời gian sắp tới. Trong bài viết tiếp theo có thể tôi sẽ chia sẻ cách để debug dịch vụ lighttpd được chạy trên thiết bị DIR-882 được sử dụng trong ví dụ trên.

Xin cảm ơn các bạn đã dành thời gian để đọc. Hãy chia sẻ nếu thấy hay và để lại những bình luận góp ý phía bên dưới nhé!

Credit: @chung96vn