Messages posted by: xnohat

HTTPS chỉ dùng khi login, sau khi login thì nên xoá cái https ở đầu thay bằng http smilie

Đã bắt đầu, hãy theo dõi các topic có tag "Script Kidy - Tut"
Hoặc theo dõi trang http://www.scriptkidy.com/ khi HVA chập chờn hoặc điên điên

DDoS và Chiếm dụng băng thông bằng Facebook Notes và Google SpreadSheet

[img]http://2.bp.blogspot.com/-wcJFLecPWPE/U1wtPtybDsI/AAAAAAAAAVw/6m0530-T7YA/s1600/Screen+Shot+2014-04-27+at+3.24.19+AM.png[/img]

Các cơ chế proxy preload của các Mạng XH ( vd: Facebook ) và các Cloud Application ( vd: Google Docs ) tiềm tàng một nguy cơ là có thể bị "mượn tay" để tấn công DDoS hoặc tấn công chiếm băng thông

Qua thử nghiệm các Vul này trên Facebook thì trong 2 phút, nó nuốt trôi hơn 8GB băng thông
Nếu kết hợp cùng lúc nhiều account, nhiều dịch vụ cloud khác nhau ( có hỗ trợ proxy preload ) thì khả năng nạn nhân bị DoS và bị disable dịch vụ hosting vì hết băng thông rất cao

Nguy hiểm cái là các bug này đều được báo cáo rồi nhưng cả mấy thằng to như Facebook, Google đều bảo là "đây là tính năng ếu phải bug" nên không sửa ( chắc cũng hơn 1 năm rồi )

Cách thực hiện thử nghiệm:

Cần có:

