banner

[Rule] Rules  [Home] Main Forum  [Portal] Portal  
[Members] Member Listing  [Statistics] Statistics  [Search] Search  [Reading Room] Reading Room 
[Register] Register  
[Login] Loginhttp  | https  ]
 
Messages posted by: huydd  XML
Profile for huydd Messages posted by huydd [ number of posts not being displayed on this page: 0 ]
 
Theo mình biết và đã test thử thì kể cả các Webserver dùng Public Cert nhưng có sử dụng OpenSSL (phiên bản từ 1.0.1 đến 1.0.1f) vẫn bị ảnh hưởng của CVE này.
HVA dùng OpenSSL nhánh 0.9.8 lại không bị ảnh hưởng smilie

Các bạn có thể test website của mình thông qua công cụ online tại http://filippo.io/Heartbleed
Nếu vẫn muốn dùng wireshark cho "thân quen" thì bạn dùng trên máy ảo nhé. Đây là cách đơn giản nhất không phải cấu hình thêm driver hay các thành phần gì khác

Cách này tôi thường dùng khi phân tích các bản tin trên lớp với USB 3G

conmale wrote:

xuanphongdocco wrote:

myquartz wrote:
kết nối https chỉ có client gà không biết mới dính giả mạo thôi. Trình duyệt sẽ cảnh báo ngay rằng cái certificate đó là không hợp lệ (untrusted), nếu client vẫn nhắm mắt "accept and add exception" thì chết là phải.
Cái này chả khác gì việc thằng lừa đảo nó đưa tiền giả cho người bán hàng, máy đếm tiền báo động đây là tiền giả nhưng người bán hàng vẫn cố tình chấp nhận tiền giả và đưa hàng cho nó, rồi lại chửi là "vì dùng tiền nên bị lừa đảo". 


Cái này có nhầm lẫn gì không? Người bị tấn công sẽ sử dụng cetificate xịn -> browser có báo gì đâu. Anh chàng attacker sniff được cái certificate đó rồi tái tạo lại, vậy là browser sẽ thông báo "accept and add exception" cho kẻ tấn công chứ?

Xin hãy đóng góp nếu tôi sai. 


Attacker tái tạo lại cái certificate nào? 


Chính xác như bạn myquartz nói. Thường thì các trình duyệt mới sẽ cảnh báo khi có certificate không hợp lệ, nhưng phần lớn người sử dụng rất ít để ý cái cảnh báo này. Hơn nữa một số website chưa có đủ tiền mua cert xịn dùng self sign certificate cũng bị cảnh báo untrusted.

Bạn nào dùng IE8 vào địa chỉ https://www.gmail.com/ xem, cũng cảnh báo untrusted vì certificate của google đăng ký cho mail.google.com chứ không phải www.gmail.com . Vài lần như thế này thì phản xạ accept khi có cảnh báo của người dùng cũng là dễ hiểu
Mỗi người có một hướng, một việc bạn à. Thời gian và công việc của tôi không cho phép tôi làm được như bạn nên tôi chỉ có thể thử hành vi và phòng tránh theo kinh nghiệm + khuyến nghị. Việc chạy tool xác định hành vi là một phần công việc chứ không phải chạy chơi, và mục tiêu DOS mà bị khai thác cũng đủ để chết và mất nghiệp rồi bạn ạ.
Tất nhiên tôi luôn trân trọng các kết quả mà các bạn dày công nghiên cứu, đọc dịch và tìm tòi ra smilie
Cả bài này nữa này, HVA luôn smilie
/hvaonline/posts/list/0/41627.html#259621

H3x4 wrote:
Mình có phân tích về bug này và cách để trigger nó lên, đồng thời 1 số hướng tham khảo để biến thành exploit.
http://bkitsec.vn/?p=389
PS: hiện tại trên thế giới vẫn chưa có reliable exploit nào, rất nhiều người đang tìm cách khai thác nó nhưng việc đó có vẻ như rất khó!
 


Có vẻ như có virus ăn theo lỗi này tự động dò cổng 3389 mở trên Internet và shutdown server cho vui rồi, ví dụ đây này /hvaonline/posts/list/41690.html#259620
Tôi đã thử khai thác với Metasploit (update revision 16005 ngày 22/03/2012 đã có MS12-020 auxiliary/dos/windows/rdp/ms12_020_maxchannelids) và hạ thành công windows 7 và win2k3 cài RDP không bật secure