Mua một VPS làm nạn nhân thử nghiệm
VPS cài iftop hoặc bất kỳ công cụ nào để xem băng thông bị chiếm dụng
Upload một file bất kỳ có kích thước > 10MB lên VPS. vd: testdos.pdf . Ghi lại URL tới file này ( vd: http://xnohat.com/share/testdos.pdf )

Thực hiện tấn công với Facebook Notes:
Tạo một account Facebook bất kỳ, tạo Facebook Note với nội dung, chứa khoảng 1000 dòng như sau

Code:

<img src='http://xnohat.com/share/testdos.pdf?r=1'/>
<img src='http://xnohat.com/share/testdos.pdf?r=2'/>
<img src='http://xnohat.com/share/testdos.pdf?r=3'/>
<img src='http://xnohat.com/share/testdos.pdf?r=4'/>
<img src='http://xnohat.com/share/testdos.pdf?r=5'/>

Chú ý sẽ thấy sau mỗi url sẽ có thêm một biến số bất kỳ với giá trị tăng dần, đây là chỗ làm tăng tốc và mức độ nguy hại của phương thức DoS này ( giải thích cặn kẽ thì tham khảo link đính kèm cuối bài ).
Mỗi dòng khi load lên sẽ gửi một request tới nạn nhân, 1000 dòng tương đường với 1000 request download file PDF 10MB như trên, tương đương 10GB băng thông bị ngốn
[img]http://2.bp.blogspot.com/-51qjXlY-Z24/U1wphr6fE1I/AAAAAAAAAVg/X-rMIxFxF04/s1600/Screen+Shot+2014-04-27+at+3.05.28+AM.png[/img]

Thực hiện tấn công với Google Docs:

Tạo một file Google Docs Spreadsheet với 1000 dòng nội dung, mỗi dòng có nội dung tương tự như sau:
Code:

=IMAGE(http://xnohat.com/share/testdos.pdf?r=1)
=IMAGE(http://xnohat.com/share/testdos.pdf?r=2)
=IMAGE(http://xnohat.com/share/testdos.pdf?r=3)
=IMAGE(http://xnohat.com/share/testdos.pdf?r=4)
=IMAGE(http://xnohat.com/share/testdos.pdf?r=5)

Chú ý sẽ thấy sau mỗi url sẽ có thêm một biến số bất kỳ với giá trị tăng dần, đây là chỗ làm tăng tốc và mức độ nguy hại của phương thức DoS này ( giải thích cặn kẽ thì tham khảo link đính kèm cuối bài ).
Mỗi dòng khi load lên sẽ gửi một request tới nạn nhân, 1000 dòng tương đường với 1000 request download file PDF 10MB như trên, tương đương 10GB băng thông bị ngốn
[img]http://1.bp.blogspot.com/-J1SwF9aVvy0/U1wsb29sFhI/AAAAAAAAAVs/E-0WtQ6vv1g/s1600/Screen+Shot+2014-04-27+at+2.53.06+AM.png[/img]

Cách thức tăng mức độ nguy hại của kiểu tấn công này:
- Phối hợp giữa Facebook Notes DDoS và Google Spreadsheet DDoS
- Refresh liên tục các trang notes và các trang spreadsheet
- Dùng nhiều account để mở nhiều trang notes và các trang spreadsheet
- Dùng nhiều máy tính + nhiều account để mở nhiều trang notes và các trang spreadsheet

Với cách thức DDoS này thì băng thông tối đa có thể DDoS được lên đến 800Mbps. Và lưu lượng băng thông bị ngốn là rất lớn. Nếu gặp các dịch vụ hosting có giới hạng băng thông tối đa hàng tháng thì nạn nhân nhanh chóng bị ISP ngưng dịch vụ vì hết bandwidth limit của tháng

xnohat

Tham khảo thêm:
http://thehackernews.com/2014/04/vulnerability-allows-anyone-to-ddos.html
http://chr13.com/2014/04/20/using-facebook-notes-to-ddos-any-website/
http://chr13.com/2014/03/10/using-google-to-ddos-any-website/

Điều khoản miễn trừ: chúng tôi không chịu trách nhiệm đối với bất kỳ hành động nào của bất kỳ ai khi sử dụng các kiến thức được cung cấp trong bài viết này cho mục đích sai trái. Nếu bạn vi phạm pháp luật, bạn sẽ phải tự chịu trách nhiệm

P.s: cái BBCode IMG của HVA hết chạy rồi smilie

Coi bản formatted tại đây http://www.scriptkidy.com/2014/04/ddos-va-chiem-dung-bang-thong-bang.html

Gói tin mẫu sniff quá trình tấn công OpenSSL Heartbleed smilie

khá thú vị smilie

http://blog.didierstevens.com/2014/04/09/heartbleed-packet-capture/

NGƯNG MỌI GIAO DỊCH TRỰC TUYẾN NGAY LẬP TỨC !!!

Thông tin khẩn. Do tình trạng mã khai thác của lỗi OpenSSL Heartbleed đang tràn lan và nhiều hacker đã triển khai thành mã khai thác tự động trên diện rộng

Nên thông báo khẩn cấp cho cộng đồng cần tạm ngưng việc giao dịch trực tuyến trên tất cả các cổng thanh toán và tất cả các ngân hàng trực tuyến cho đến khi các ngân hàng và các cổng này thông báo đã vá lỗi

Theo ghi nhận hiện nay có nhiều cổng thanh toán và ngân hàng đang dính lỗi mà chưa vá, các thông tin thẻ có thể bị thu thập dễ dàng

Hãy truyền tin cảnh báo này cho bạn bè bạn ngay khi đọc được

HVAOnline.net

Thông tin kỹ thuật về lỗi này chi tiết tại đây:
http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html

xnohat

Cái bookmark này hay đấy. Tks bồ đã collect giúp smilie

Vô chrome extension gỡ toàn bộ các extension trong Chrome ra

startbkhn wrote:

cảm ơn vì đã giúp mình trả lời câu hỏi. mình cũng đang muốn truy xuất vào chuỗi nhị phân chứa data của ảnh bmp của bạn, rồi băm nó ra để tạo chứ ký số cho file. đang định insert vào file nhưng không biết đặt chỗ nào cho hợp lý

Nếu chỉ để "băm file ra để tạo chữ ký số cho file" hay gọi nôm na dễ hiểu là Hash Checksum ( MD5 Checksum, SHA-1 Checksum ... ) thì không cần quan tâm tới các file format làm gì smilie

Bồ nên hiểu file format là cách sắp xếp nội dung bên trong 1 File. Hiểu nôm na
- File là cái thùng to
- Trong cái thùng có cả núi văn phòng phẩm: đây là nội dung file

Bạn sắp giấy in ở dưới rồi để mấy cái kẹp sách ở trên 1 lớp, rồi trên cùng là bút chì, gôm, thước... Đây là file format smilie

Khi băm thì bồ cứ việc lấy toàn bộ nội dung ra băm ( băm toàn bộ cả header lẫn body... etc ) chứ hiểu file format làm gì ? khi mà trên đời có hàng triệu loại file format khác nhau ?

Kể hoài thì chả biết bao giờ hết smilie

) , nên tốt nhất bồ nên nói bồ đã tìm hiểu dc gì smilie

gạch đầu dòng và ghi ra

tuannhat0blue wrote:

Cho em hỏi người mới vào ngành như em thì gọi là newbie thế những cấp độ và tên gọi của những người trên cái tầm newbie thì gọi là gì vậy?

Có các mức thường gọi

New user
User
Advanced User
Researcher
Hacker

Newbie thường ngang với mức New user

Trân trọng,

Góc newbie - Dành cho người mới vào nghề

Topic này sẽ là topic để post các Hỏi-Đáp dành cho tất cả các câu hỏi dù là ngây thơ, nhảm, xàm của các mem mới vào nghề (newbie), chưa biết gì. Chấp nhận hết, còn trả lời hay không thì còn tuỳ xem smilie

Dĩ nhiên cấm các thể loại comment: Troll ( vô duyên ra đảo, có duyên thì được ), chửi bới, nói móc, xỉa xói
Khứa nào vi phạm thì ra đảo nhé nhẹ thì 1 tuần nặng thì đi luôn

Topic này không chỉ để chờ các Mod, Admin trả lời mà Topic này còn là chỗ để các mem có kinh nghiệm vô trả lời các newbie. Dĩ nhiên việc này sẽ có sự đền đáp xứng đáng, ai chịu khó reply thảo luận, hỗ trợ những mem khác, chia sẻ kinh nghiệm thì sẽ được chú ý và dĩ nhiên là sẽ được ưu tiên một số quyền lợi nhất định kiểu như lâu lâu được share mấy cái tool xịn, được trả lời khi hỏi riêng ( mấy khứa khác PM inbox thì xác định là pm vô lỗ đen nhé không mấy khi rảnh trả lời đâu ), gặp mem nào khá giỏi và tích cực thì có thể có cơ hội ngồi nhậu với một số anh em khác trong BQT

Trân trọng,

Lớp học "Hacking" - Scriptkiddies class

Đêm mùng 3 tết Nhâm Ngọ dương lịch 2014,

Ngẫm thấy HVA lâu rồi không có hoạt động gì lấy làm xôm xụ. Tôi thấy cũng nên khuấy một chút lên

Tôi quyết định là sẽ mở lại một topic cũ xưa tôi từng lập trên HVA với tên "Lớp học Hacking" . Nhưng lần này có hơi khác một chút, lần này sẽ theo hướng "Script Kiddies" , tức đây sẽ là lớp của mấy trò "nghịch" và "phá" với các công cụ sẵn có

Lý do tại sao lần này lại mở lớp theo hướng này ?

Umm, HVA giờ toàn người già smilie

mà mình thì thích HVA xưa cũ lúc các anh già bây giờ, còn trẻ smilie

hồi ấy đầy những trò nghịch phá, đánh đấm. Vậy mới đậm chất H4k0r.
Với lại cái gì cũng phải có 2 thái cực, phải có tốt có xấu thì mới cân bằng. Có mấy ông anh lớn lo chuyện "bảo mật" rồi, tôi sẽ khuếch trương vụ "phá" smilie

Tính tôi thì thích nghịch ngợm, chuyện nghiêm túc để các anh lớn lo.

Lớp này sẽ hoạt động ra sao ?

Sẽ có 2 hình thức:
1. Tút ( tutorial ) lâu rồi HVA không có mấy cái tút gì mới cả smilie

. Đây là hình thức truyền kinh nghiệm kiểu "truyền thống" smilie

2. Lớp live trên Youtube, cái này thì đợi tui có đủ 100 Subcrible thì sẽ thử nghiệm 1, 2 course gì đó . Lâu lâu làm một cái lấy không khí smilie

. Bạn nào rảnh thì Subcrible cái Channel này của tôi đặng có đủ 100 cái theo yêu cầu của Youtube https://www.youtube.com/user/xnohatchannel

Điều kiện để tham gia ?
1. Thành viên HVA ( dĩ nhiên smilie

)

2. Có não ( mấy kiểu hỏi ngu, chửi bới, nói xách mé ... etc trong topic này là ra đảo hết , vOz cũng từ HVA mà ra nên tự hiểu ha smilie

)

3. Kiến thức nên có (có thì đọc tút mới làm theo được, còn không thì coi thấy giống Kinh viết bằng tiếng Phạn thôi smilie

)

a. Lập trình: cần phải biết lập trình (tốt nhất là nên giỏi smilie

). ngôn ngữ thì C, C++, Java, PHP, Visual Basic, Python ... cái gì cũng được miễn biết lập trình. Còn chưa biết ? đi đăng kí học ở đâu đi. Đến lập trình còn đếch biết thì hack hiếc cái éo. Lời khuyên: nên học C/C++ trước cho mấy trò hack trên local, rồi học cả PHP + SQL + HTML + CSS + Javascript cho mấy trò hack web, rồi rảnh thì học thêm Python này nọ cho nó theo kịp thời đại ( mền đếch biết Python smilie

và chả ngại gì việc này )
b. Biết xài giao diện dòng lệnh của Linux ( bash hay sh ). Biết xài giao diện dòng lệnh của Windows ( cmd.exe ). Biết xài tức là biết mấy lệnh cơ bản như ls , dir, rm -rf , mv , cp ...
c. Phải biết xài Linux ! cái này mới giống hacker, éo biết cái này thì dẹp, nghỉ mơ hack hiếc đi. Chưa biết thì cài một cái vô máy ảo rồi tải cái này về, in ra rồi đọc mà học cách xài Linux http://hanoi.centre-linux.org/IMG/pdf/l4u.pdf . Khứa nào comment kiểu "Em không biết xài linux" thì xác định là ra đảo nhé

4. Đạo đức nên có:
a. Chịu khó mò. Tút viết thế thì cứ làm theo, làm không được thì tự mò lí do tại sao làm không được, lên hỏi kiểu "em làm theo y chang mà không được" thì ra đảo luôn
b. Chịu khó thảo luận, tức là mò được cái gì hay thì lên share. Vì HVA không có nút thank nên chả biết ai đọc rồi ai chưa đọc, vì vậy ai chịu khó reply thảo luận, hỗ trợ những mem khác, chia sẻ kinh nghiệm thì sẽ được chú ý và dĩ nhiên là sẽ được ưu tiên một số quyền lợi nhất định kiểu như lâu lâu được share mấy cái tool xịn, được trả lời khi hỏi riêng ( mấy khứa khác PM inbox thì xác định là pm vô lỗ đen nhé không mấy khi rảnh trả lời đâu ), gặp mem nào khá giỏi và tích cực thì có thể có cơ hội ngồi nhậu với một số anh em khác trong BQT
c. Nguyên tắc bất thành văn trong giới nên nhớ:
- Không thử nghiệm hack hiếc trên website hay hệ thống của người khác, không thuộc sở hữu của bản thân
- Không mó máy vào website của các chính phủ, các công ty ...
- Không bàn chuyện chơi CC trên này ( đây không phải forum Underground )
Khứa nào không tuân theo thì trời phạt ráng chịu, đừng khóc, năm nào cũng có vài khứa chơi dại rồi đi tù, đọc báo thì biết

Bao giờ bắt đầu ?

Đã bắt đầu, hãy theo dõi các topic có tag "Script Kidy - Tut"
Hoặc theo dõi trang http://www.scriptkidy.com/ khi HVA chập chờn hoặc điên điên

Chào thân ái và quyết thắng,
Trân trọng,

xnohat

Rất tiếc đến tên phần mềm nghe còn lạ lẫm. Khi nào phần mềm này phổ dụng và trở thành nhu cầu bức thiết, chúng tôi sẽ cân nhắc bổ sung

Trân trọng,

Hiện đã lưu hành một exploit script khai thác một lỗi mới của diễn đàn vBulletin. Lỗi này là lỗi SQLinjection xảy ra tại biến nodeid của script index.php/ajax/api/reputation/vote

Các administrator các diễn đàn đang dùng vBulletin nên cập nhật bản vá mới nhất từ vBulletin .Inc hoặc tắt module trên hoặc chặn truy cập module trên bằng mod_security hoặc tự patch sửa lỗi dựa trên mã khai thác dưới đây

http://www.exploit-db.com/exploits/30212/

Rất tiếc trên windows môi trường desktop không có ứng dụng nào làm chuyện trên. Cách tốt nhất là cài một firewall vào mặc định sẽ chặn các remote connection smilie

nếu ai tìm cách remote firewall sẽ alert smilie

Lỗi nghiêm trọng trong vBulletion 4.x , 5.x install script đang bị khai thác diện rộng bằng công cụ tự động

Đang có một lỗi nghiêm trọng đã được nhận diện ( từ ngày 13/8 ) trong script cài đặt của vBulletin ( mã nguồn Forum đang được sử dụng rộng rãi tại Việt Nam ). Lỗi nằm trong các script nằm trong các folder
Code:

4.X - /install/
5.X - /core/install

Hiện đã có công cụ khai thác tự động lỗi này được bán trên các forum UG nước ngoài

Các quản trị viên của các diễn đàn đang dùng vBulletin nên mau chóng xoá bỏ các thư mục cài đặt trên nhằm tránh bị khai thác, cũng như cập nhật phiên bản vBulletin mới nhất

xnohat

Tham khảo thêm:
[1] http://www.vbulletin.com/forum/forum/vbulletin-announcements/vbulletin-announcements_aa/3991423-potential-vbulletin-exploit-vbulletin-4-1-vbulletin-5
[2] http://www.webhostingtalk.com/showthread.php?t=1299608
[3] http://thehackernews.com/2013/09/major-vbulletin-based-websites-are.html

Mền thắc mắc là Unikey vốn là opensource với source code được public tại đây

http://unikey.org/source.php

Tại sao phải reverse rồi patch chi cho mất công nhẩy smilie

Trên mạng internet cũng còn lưu trữ một số thảo luận tại unikeyspell, có hồi đáp của tác giả Phạm Kim Long. Nếu các bồ thực sự thích và muốn phát triển Unikey mở rộng tiếp thì có thể liên lạc với bác ấy, tôi có thể làm cầu nối smilie

https://groups.google.com/forum/#!topic/unikeyspell/p3LrUKm72XA

Lời bàn: Unikey thực sự được viết rất tốt, suốt từ năm 2009 tới giờ thực tế là không cần bản vá lỗi nào mà sản phẩm này vẫn hoạt động bền bỉ trên mọi phiên bản hệ điều hành Windows. Điển hình của một phần mềm rất tốt smilie

firewallcookies wrote:

Sử dụng cookies sẽ giúp ta loại bỏ các bot, tool ddos, dos. Vì cookies chỉ tồn tại giữa. Trang web và browser.

Ý này sai ở một điểm quan trọng smilie

Đoạn script trên bị mấy con bot bypass cái một smilie

ldd wrote:

Chào mọi người,

Hiện tại mình có lập trình một phần mềm sử dụng giao thức tự phát triển có tên gọi GBProrotol dùng để truyền file và message trên nền TCP.

Giao thức này có thể truyền file nhanh hơn FTP từ 4-5 lần tùy vào mức độ nén được của file.

Do nhu cầu cần ứng dụng trong thực tế đòi hỏi phải có đăng nhập khi truyền dữ liệu, mình cũng đã bổ sung thêm tính năng đăng nhập, khi có đăng nhập thì lại phải giải tiếp bài toán về bảo mật thông tin, thế lại lại phải thêm phần mã hóa.

HIện tại GBProtocol đã hỗ trợ mã hóa đường truyền dùng AES 256 bit. Key AES khi truyền được mã hoá bất đối xứng dùng RSA 1024 bit, hỗ trợ truyền public key qua lại giữa client và server mà không cần bất kỳ can thiệp nào. Username và password khi truyền cũng được mã hóa kết hợp giữa SHA-256 và MD5.

Mình cũng đã thử sniff test và nhận thấy rằng data đã được mã hóa tương đối ổn (ý kiến chủ quan của mình thôi nhé, chắc chắn sẽ có nhiều sai sót).

Mình hy vọng các bạn trên diễn đàn có thể sử dụng thử và cho mình ý kiến về cách thức bảo mật đường truyền như thế này có cần quan tâm thêm một số vấn đề gì hay không? hoặc có lỗ hổng bảo mật nào khiến hacker có thể can thiệp, lấy và hiểu được các thông tin quan trọng không?

Rất mong sự góp ý của các bạn.

Website giới thiệu GBCopy: http://gbcopy.misamap.com

Chúc các bạn ngày vui!

Trân trọng,

Điều đầu tiên tôi muốn hỏi là hiện giao thức GBProtocol này của bồ tạo ra là giao thức mở hay đóng ?

Nếu giao thức đóng thì thường sẽ không có các thảo luận chuyên sâu hơn cho tới khi giao thức này của bồ được thương mại hoá và có giá trị khiến các chuyên gia phải bỏ thời gian reverse giao thức và tấn công giao thức. Tuy nhiên nếu có chuyên gia thấy thú vị thì đôi lúc họ vẫn có thể "ngồi nghịch" chút smilie

Nếu đây là giao thức mở thì bồ nên tham khảo layout của các tài liệu Request For Comment ( RFC ), trình bày lại đầy đủ thiết kế giao thức, lúc đó các chuyên gia sẽ có căn cứ để góp ý ( đúng tinh thần Request For Comment )

Sơ bộ theo bồ mô tả có vẻ giao thức này chỉ bổ sung thêm 2 giải pháp: nén và mã hoá ( bất đối xứng ) đối với dữ liệu trung chuyển. Còn gì đặc biệt trong đặc tả của giao thức mà bồ chưa nói không ?

cacthanh123 wrote:

Hello các bạn

Server mình dạo này thường xuyên bị ddos, attacker có 2 kiểu ddos như sau :

Mình dùng tcpdump, mình dùng Linux server, file pcap mình open trên windows

Loại thứ 1 : SYN FLOOD

http://i.upanh.com/vpvtsn

File capture package : http://www.mediafire.com/download/09dy34d9y99adk4/ddos-servervn.pcap

Tình trạng : SSH vẫn truy cập bình thường, nhưng apache port 80 bị treo dẫn đến toàn bộ website không tải được.

Kiểm tra trạng thái kết nối, mình thấy thế này :

5 ESTABLISHED
1 FIN_WAIT2
3 LISTEN
5 TIME_WAIT
300 SYN_RECV

Dùng CSF enable SYNFLOOD giới hạn lại cũng chẳng ăn thua

Loại thứ 2 : DNS Ampli DDoS

http://i.upanh.com/vpvtsd

File dump : http://www.mediafire.com/?ptdl4qifm9etdxc

Loại này kinh khủng quá, nó ddos vào là server die liền, ko kịp ngáp, OFF mạng của Dedicated, dùng KVM remote vào, lệnh #iptraf, thấy TCP bình thường, nhưng UDP chạy chóng mặt, card mạng mình max là 100mbps, nó ddos vào 15s là lên đến 99mbps, server die ngay lập tức, không thể SSH, chỉ có thể ngồi tại phòng server mà gõ terminal.

Nếu cần mình sẽ attack file pcap dump đc khi bị ddos lên cho các bạn xem và dễ hình dung nhé.

Mong các bạn hỗ trợ mình, vì ngày nào mình cũng chịu ít nhất là 2 giờ bị ddos, không biết làm sao để thoát nạn cả.

Cảm ơn các bạn đã quan tâm.

Hi bồ,

Về syn flood thì bồ cản lọc dựa trên phân tích tần suất syn packet trong file dump của bồ

Về DNS amplify DDoS thì bồ có 2 thứ cần làm
1. Liên hệ Datacenter yêu cầu filter từ router biên các kết nối UDP không cần thiết ( dựa trên phân tích file dump của bồ )

2. Phân tải cho server bằng việc tăng các reverse proxy, ở trường hợp của bồ tăng thêm 2 cái nằm ở 2 DC với 2 ISP internet khác nhau là ổn

Tham khảo thêm:
/hvaonline/posts/list/44934.html
/hvaonline/posts/list/44935.html

Hiện tôi đã có tạo một project trên GitHub và sẽ dần dần release từng bộ từ điển tôi tổ hợp xong lên đây

https://github.com/xnohat/vipasswordict

@concobe: các ý tưởng bổ sung của bồ rất đáng giá và hữu lý, tôi sẽ cân nhắc thực hiện và bổ sung vào bộ vipasswordict

mylove14129 wrote:

quanta wrote:

Có bạn nào hứng thú trả lời mấy câu hỏi này không nhỉ?

e. Có bao nhiêu requests xảy ra trong một giây, một phút, 5 phút đi từ cùng một IP và có cùng một User-Agent?

f. Có bao nhiêu User-Agents khác nhau đi từ một IP trong một khoản thời gian nào đó?

Không rõ quanta có tool nào tự động thực hiện việc này không, thường mình hay sử dụng splunk filter khá tốt nhưng nếu yêu cầu phức tạp quá thì có lẽ nên làm một cái script có khi tốt hơn

Với lưu lượng DDoS lớn và kích thước log phì đại nhanh khủng khiếp thì việc dùng script để phân tích log có vẻ là thiếu hiệu quả vô cùng smilie

DDoS và nguyên tắc phân tích gói tin

Như đã đề cập ở bài trước /hvaonline/posts/list/0/44934.html)

Giảm thiểu tác hại của DDoS có hai hướng chính:

1) Giảm thiểu bằng cách cản lọc những đặc điểm cụ thể.

2) Giảm thiểu bằng cách cản lọc theo ấn định số lần truy cập trong một khoản thời gian (nếu không tìm ra được đặc điểm cụ thể).

Từ những thông tin nào có thể giúp mình thực hiện việc giảm thiểu ấy? Cách khó nhất, tỉ mỉ nhất nhưng cũng chính xác nhất là lấy thông tin từ những gói tin bắt được trong lúc chúng tràn vào mục tiêu (để thực hiện việc DDoS).

Có lẽ một trong những công cụ phổ biến nhất ngày nay cho công việc bắt gói tin và phân tích gói tin đó là Wireshark (ngày xưa có tên là Ethereal). Công cụ này cho phép chúng ta sắp xếp gói tin theo:
- thời gian gói tin đi đến.
- theo nguồn IP của gói tin.
- theo dạng giao thức của gói tin.
- theo chiều dài của gói tin.
- và đi sâu vào tính chất của từng gói tin.

Tuỳ nhu cầu, tuỳ hoàn cảnh mà sử dụng biện pháp sắp xếp để phân tích. Đôi khi cần phải đổi từ cách sắp xếp gói tin từ dạng này sang dạng khác để có thể nắm bắt tính chất được xem là "đặc điểm cụ thể".

Tất nhiên, logs trên proxies, trên web server (như Apache, Nginx, IIS..v..v..) cũng có thể dùng để phân tích nhưng chúng thiếu hẳn những thông tin cụ thể về giao thức. Tuy vậy chúng có điểm lợi là đơn giản hơn, dễ phân tích hơn nhưng nếu muốn nắm rõ tính chất những gói tin thuộc dạng DDoS không thể không dùng Wireshark để bắt gói tin và phân tích gói tin.

Lấy một đoạn packets được dùng để tấn công một nạn nhân gần đây (5/7/2013), chúng ta có thể thấy gì?

- Các gói tin đã được sắp xếp (sort) theo nguồn (IP) ở đây đang tập trung vào phân tích nguồn 113.170.184.21.

- Nếu bấm vào dòng có giao thức là HTTP và có Info là "GET / HTTP/1.1" thì sẽ thấy có giá trị "User-Agent" hiện ra. Theo thông tin ở đây, đó là một điện thoại di động dạng Android và có địa phương (locale) là Canada (en-ca).

- Gói tin HTTP kia có chiều dài là 502 bytes (bao gồm chiều dài của gói tin TCP/IP tầng dưới).

- Nếu sử dụng tính năng "follow TCP stream" của gói tin cụ thể trên, bạn sẽ thấy một nhóm các gói tin được gởi / nhận và được ráp lại.

Nếu xoáy sâu xuống một chút, mình có thể thấy thêm đây là một gói ACK có PSH flag và có chiều dài là 448 bytes.

Nếu tiếp tục xem xét danh sách các request đi từ 113.170.184.21, bạn sẽ thấy nhiều gói tin có tính chất y hệt xảy ra nhiều lần. Đó là chuyện bình thường nhưng sự thể sẽ bất thường khi cùng một IP lại có User-Agent khác cùng gởi request trong cùng 1 giây đó và đặc biệt, chúng gởi request đến cùng một địa chỉ lặp đi lặp lại liên tục như: http://www.abc.com/ trong một khoảng thời gian.

Những thông tin trên có vẻ rất bình thường nhưng đó là một bức ảnh mẫu để so sánh và để đặt ra những câu hỏi giúp cho việc phân tích, ví dụ:

a. Tại sao một IP thuộc Việt Nam mà lại dùng bằng điện thoại Android có ấn định địa phương là Canada?

b. Tại sao một IP như trên lại có User-Agent khác có ấn định địa phương là từ Đan Mạch gởi nhiều request cùng một lúc đến cùng một địa chỉ URL?

c. Tại sao những HTTP requests kia có cùng những nhóm "length" y hệt nhau và lặp đi lặp lại?

d. Tại sao chúng có cùng giá trị Referer, thậm chí Referer ấy không tồn tại?

e. Có bao nhiêu requests xảy ra trong một giây, một phút, 5 phút đi cùng một IP có cùng một User-Agent?

f. Có bao nhiêu User-Agents khác nhau đi từ một IP trong một khoản thời gian nào đó?

g. Liệu những IP tấn công kia có phải là IP của một proxy có nhiều người dùng chung hay không?

v....v....v....

Nói chung, càng nhiều câu được đặt ra và trả lời càng giúp cung cấp các thông tin để hình thành những điểm đặc thù của dạng tấn công. Từ đó mới có thể hình thành biện pháp cản lọc.

1. Cản lọc trên tầng IP:
Là những cản lọc thuần tuý mang tính chất thuộc về tầng IP thay vì những "string" và "text" thấy được ở tầng application (sau khi các packets đã gom lại hoàn chỉnh). Ví dụ, bạn thống kê được có 1 triệu requests đánh tới "index.php" có mấy chục User-Agents khác nhau và những requests này thuộc dạng ACK-PSH và có chiều dài chung là 488, 502, 515, 576, 590 (chẳng hạn). Trong khi đó, các requests (được xem là hợp lệ và sạch sẽ) của người dùng bình thường có chiều dài khác. Bạn có thể có hai chọn lựa:

1.1 Cản cụ thể các packets ACK-PSH có chiều dài như trên vì bạn (biết) rằng người dùng đến trang web của bạn không có mấy ai xài đổ địa phương là Canada, Đan Mạch, Belarus...v.v.v.. Chọn lựa này có thể cản nhầm một số người nhưng trong tình trạng bị đập nặng nề, đó là một chọn lựa nhằm cứu vãn số người dùng còn lại.

1.2 Cản tổng quát dựa trên số lần truy cập trong 1 giây (hoặc một phút, hoặc một khoản thời gian nào đó). Lý là người dùng bình thường chẳng có ai liên tục truy cập hàng chục lần đến trang chủ trong mỗi giây hoặc vài trăm lần đến một hoặc nhiều URL trong một phút. Chẳng có ai có thể đọc nhanh như thế.

2, Cản lọc trên tầng application:
Là những cản lọc cụ thể và chính xác những "string" và "text" thấy được trên logs của các web server. Ví dụ, bạn thống kê được có 1 triệu requests đánh tới "index.php" có mấy chục User-Agents khác nhau và bạn biết rằng những User-Agents ấy trước giờ ít xuất hiện vì không có mấy ai xài đổ địa phương là Canada, Đan Mạch, Belarus...v.v.v.. Bạn cũng có hai chọn lựa:

2.1 Cản cụ thể các User-Agents lạ như đã thống kê. Chọn lựa này có thể cản nhầm một số người nhưng trong tình trạng bị đập nặng nề, đó là một chọn lựa nhằm cứu vãn số người dùng còn lại. Ngày nay, biện pháp cản lọc trên tầng application có vô số các công cụ, tiên ích, plugins, modules...v..v... giúp cho việc này.

2.2 Cản tổng quát dựa trên số lần truy cập trong 1 giây (hoặc một phút, hoặc một khoản thời gian nào đó), y hệt với nguyên tắc phần 1.2 ở trên.

Conmale

DDoS và nguyên tắc chống chọi

Tóm tắt những điểm tối quan trọng trong việc chống chọi với DDoS (distributed denial of service attack) cho những ai quan tâm.

- DDoS có nhiều dạng, nhiều biến thái tấn công nhưng tựu trung có một mục đích: làm người dùng không thể sử dụng được dịch vụ.

- DDoS có hai dạng chính:

1) làm ngập băng thông khiến cho người dùng không thể truy cập dịch vụ.

2) làm cho dịch vụ hoàn toàn tê liệt vì hết tài nguyên khiến cho người dùng không thể truy cập dịch vụ.