doanpv22 wrote:

xuanphongdocco wrote:

E đang sử dụng phần mềm PRTG để giám sát băng thông, đang dùng Nettool để theo dõi gói tin và đã bắt được khi bị remote. Tuy nhiên mỗi lần bị và em bắt gói tin thì nó có hàng mấy chục địa chỉ IP connect vào PC đấy theo port 3389 cơ, em ko thể chặn xuể đc, e check thì toàn IP bên USA và Ba Lan...
Em cũng nghỉ định kiếm cái HUB để cắm vào Gateway để bắt goi tin bằng Wireshark nhưng giờ kô kiếm đc HUB nên đành chịu! Bác có tool nào bắt được chi tiết máy nào kô? và có thể support cho em qua về nó dc kô? huhu
Sếp mắng em nhiều quá! Em xin chân thành cảm ơn các bác đã góp ý! 


1. Nếu nhiều gói tin từ ngoài gửi đến 3389 thì bạn chặn cổng đó trên firewall hoặc gateway router. nếu không có firewall thì dùng iptables cũng được

2. Nếu bạn muốn bắt gói tin để inspect thì có thể cấu hình Mornitor port hoặc netflow để xuất bản tin về một máy phân tích và dùng wireshark để xem mà không cần phải dùng hub

simmy wrote:

Có thể tìm hiểu fail2ban tại đường dẫn: http://www.fail2ban.org
Mình đã thử dùng fail2ban với asterisk và FTP. Nói chung là dùng khá tốt, kết hợp với email tự động nửa, nên bạn có thể chủ động warning cho bạn khi có ai đó cố gắng brute force vào hệ thống. Đương nhiên, để dùng fail2ban thì bạn phải có quyền cài đặt nó lên server chứa dịch vụ cần kiểm tra. 


Dùng fail2ban hay tất cả các tool theo kiểu scan log rồi đưa ra action đều chiếm dụng memory và cpu cao, đặc biệt là nếu viết script không tốt và file log có kích thước quá lớn chưa được cắt
Theo tôi thì bạn chủ topic nên tìm hiểu kỹ hơn về các service mình triển khai để tối ưu cấu hình. Dovecot thì tôi không rõ nhưng ssh có thể giới hạn số lần thử sai qua tham số MaxAuthTries trong /etc/sshd_config

Tất nhiên để làm được bạn phải có quyền root trên server
Hiện nay với ettercap, arpspoof và vài thủ thuật đơn giản, người ta hoàn toàn có thể nghe trộm được các thông tin trao đổi của một máy trong LAN. Thậm chí cả thông tin qua https cũng bị sniff thông qua Certificate giả mạo. Người dùng thì đa phần luôn nghĩ https là tuyệt đối an toàn và phần lớn không phát hiện ra hiện tượng bị nghe trộm trên mạng. Hạ tầng mạng thì không phải ở đâu cũng có thể triển khai cơ chế chống arpspoofing được. Vậy xin hỏi các ACE có kinh nghiệm triển khai ứng dụng web có cách nào phát hiện ra hiện tượng giả mạo này từ phía server không?

Hiện hvaonline cũng chưa phát hiện được hiện tượng giả mạo này nên ai đó login vào hvaonline thậm chí dùng https vẫn có khả năng bị nghe trộm mật khẩu nếu không cẩn thận

Dưới đây là thông tin Cert xịn của HVA và Cert giả mạo do ettercap tự tạo ra, các bác tìm thử điểm khác nhau, đâu là hàng chính hãng, đâu là fake nhé smilie
1.



2.

TQN wrote:
Bạn huydd đang làm trong lãnh vực nào vậy, xem các topic create và post của bạn, tôi hơi có dấu ? Shellcode này tương đối phức tạp, bạn muốn nắn gân, thử sức anh em phải không ?
Sếp bạn là ai, cơ quan nào, tại sao lại có 2 file tiếng Việt này gởi tới đích danh như vậy ?
Thời điểm cậu post và up hai con .rtf này lên, tui có nhận được mail này, có liên hệ gì không, muốn thử xem Thằng Cu Anh này có bó tay không phải không ?
 