Chống đỡ hai dạng trên đều đòi hỏi gia tăng tài nguyên (băng thông, CPU, diskspace, memory). Tài nguyên càng phát tán rộng ra nhiều network càng tốt.

- Giảm thiểu tác hại của DDoS có hai hướng chính:

1) Giảm thiểu bằng cách cản lọc những đặc điểm cụ thể.

2) Giảm thiểu bằng cách cản lọc theo ấn định số lần truy cập trong một khoản thời gian (nếu không tìm ra được đặc điểm cụ thể).

- Giảm thiểu bằng cách cản lọc những đặc điểm cụ thể dựa trên những thông tin lấy từ logs (tổng quát về IP, user-agents, số lần truy cập trong một khoảng thời gian nào đó) hoặc từ packet capturing bằng tcpdump hoặc wireshark (chi tiết tính chất trong các packet header và payload). Làm việc này đòi hỏi am hiểu đặc tính của log và tính chất của các gói tin.

- Giảm thiểu bằng cách cản lọc theo ấn định số lần truy cập trong một khoản thời gian dựa trên kết quả phân tích số lần truy cập đi từ một IP trong một khoảng thời gian. Làm việc này đòi hỏi am hiểu đặc tính của log.

Bốn điểm cần lưu ý:

I. Cản trên tầng IP cho những đặc điểm cụ thể trên tầng IP (ví dụ: iptables). Cản trên tầng application cho những đặc điểm trên tầng application (ví dụ: mod_security). Tránh đừng cản lọc những thứ thuộc về tầng application trên tầng IP và ngược lại, tránh đừng cản lọc những thứ thuộc tầng IP trên tầng application vì chúng không hiệu suất.

II. Nếu blackhole (/dev/null) được ngay trên router thì thực hiện ngay thay vì cản lọc trên firewall.

III. Cản lọc không dừng lại ở MỖI TẦNG mà ở trên TẤT CẢ CÁC TẦNG GIAO THỨC bất cứ nơi đâu có thể được, thậm chí phối hợp giữa các tầng.

IV. Tính hiệu suất, gọn nhẹ là chìa khoá để bảo tồn tài nguyên.

Conmale

Vui lòng không thảo luận về MMO tại đây và diễn đàn này

Trân trọng,

totden wrote:

1. Bác thu thập từ ~1.500 từ tiếng việt ở đâu vậy? Sao ko lấy từ từ điển ra. Mình thấy dự án Free Vietnamese Dictionary cũng làm được bộ >30k từ, nếu tính từ đơn chắc cũng >5k
2. Cách bác lấy 2 từ kiểu j. Mình thấy trong xử lý ngôn ngữ tự nhiên thì việc tách từ đạt hiệu quả khá cao, >90% thì phải. Vậy có thể lấy các đoạn văn bản trên các báo,... rồi tách từ để lấy cụm 2 từ.

Các từ đơn lúc đầu tôi lấy từ dự án ViSpell http://vispell.googlecode.com). Sau đó tôi thu thập khoảng vài trăm bài báo từ Vnexpress rồi hợp lại thành 1 large text file, sau đó tự động matching 1556 từ này với nội dung trong large text file trên, các từ nào có trong large text file mà không có trong 1556 từ ban đầu tôi sẽ đưa vào trong danh sách 1556 từ.