Bác TQN đa nghi quá nhỉ? Chắc với kỹ năng của bác tìm ra huydd làm ở đâu có khó gì vì thông tin về Ip truy nhập hoặc thông tin cá nhân của tôi trên Internet muốn tìm thì chỉ vài phút là ra hết cả anh em vợ con (khéo cả bồ nữa ấy chứ) smilie

Tôi làm về đào tạo, chuyên môn chính là về mạng nhưng cũng có liên qua đến security chút đỉnh. Các bài viết của bác và các anh trên HVA thường là những ví dụ rất hữu ích cho tôi khi đi dạy. Sếp của tôi trong case này là một giáo sư về viễn thông nhưng lại mù tịt về CNTT hix (vẫn dùng XP với Office 2003 ko patch), cụ sắp về hưu rồi nên lười update công nghệ quá.

Làm mất công của anh em nhưng quả thật các bài viết của bác rất hữu ích cho những người muốn nghiên cứu về các kỹ thuật trong RE. Cảm ơn các bác nhiều

Bác TQN ơi, tôi không máy mó gì đâu ngoại trừ đổi cái tên tiếng Việt có dấu thành không dấu rồi zip nó lại cho gọn
Thú thực theo dõi làm thử cùng các bác đến đoạn XOR mấy phát là bó tay ngồi xem rồi, không dám phát biểu tiếp
Mấu chốt vấn đề là javascript và cookie authentication. Bạn tìm hiểu thêm nhé

<input type="submit" value="submit" onclick=javascript:document.cookie='level10_authorized=yes';>


AkamPro wrote:

........
- Chống DDos dạng nào thì mình không biết chỉ biết là máy bị truy cập quá nhiều làm nghẽn mạch: Ví dụ bị tấn công vào 1 port nào đó trên máy mình ví dụ port 80, 8080, 443,... cỏ thể mở 1 trăm 1 triệu connection vào cái port nào đó lúc đó server không kịp phản hồi lại => cái này chắt gọi là DDos quá.
.......
 


Nếu mà bạn muốn chống tất cả các loại DoS thì liên hệ với các bạn viết phần mềm trên Cisco Guard DoS, Arbor Peakflow SP, Juniper SSG... Mà ngay cả sale của các bạn này cũng chẳng dám khẳng định là chống DDoS được tuyệt đối
Theo như ý mình hiểu thì bạn muốn tìm giải pháp phần mềm để chống tấn công từ chối dịch vụ cho Web Server của bạn thông qua việc chặn IP. Vấn đề này theo mình nhớ đã được thảo luận trong một thớt trước đây trên HVA. Đại khái giải pháp là count connection theo IP trên server và kích hoạt ratelimit hoặc block trên gateway/firewall

Bạn tìm lại xem
Phân tích cả hai em này qua FileInsight thì thấy chúng có chung một đoạn 3737373737373737}}}} và kể từ đoạn này trở về sau thì mã hex gần như giống nhau. Shellcode entry point ở đây chăng các bác?

Cái thứ nhất



Cái thứ hai


Message mà mình chờ đợi nhất reply trong thớt này là của bác TQN thế mà lại bị ẩn đi là sao nhỉ?
Nhờ các cao thủ thảo luận giúp. Máy của Mr Sếp mình thì mình cài lại cho chắc rồi

À, thêm một thông tin nữa cho các bác RE đỡ mất công là hai file DOC trên chỉ kích hoạt được trên Windows XP với Office 2003 thôi còn với Office 2007 thử trên Virtual Box thì không thấy gửi gói tin nào ra ngoài hết

Thanks
Hôm rồi sếp có cái file doc nhận được qua email nhưng mở ra bị lỗi nên forward cho mình check. Thấy nghi nghi nên cũng cần thận kiểm tra thì Microsoft Security Essential không detect được gì, McAfee chạy trên máy cũng không phản ứng. Tuy nhiên check trên virus total thì ra kết quả là 10/43 với exploit code là CVE-2010-3333 (một số bạn nổi tiếng như KAV, McAfee, Trend... thì chẳng thèm nhận mặt, hay thật)
Theo mình hiểu thì CVE-2010-3333 là lỗi tràn bộ đệm khi bị khai thác thì nó thực thi mã trực tiếp connect đến một máy remote để tạo backdoor. Đây là một mã lỗi khá cũ sao các AV hiện tại lại không nhận ra. Vì vậy mình thử mở file word ở trên trong Virtual Box và dùng Wireshark để bắt gói tin thì lại thấy kết quả như dưới đây