Còn vấn đề lấy 2 từ, tôi không làm chuyện phức tạp, khi mà số tổ hợp 2 từ thấp, 3 từ vẫn thấp thì tôi chọn cách vét cạn không gian tổ hợp thay vì ngồi làm chuyện "phức tạp" vì việc dùng password dict đã giảm tỷ lệ thành công xuống khi thực hiện crack password rồi, làm chuyện "phức tạp" đương nhiên sẽ làm giảm tỷ lệ đó xuống một mức nữa không đáng có, trong khi computing power cỡ con core i3 tôi có đã đủ giải quyết trọn bộ không gian tổ hợp 2, 3 từ

Dictionary Attack và Brute Force attack - Vietnamese Password Dictionary Attack

Bài viết này sẽ nói về một tham vọng nho nhỏ là tổ hợp bộ từ điển password tiếng Việt. Cũng như nói sơ qua về Password Dictionary Attack với Password Brute Force Attack

Dictionary Attack và Brute Force attack

Đầu tiên cần có chút phân biệt nho nhỏ giữa 2 kiểu tấn công nhắm vào mật khẩu này. Nhưng trước nhất chúng ta nên nói sơ qua về password ( tôi không dùng từ Mật Khẩu vì từ này sai tét bét ).

Password mà tôi nói tới ở đây thường là một chuỗi tổ hợp ký tự có độ dài giới hạn bao gồm tất cả các ký tự mà bảng mã ký tự lớn nhất hành tinh hiện nay có thể đánh mã số - bảng mã Unicode. Sức mạnh của password nằm ở 2 điểm

- Chỉ một hoặc một số ít người biết nội dung ( tổ hợp ký tự được dùng ) làm password. Điều này đem tới thứ lợi ích đầu tiên là “bí mật”
- Nếu một người không biết nội dung của password thì buộc phải dí dao vào cổ thằng có password để đòi hoặc buộc sẽ phải đoán. Tức là phải tốn công sức ở một mức độ nào đó để lấy được Password. Điều này đem đến lợi ích thứ 2 “bảo mật”

Theo như điểm thứ 2 ở trên thì chúng ta hình thành được 2 con đường để phá vỡ lợi ích “bảo mật” ( bảo vệ bí mật ) của password

- Dí dao lấy password từ thằng có password. Dĩ nhiên là tôi nói đùa đấy, đây là cách nói cụ thể cho hướng lấy password từ chính người có nó, thông qua tấn công APT, nghe lén, keylogging… Tuy nhiên nếu như người có password là người không dễ để có thể lấy được password, ví dụ: không thể dí dao vào cổ Tổng Thống Mỹ để lấy password ( bạn sẽ bị phơ ngay 1 viên kẹo ), hoặc attack vào máy tính của một chuyên gia bảo mật am tường ( kiểu như lão mrro, gamma95 ) bạn sẽ bị phản “damage” nếu thử attack họ ( ví dụ stl chơi dại khi đụng vào anh TQN )
- Đoán mò password. Đúng bạn phải “đoán” và “mò” password
Tôi sẽ nói rõ hơn về vụ “đoán” và “mò” password này. Đây là 2 động từ tiếng Việt của 2 phương pháp kỹ thuật tấn công password dưới đây
- Đoán: Dictionary Attack
- Mò: Brute Force Attack