Có vẻ như hoạt động không giống với CVE-2010-3333 thông thường vì mình cũng đã thử metasploid với CVE này trước đây để test rồi. Xem thông tin trên wireshark thì chỉ biết nó connect đến billgate2012.xicp.net. Phần còn lại nó chơi https thì mình bó tay, không hiểu nó làm gì tiếp
Kiểm tra tasklist sau khi mở file trên thì chỉ thấy có phát sinh iexplore.exe với thông số như sau

IEXPLORE.EXE 1736 Console 0 1,588 K
WINWORD.EXE 1704 Console 0 8,652 K



Phán đoán của mình là nó dùng IEXPLORE.EXE để connect đến server qua https nhưng nó gửi trao đổi những gì thì chịu. Chỉ chắc chắn là máy sếp đã dính em này vì mình có cài wireshark lên máy sếp thử thì thấy các bản tin gửi đến billgate2012 rất đều đặn, chỉ kill IEXPLORE.EXE đi mới hết

Mình không chuyên về RE và RCE lắm nên đọc qua hex code của mấy file này chẳng hiểu gì, mà hình như nó mã hoá hay sao đó nên cũng không thu được nhiều thông tin như các ví dụ của bác TQN có trình bày. Vậy nhờ các bác RE cao tay ở đây giúp dùm xem mấy em này bản chất nó làm gì, có cài cắm thêm gì vào máy không để mình hỗ trợ sếp trong việc removal

Các file này mình tạm upload tại link: removed.

Cảm ơn các ACE nhiều

conmale edited: remove link đến malware.

quanta wrote:

huydd wrote:

...
Còn trong lúc trình bày mà học viên có hỏi cách làm thì cũng nên chỉ cho họ link đề vào HAV (để đọc bài của bác conmale rằng không được phổ biến bừa bãi smilie

huydd wrote:

...
cũng giống như các bác ở HAV và MAIT trước đây có đợt rất hào hứng với vụ demo crack Wifi WEP key để chứng minh dùng wifi không an toàn.
 

Mình chỉ kéo áo nhẹ một cái: tên diễn đàn là HVA. 

Sorry bác quanta, đang định sửa thì đã bị bác kéo rồi smilie
Các bạn thích chỉ trích thường không chịu đọc kỹ để hiểu bản chất vấn đề, cứ thấy hội nghị là lao vào ném đá, bản chất đó thì chỉ sợ mãi không khá lên được.
Như tôi đã nói ở trên, đây là nội dung tôi dự định đưa vào đợt tập huấn cho cán bộ về các nguy cơ bảo mật trên mạng lưới. Và mục đích của con bot này cũng chỉ là demo về nguy cơ khi một người dùng nhận được một file từ lạ. Việc che dấu ở trên tất nhiên chỉ nhằm qua được kiểm soát ban đầu khi người dùng nhận file về, còn nó hoạt động được trên hệ thống hay không thì đúng như bác xnohat nói, còn phụ thuộc vào nhiều thứ, ví dụ đơn giản như bật firewall mặc định của windows lên là con bot của tôi ngọng.
Ở đây không phải vấn đề tự tin hay không vì với kinh nghiệm hơn chục năm giảng dạy thì vấn đề tuỳ biến lúc giảng không quá khó. Cái tôi mong muốn là đem lại một cái nhìn mới, trực quan một chút về vấn đề mình nói, cũng giống như các bác ở HVA và MAIT trước đây có đợt rất hào hứng với vụ demo crack Wifi WEP key để chứng minh dùng wifi không an toàn.

Thân
This post is set hidden by a moderator because it may be violating forum's guideline or it needs modification before setting visible to members.
Solved: Vấn đề đã được xử lý. Cảm ơn các bác đã comment
Không ngờ có những công cụ crypt được bot mà qua mặt được cả những anh như kaspersky hay bitdefendef.

Đính chính lại với các bác là em zombie này không phải là tôi viết mà là đoạn code về bot khá phổ biến được chỉnh sửa lại, chính vì thế các trình AV mới phát hiện ra ngay các dấu hiệu của nó. Mục tiêu ở đây là cho người học thấy được nguy cơ chứ không phải hướng dẫn cách tạo và reo rắc zombies.

@Aro: ở đây tôi muốn hỏi công cụ tức là một loại phần mềm để crypt các signatures đã biết của zombies thành một chuỗi crypted mà AV không phát hiện được. Lý thuyết để làm cái này thì có cả kho nhưng mà hiện thực hoá được nó bằng phần mềm thì tương đối mất công, tốt nhất là đi tìm tool hoặc opensource cho tiện. Còn trong lúc trình bày mà học viên có hỏi cách làm thì cũng nên chỉ cho họ link đề vào HVA (để đọc bài của bác conmale rằng không được phổ biến bừa bãi smilie )
Cái này không phải chương trình đại học bác conmale ạ, đây là chuỗi bài giảng về an ninh thông tin tôi đang soạn để tổ chức tập huấn cho các cán bộ quản trị mạng trong ngành. Tôi muốn đưa vào các phần demo để anh chị em có thể có cái nhìn trực quan hơn. Thực ra việc ẩn botnet không quá quan trọng đối với demo nhưng ở đây tôi muốn chứng minh là ngay cả khi một máy tính được trang bị một phần các giải pháp bảo mật nhưng nếu người sử dụng không cẩn thận thì việc trở thành nạn nhân của botnet vẫn xảy ra.

Cảm ơn các bác
Chào các bác,
Chẳng là tôi đang compile một số loại botnet để demo phục vụ cho các bài giảng của tôi. Hiện botnet đã hoạt động tốt nhưng ngặt cái bất cứ trình antivirus nào cũng phát hiện được kể cả chương trình còi lẫn chương trình hàng khủng.
Vậy xin hỏi có bác nào biết về các phần mềm encrypt và pack để đóng gói lại botnet nhằm qua mặt các chương trình antivirus thông thường hay không. Nếu biết xin cho biết tên hoặc có link qua PM nữa thì càng tốt

Xin cảm ơn các bác
Hiện tại tôi cấu hình xvnkb, khi gõ trong firefox hoặc OOo nó bị mất chữ (ví dụ gõ kiểu telex oo thì nó xoá luôn cả chữ o đầu đi) và ở console hiện thông báo lỗi như sau
WARNING **: Error converting text from IM to UTF-8: Invalid byte sequence in conversion input
Các thông số khi khởi động tôi đã đặt như sau
export LANG="en_US.UTF-8"
export LD_PRELOAD=/usr/lib/xvnkb.so.0.2.9
export XMODIFIERS="@im=xvnkb"
export GTK_IM_MODULE="xim"
export QT_IM_MODULE="xim"
export LC_CTYPE="en_US.UTF-8"

Bạn nào biết nguyên nhân tư vấn giúp với ạ
Mình đã kích hoạt rồi (thử cả SCIM và SKIM), nó hiện lên cái biểu tượng ở góc taskbar
Khi chuyển vào vùng edit và nhấn Ctrl+Space thì nó hiện lên hai lựa chọn bàn phím như mình mô tả ở trên
Bạn nào đã cài thành công bộ gõ trên Slax thì góp ý cho mình với. Cám ơn nhiều
Mình sử dụng bản Slax (www.slax.org) và tự build các component để chạy trên USB. Hiện tại thì đã cài được xvnkb chạy với đa số ứng dụng rồi. Ví dụ đang ngồi gõ trên Konquere đây. Tuy nhiên khi gõ trong openoffice thì toàn bị lỗi : Ví dụ "cộng hoà" thì nó thành "cÃộng hoà"
Mình mới dùng OOo nên cũng chưa có kinh nghiệm trong việc xử lý input và charset, ko rõ là do OOo hay do xvnkb
Còn SCIM thì mình đã thử cài cả lzm lần compile từ source nhưng không hiểu sao nó chỉ có hai cái keyboard layout english và english/european chứ không hiện thêm cái nào khác.

Rất cám ơn mọi người đã chia sẻ
Tôi đang dùng slax và cũng đang gặp lỗi tương tự, không biết chủ topic đã biết cách xử lý vấn đề này chưa nhỉ?
Thanks
 

Powered by JForum - Extended by HVAOnline
 hvaonline.net  |  hvaforum.net  |  hvazone.net  |  hvanews.net  |  vnhacker.org
1999 - 2013 © v2012|0504|218|