Brute Force Attack:

Tôi sẽ nói về cái này trước. Đây là kiểu tấn công mà bạn sẽ “mò” tất cả các tổ hợp ký tự có thể là password cho đến khi có một tổ hợp ký tự trùng khớp với tổ hợp ký tự được dùng làm password. Phương pháp tấn công này giúp ta thấy rõ được điểm mạnh cốt lõi của password.

Password là bí mật, không ai biết được nó có độ dài bao nhiêu và tổ hợp từ những ký tự gì ngoài người sở hữu nó

Người tấn công về mặt lý thuyết buộc phải thử “tất cả” các trường hợp có thể có của tổ hợp ký tự cho đến khi tìm ra tổ hợp đúng. Chính cái “tất cả” này làm cho password an toàn. Do năng lực tính toán là có “giới hạn” nên việc “mò” hết “tất cả” các tổ hợp sẽ tốn 1 thứ là “thời gian”. Nếu một password có thể đẩy việc mò ra nó tới một thời gian xa xôi trong tương lai ( tính bằng ngàn năm ) thì coi như nó thắng người tấn công vì người đó không thể chờ tới lúc mò ra được password.

Để đẩy việc “mò” password tới một thời gian xa xôi trong tương lai người ta có 2 cách, dựa trên 2 thành tố cơ bản tạo thành password: độ dài password và độ dài bảng ký tự được sử dụng.

Ví dụ:

Với một bảng ký tự như sau:
Code:

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789

ta có tất cả 65 ký tự

Ta tạo thành một mật khẩu: Hvaonline2013

Có độ dài là 13 ký tự

Vậy tôi có 369,720,589,101,871,000,000,000 tổ hợp
Giả sử tôi có một máy tính với khả năng tạo 80,000,000 tổ hợp ký tự trên 1 giây. Thì tôi cần
Code:

4,621,507,363,773,390 second (hoặc)
77,025,122,729,557 minutes (hoặc)
1,283,752,045,493 hours (hoặc)
53,489,668,562 days (hoặc)
1,782,988,952 months (hoặc)
148,582,413 years

Rất nhiều thiên niên kỷ trôi qua để làm công việc này. Do đó password này đạt được thứ lợi ích là “bảo mật”

( Hãy nhớ các con số phía trên tôi tính, để lát nữa bạn thấy một điểm yếu khác của password khiến password có thể bị phá vỡ nhanh hơn trên kia. Bên cạnh đó tôi có viết một bài về cách tính số tổ hợp ký tự tại đây http://xnohat.blogspot.com/2011/06/cach-tinh-so-to-hop-mat-khau-can-phai.html )

Tóm lại, với kiểu tấn công Brute force password tôi sẽ chết già trước khi mò các mật khẩu có độ dài lớn. Và các password sẽ an toàn trước tôi.

Tuy nhiên đời không như là mơ !

Dictionary Attack:

Vấn đề của Brute Force Attack là việc “mò” hết “tất cả” các tổ hợp làm tôi “mất thời gian”. Thể nên kỹ thuật Dictionary Attack ra đời. Kỹ thuật này thay hành động “mò” vô tội vạ bằng hành động “đoán” có tính toán.
Bạn có thể hiểu sơ sơ về phương thức tấn công này dựa vào cái tên của chính nó “Dictionary” tức “từ điển”, hay nói ngắn gọn bạn có một danh sách các tổ hợp ký tự có “khả năng cao” là password rồi mang dò coi trong cái danh sách đó có cái nào là password không.

Từ khóa trong đoạn trên là “khả năng”. Chính xác thứ làm cho phương pháp tấn công này trở nên yếu ớt trước password là “khả năng” password nằm trong cái danh sách ( từ điển ) của bạn là “giới hạn”. Vì nếu bạn có một danh sách quá dài, “thời gian” để bạn dò hết danh sách đó cũng sẽ khiến bạn thua cái password nếu nó đẩy bạn tới một giới hạn thời gian xa xôi trong tương lai. Do đó việc cần làm ở đây là “đoán” về “cấu trúc” của password rồi từ đó hình thành một từ điển “ngắn gọn hơn” và có “khả năng cao hơn”. Ví dụ một số điểm có thể được coi là thành phần cấu trúc của password:

- Password có thể hình thành từ một cụm từ có nghĩa trong một ngôn ngữ cụ thể: Password có thể là một cụm từ tiếng Việt chẳng hạn, ví dụ: phucdeptrai
- Password có thể được đặt theo một thói quen: kiểu như 123456789, 987654321, 123456, 1234567, 12345678, matkhau, password, admin …
- Thành phần của password được hình thành theo một khuôn mẫu: ví dụ Xuanthanh2503
Bằng việc dựa vào các khuôn mẫu nêu trên kèm với việc điều tra tính cách cá nhân người tạo Password, tôi có thể giới hạn danh sách password xuống thành một cái list khá gọn hơn. Ví dụ tôi nhận định một cái list tương đối phù hợp cho người Việt Nam sẽ bao gồm:

- Ngôn ngữ: tiếng Việt
- Tổ hợp từ có nghĩa
- Số từ trong mật khẩu: 2 hoặc 3
- Theo như tôi thống kê từ khá nhiều DB tôi tiếp cận được ( trong qua trình nghiên cứu, các DB này do các hacker vứt bừa bãi trên các diễn đàn mạng, tôi down về phân tích ). Các password được coi là “mạnh” ở Việt Nam thường có dạng:
+ Cụm 2-3 tự tiếng Việt có nghĩa
+ Chữ cái đầu viết hoa – 2 từ tiếng Việt có nghĩa – từ 3 đến 4 chữ số
+ Ký tự @#$! - Chữ cái đầu viết hoa – 2 từ tiếng Việt có nghĩa – từ 3 đến 4 chữ số - Ký tự @#$!

Với sự giới hạn lại trong các khuôn mẫu tôi cho rằng ( khá chủ quan ) khả năng password nằm trong danh sách của tôi đối với trường hợp người Việt tạo password là cao

Một số tính toán:

Tôi có một danh sách 1556 từ tiếng Việt đơn

Password dự trù theo dạng Cụm 2-3 “từ” tiếng Việt có nghĩa thì tôi có tổng cộng

3,767,287,616 tổ hợp “từ”

Bạn sẽ thấy sự khác biệt ở đây là tôi có 3,767,287,616 tổ hợp “từ” chứ không phải tổ hợp “ký tự”, mà từ thì có thể dài tới 21 ký tự trong trường hợp password có 3 chữ “nghieng” ( từ dài nhất trong tiếng Việt )
Cũng với máy tính với sức tính toán như trên chúng ta sẽ cần:

Code:

Alphabe Table 1,556 (Word, no number)
Password length 3
Total combination 3,767,287,616
Computing Power 80,000,000 hash/s
Time 47 second (or)
1 minutes (or)
0 hours (or)
0 days (or)
0 months (or)
0 years

Chính xác là còn khoảng 47 giây để crack mật khẩu dài 21 kí tự ! ( khoảng 1 ngày cho 28 kí tự )
Điều cốt lõi ở đây là số tổ hợp “từ” sẽ ít hơn số tổ hợp “ký tự” do không gian tổ hợp bị thu hẹp xuống rất nhiều lần. Với một password 3 từ thì nó cũng không khác mấy khi so với một password 3 ký tự trong trường hợp này

Vietnamese Password Dictionary (vipasswordict):

Vấn đề khi thi triển kỹ thuật tấn công Dictionary Attack là ở Việt Nam chưa có một file từ điển nào được tổ hợp cho mục đích trên. Do đó tôi đang start một dự án nho nhỏ về tạo một vài bộ từ điển password dict cho ngôn ngữ Tiếng Việt. Sơ bộ thì sẽ có các bộ password dict:

- 1556 Từ tiếng Việt đơn ( đã hoàn tất ): bộ từ này là bộ căn bản dùng để tổ hợp các bộ khác, là 1556 từ tiếng Việt không dấu và đơn nhất
- Tổ hợp 2 từ tiếng Việt ( đã hoàn tất )
- Tổ hợp 3 từ tiếng Việt ( đã hoàn tất ): sau khi áp dụng grid computing thì hoàn tất mớ này trong 3 ngày chạy liên tục
- Tổ hợp 2 từ tiếng Việt – padding thêm 4 kí tự số ( 0000-9999) ( đã hoàn tất ): vì theo như tôi thống kê từ khá nhiều DB tôi tiếp cận được ( trong qua trình nghiên cứu, các DB này do các hacker vứt bừa bãi trên các diễn đàn mạng, tôi down về phân tích ). Các password được coi là “mạnh” ở Việt Nam thường có dạng “Xuanthanh2503”
- Tổ hợp 3 từ tiếng Việt – kí tự đầu viết hoa – padding thêm 4 kí tự số ( 0000-9999) ( chưa làm )

Hiện tôi đã có tạo một project trên GitHub và sẽ dần dần release từng bộ từ điển tôi tổ hợp xong lên đây

https://github.com/xnohat/vipasswordict

xnohat

Về vụ sniff dữ liệu của Zalo và Wechat thì đã test rồi nghen. Hai thằng hành động khá khác nhau

Wechat thì submit contact list của user lên server ngay sau khi mở App

Code:

POST /cgi-bin/micromsg-bin/uploadmcontact HTTP/1.1
Accept: */*
User-Agent: Mozilla/4.0
Content-Type: application/x-www-form-urlencoded
Host: hkshort.weixin.qq.com
Content-Length: 1032
....

Zalo thì down contact list đã submit trước đó theo JSON format về ngay sau khi mở App ( mền chưa chưa chụp được packet đoạn submit contact list lên server, sẽ gửi lên sau )

Code:

{"error_code":0,"error_message":"Successful.","data":[{"userId":102282593,"username":"t_m7e07m90f0","displayName":"Lan XXX","avatar":"http://avatar.talk.zdn.vn/d/b/1/2/0/75/ea334590xxxx094f346084a16.jpg","gender":1,"dob":50xxx00,"phoneNumber":"+849xxxxxx" ...

Hề hề nhờ Zalo, Wechat không dùng HTTPS connection nên có vẻ mền có thể lấy khá nhiều contact của user một cách dễ dàng :v