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: WinDak  XML
Profile for WinDak Messages posted by WinDak [ number of posts not being displayed on this page: 10 ]
 
@xnohat smilie thanks lão coi dùm phần đó.

namnx wrote:
Theo mình nghĩ thì việc xác định 2 sản phẩm này có dùng mã nguồn của nhau không bằng cách reverse 2 file APK thì khó mà chính xác được. 2 sản phẩm này đều có 2 phần là front-end (app trên smartphone) và back-end. Mình nghĩ rằng đối với những sản phẩm như Zalo và WeChat, bằng back-end sẽ nặng và phức tạp hơn nhiều so với phần front-end. Còn phần back-end được phát triển như thế nào chỉ có những người phát triển nó mới biết, người ngoài thì khó mà biết được.

Do đó chỉ có reverse 2 app này để kết luận thì hơi... thiếu chính xác.
 


Cảm ơn đóng góp của anh namnx, mục đích của mình là so sánh ứng dụng Android xem có xài source của nhau không, còn phần back-end thì chưa có ý kiến và cũng chỉ có thể phán đoán qua các gói tin chứ không thể kết luận được.

@TQN: source sau khi extract em có upload đó smilie cảm ơn nhiều nếu anh giúp đỡ, cũng sẽ thử SourceInsight xem sao.

@logichvaonline: thường thì bạn phải root máy mới chui vào dc /data/app, có thể xài các "root explorer" app hoặc adb ( xài lệnh adb pull )

Mình rất hoan nghênh và cảm ơn các bạn có đóng góp tiếp tục phân tích 2 ứng dụng này.

Gần đây có một người bạn nhờ tôi kiểm tra xem WeChat – một ứng dụng Android (Android App) của tàu khựa có liên hệ gì với Zalo sản phẩm có tính năng tương tự của Việt Nam, do hãng VNG sản xuất hay không. Chưa từng reverse Android App nên tôi cũng mày mò và tranh thủ học hỏi thêm. Bài viết này nhằm 2 mục đích:

  1. Giới thiệu và thảo luận phương pháp và một số công cụ reverse một Android App
  2. Thảo luận và so sánh WeChat và Zalo, về các mặt: mã nguồn, vấn đề bảo mật người dùng, các tính năng có thể nguy hại đến người dùng


Phần 1: Dịch ngược:

Để bắt đầu thì trong bài viết này tôi sử dụng 2 file apk sau cho 2 ứng dụng:
  • WeChat: http://dl.dropbox.com/u/11027388/WeChat_4.5.apk
  • Zalo : http://dl.dropbox.com/u/11027388/Zalo_1.0.8.apk


File APK chính là file thực thi của một ứng dụng Android, nó thực ra là một file đóng gói của ngôn ngữ Java mà hệ điều hành Android có thể đọc được và thực thi trong môi trường HDH Android.

Khi cài đặt 1 ứng dụng từ google play, file apk sẽ nằm trong thư mục /data/app trong máy ( bài tập cho bạn: làm sao lấy được nó ra khỏi máy ? )

Sau khi lấy được 2 file này, chúng ta cần một số công cụ để dịch ngược file apk thành file java ban đầu. Để làm việc này tôi sử dụng 2 công cụ:

  1. dex2jar : https://code.google.com/p/dex2jar/
  2. jd-gui : http://java.decompiler.free.fr/?q=jdgui


Công cụ (1) giúp chuyển tập tin apk thành định dạng “jar” (Java Archive) một file đóng gói khác của java.

Code:
dex2jar.sh Zalo_1.0.8.apk
ls
Zalo_1.0.8.jar


Tuy nhiên trong file .jar chỉ toàn là java bytescode gồm các mã lệnh dưới dạng binary của java, rất khó để đọc vì vậy tôi đã sử dụng tiếp chương trình (2).
Code:
./jd-gui


Kết quả:



Mã nguồn rất tuyệt và dễ đọc hơn java bytecode gấp 10000 lần smilie

Tuy nhiên ta còn một vấn đề nhỏ. Trong quá trình đóng gói ứng dụng, 1 số thông tin của các hàm, biến v.v... đã bị xóa khỏi ứng dụng, vì mục đích obfuscation (làm cho khó đọc). Chính vì thế ta thấy rất nhiều các file a,b,c,d … .java xuất hiện như trên hình.

Để đỡ rối khi đọc, tạm thời tôi di chuyển các file chưa xác định tên tuổi này vào 1 package gọi là “unk” (nghĩa là chưa biết). Một đoạn ruby script nhỏ sẽ giúp ta làm điều này.

Code:
`mkdir unk 2>/dev/null`
Dir.glob("**/*").select { |f| not File.dirname(f) =~ /^unk/ and File.basename(f) =~ /^[a-z]{0,3}\.java$/}.each do |f|
puts f
content = open(f).read().sub("package ", "package unk.")
open(f,"w").write(content)
`mkdir -p unk/#{File.dirname(f)} 2>/dev/null`
`mv #{f} unk/#{f}`
end


Ngoài ra tôi cũng sử dụng thêm công cụ apktool tại https://code.google.com/p/android-apktool/ để thực hiện việc lấy các thông tin về resources của ứng dụng android. (Apktool cũng sẽ convert các file byte code thành dạng smalli và ta cũng có thể sử dụng để hiểu thêm về ứng dụng)

Toàn bộ quá trình trên sau khi hoàn tất tôi đã đưa kết quả lên github cho các bạn nếu thích thì tìm hiểu cùng:

  • WeChat: https://github.com/danghvu/WeChatRE
  • Zalo: https://github.com/danghvu/ZaloRE


( Kết quả của apktool nằm trong src/resources/* )

Phần 2: So sánh mã nguồn

Để so sánh mã nguồn 2 chương trình này, tôi sử dụng gói ứng dụng PMD: http://pmd.sourceforge.net/

Gói ứng dụng PMD có kèm theo 1 chương trình cho phép kiểm tra các đoạn code copy & paste của các file source code trong cùng 1 thư mục. Tôi tiến hành copy file source của Zalo và WeChat vào cùng 1 thư mục và thực hiện:

Code:
./bin/run.sh cpd --minimum-tokens 50 --files ./src/ --language java


( cpd là công cụ “copy-paste-detector”, minimum-token xác định độ dài tối thiểu của đoạn mã cần so sánh. )

Output của chương trình ra giống như sau:

Code:
Found a 257 line (1735 tokens) duplication in the following files:
Starting at line 278 of ./src/ZaloRE/src/unk/com/zing/zalo/utils/a.java
Starting at line 545 of ./src/ZaloRE/src/unk/com/zing/zalo/e/a.java
qC = new int[] { 1, 2, 4, 8, 16, 32, 64, 128, 27, 54, 108, 216, 171, 77, 154, 47, 94, 188, 99, 198, 151, 53, 106, 212, 179, 125, 250, 239, 197, 145 };
int[] arrayOfInt1 = new int[256];
arrayOfInt1[0] = -1520213050;
arrayOfInt1[1] = -2072216328;
….
=====================================================================
Found a 177 line (1211 tokens) duplication in the following files:
Starting at line 663 of ./src/WeChat/com/tencent/qqpim/dao/SYSSmsDaoV2.java
Starting at line 585 of ./src/WeChat/com/tencent/qqpim/dao/SYSSmsDaoV1.java
...


Kông tốt lắm smilie vì cpd không so sánh 2 bộ mã nguồn mà chỉ có so sánh trong cùng một bộ tuy vậy ta có thể làm được điều mình muốn bằng một thủ thuật nhỏ đó là tìm những file giống nhau trong 2 folder khác nhau từ output của chương trình.

Tiếp tục luyện kungfu ruby script:
Code:
zalo = wechat = found = nil
File.open(ARGV[0]).each_line do |line|
if line =~ /^=+$/
puts "#{found}#{zalo}#{wechat}\n" if (zalo and wechat)
found = zalo = wechat = nil
end
found = line if line =~ /Found/
zalo = line if line =~ /Zalo/
wechat = line if line =~ /WeChat/
end
puts "#{found}#{zalo}#{wechat}\n" if (zalo and wechat)


Sau khi chạy script trên với output phần trước thì ta thấy cpd đã tìm ra được tổng cộng 7 tập tin sau đây có sự trùng lặp giữa mã nguồn của Zalo và WeChat =]]]]

(Các file dưới đây các bạn có thể xem tại github mình đã up lên ở phía trên, ví dụ file đầu tiên có thể xem ở https://github.com/danghvu/ZaloRE/blob/master/src/com/facebook/android/Util.java)

Code:
Found a 10 line (86 tokens) duplication in the following files:
Starting at line 131 of ./src/ZaloRE/src/com/facebook/android/Util.java
Starting at line 62 of ./src/WeChat/src/unk/com/tencent/mm/ui/facebook/a/m.java
Found a 5 line (70 tokens) duplication in the following files:
Starting at line 87 of ./src/ZaloRE/src/unk/com/a/b/e.java
Starting at line 155 of ./src/WeChat/src/unk/com/tencent/mm/sdk/platformtools/bg.java
Found a 5 line (69 tokens) duplication in the following files:
Starting at line 87 of ./src/ZaloRE/src/unk/com/a/b/e.java
Starting at line 562 of ./src/WeChat/src/unk/com/tencent/mm/platformtools/bf.java
Found a 16 line (65 tokens) duplication in the following files:
Starting at line 81 of ./src/ZaloRE/src/unk/com/zing/zalo/uicontrol/w.java
Starting at line 55 of ./src/WeChat/src/unk/com/tencent/mm/modelemoji/l.java
Found a 11 line (59 tokens) duplication in the following files:
Starting at line 21 of ./src/ZaloRE/src/me/zing/vn/gl/FilterGLSurfaceView$ConfigChooser.java
Starting at line 21 of ./src/WeChat/src/unk/com/badlogic/gdx/backends/android/w.java
Found a 13 line (59 tokens) duplication in the following files:
Starting at line 161 of ./src/ZaloRE/src/com/zing/zalo/uicontrol/HorizontalPager.java
Starting at line 148 of ./src/WeChat/src/com/tencent/mm/ui/base/MMFlipper.java
Found a 16 line (55 tokens) duplication in the following files:
Starting at line 12 of ./src/ZaloRE/src/unk/com/zing/zalo/plugin/a.java
Starting at line 36 of ./src/WeChat/src/com/android/internal/telephony/ISms$Stub.java


Hm.. liệu Zalo có ăn cắp mã của WeChat / ngược lại ? Tôi cẩn thận xem xét từng file và nhận thấy những đoạn code giống nhau là từ những mã nguồn của các thư viện mở mà 2 ứng dụng này cùng sử dụng.

Lấy ví dụ, ta thử so sánh:
Code:
Starting at line 131 of ./src/ZaloRE/src/com/facebook/android/Util.java
Starting at line 62 of ./src/WeChat/src/unk/com/tencent/mm/ui/facebook/a/m.java
if (!paramBundle.containsKey("method")) "
paramBundle.putString("method", paramString2);
if (paramBundle.containsKey("access_token"))
paramBundle.putString("access_token", URLDecoder.decode(paramBundle.getString("access_token")));
localHttpURLConnection.setRequestMethod("POST");
localHttpURLConnection.setRequestProperty("Content-Type", "multipart/form-data;boundary=" + "3i2ndDfv2rTHiSisAbouNdArYfORhtTPEefj3q2f");
localHttpURLConnection.setDoOutput(true);
localHttpURLConnection.setDoInput(true);
localHttpURLConnection.setRequestProperty("Connection", "Keep-Alive");
localHttpURLConnection.connect();


Đây là một đoạn xử lý khi ứng dụng muốn gửi 1 request lên ứng dụng facebook ( vì Zalo và WeChat đều có facebook integration ) nằm trong bộ Facebook-Sdk (File version nằm ở src/com/facebook/FacebookSdkVersion.java )

Một điều thú vị nữa khi đọc đoạn code này là dường như cả Zalo và WeChat đều không sử dụng giao thức HTTPS smilie, bởi vì cả 2 cùng sử dụng “HttpURLConnection” thay vì "HttpsURLConnection” , attacker có thể dễ dàng “sniff” các gói tin … Để khẳng định điều này chúng ta sẽ sniff packet của Zalo và WeChat để so sánh, nhưng xin hẹn lại dịp sau.

Kết luận của tôi tạm thời hiện nay qua việc kiểm tra mã nguồn thì tuy có 1 số trùng lặp trong code nhưng điều đó chưa chứng tỏ được Zalo có sử dụng mã nguổn sao chép từ WeChat.

Để khẳng định rõ hơn nữa thì cần phải tiếp tục rà soát các yếu tố trong các tính năng chính của cả 2 bên, phần bộ nhớ lúc thực thi (phần sau sẽ hướng dẫn sử dụng debugger cho android) và các phần mã bị làm rối mà jd-gui không dịch ngược lại được. ( Chẳng hạn : WeChat/src/unk/com/tencent/mm/sdk/platformtools/bg.java :1272 )

To be continue ..

xnohat wrote:
Làm khó bạn rồi windak smilie HVA có csrf cũng khó mà khai thác được vì có quá nhiều giới hạn khó vượt qua 

=p hihi, làm khó mới ló cái khôn chứ xnohat

Thôi hỏi lùi về 1 bước vậy. Hva có cơ chế chống CSRF như thế nào ? Có ai xung phong trả lời câu này không ?
Học phải đi đôi với hành.
Bài tập cho bạn là hãy tìm lỗi CSRF trên chính forum này của HVA.
Nếu chắc chắn đó là Mysql 5.1.xx thì có khả năng là information_schema bị filter hoặc replace bởi giá trị khác.

Cách giải quyết thì phải tùy trường hợp rồi.. nhiêu đó thông tin thì không đủ.
Nhằm tối ưu và hỗ trợ cho kĩ thuật "tấn công tâm lý" ( Social Engineering ), các hacker đã cho ra đời bộ công cụ Social-Engineer Toolkit (SET), giúp các tin tặc dễ dàng hiện thực kiểu tấn công này trong đời thực

Công cụ khai thác Social-Engineering (SET) là một công cụ tổng hợp các cách tấn công tận dụng sơ hở của người sử dụng qua các yếu tố tâm lý kết hợp với các lỗi bảo mật đã được phát hiện. Giao diện của SET khá lạ so với các công cụ khác bao gồm nhiều câu hỏi và lựa chọn tương ứng với các tình huống khác nhau khi khai thác Social Engineering. Phiên bản 3.2 mới được cập nhật có giao diện như sau:
Code:
root@bt:/pentest/exploits/set# ./set
..snip..
Welcome to the Social-Engineer Toolkit (SET). Your one
stop shop for all of your social-engineering needs..
Join us on irc.freenode.net in channel #setoolkit
Help support the toolkit, rank it here:
 http://sectools.org/tool/socialengineeringtoolkit/#comments
Select from the menu:
1) Social-Engineering Attacks (Tấn công Social-Engineering)
2) Fast-Track Penetration Testing (Kiểm tra bảo mật nhanh)
3) Third Party Modules ( Các thư viện của tổ chức khác )
4) Update the Metasploit Framework ( Cập nhật Metasploit )
5) Update the Social-Engineer Toolkit ( Cập nhật ứng dụng )
6) Help, Credits, and About (Giúp đỡ)
99) Exit the Social-Engineer Toolkit (Thoát)
set>


Chọn 1
Code:
Select from the menu:
1) Spear-Phishing Attack Vectors (Tấn công dạng lừa đảo email Spear-Phishing)
2) Website Attack Vectors ( Tấn công dựa trên lỗ hổng web )
3) Infectious Media Generator ( Tạo những file media độc )
4) Create a Payload and Listener ( Tạo payload tấn công và cài mã độc)
5) Mass Mailer Attack ( Gửi email hàng loạt )
6) Arduino-Based Attack Vector ( Tấn công dựa trên Arduino )
7) SMS Spoofing Attack Vector ( Tấn công mạo danh SMS )
8) Wireless Access Point Attack Vector ( Tấn công mạng không dây )
9) QRCode Generator Attack Vector ( Tạo các mã QR độc )
10) Third Party Modules ( Các thư viện của tổ chức khác )
99) Return back to the main menu. ( Quay về menu chính )


Sau khi chọn một trong các kiểu tấn công, SET còn giải thích rõ nguyên lý hoạt động của kiểu tấn công đó. Ví dụ nếu ta chọn mục số 6 trong các mục ở trên SET sẽ in ra:
The Arduino-Based Attack Vector utilizes the Arduin-based device to program the device. You can leverage the Teensy's, which have onboard storage and can allow for remote code execution on the physical system. Since the devices are registered as USB Keyboard's it will bypass any autorun disabled or endpoint protection on the system.
..snip..
Phương pháp tấn công Arduino tận dụng những thiết bị chuẩn Arduin để cài chương trình vào thiết bị đó. Bạn có thể sử dụng công cụ của Teensy mà có bộ nhớ trong cho phép thực thi mã độc khi cắm vào máy. Vì thiết bị này được xử lý như một bàn phím USB, nó có thể vượt qua các phần bảo vệ của hệ thống (như ngăn cản autorun).


SET có sẵn trong backtrack, nhưng là phiên bản rất cũ smilie bạn cần phải tự mình update lên phiên bản mới nhất.

Phiên bản 3.2 với mã tên "#FreeHugs" có thêm nhiều cải tiến bao gồm 1 phần cho phép lựa chọn payload để tạo HTTP reverse shell xây dựng riêng cho ứng dụng. Thêm vào đó rất nhiều exploit của Metasploit cũng được thêm vào phần tấn công lợi dụng lỗ hổng trình duyệt web. Tóm tắt những thay đổi quan trọng gồm có:

* cải tiến cho phần tấn công thông qua HTTP, phần Reverse HTTP Shell sẽ sử dụng mã hoá AES khi gửi lệnh và nhận kết quả.
* thiết lập khả năng tạo RevHTTP shell khi tấn công bằng Java Applet
* thêm công cụ tận dụng lỗi "AtomicReferenceArray Type Violation Vulnerability","Adobe Flash Player MP4 ‘cprt’ Overflow exploit","MS12-004 midiOutPlayNextPolyEvent Heap Overflow", vào các công cụ tấn công sử dụng Metasploit
...

Toàn bộ phần thay đổi có thể xem thêm tại https://www.secmaniac.com/blog/2012/04/02/the-social-engineer-toolkit-v3-2-codename-freehugs-has-been-released/
Hình như cái bạn foaato đang nó là asymmetric key để tạo MAC anh mrro:

A: quy trình trong trường hợp mã hóa rồi mới kí như sau: Alice dùng khóa công khai của Bob để mã hóa thông điệp, gọi cái thông điệp sau khi đã đc mã hóa này là Z. Sau đó dùng khóa bí mật của mình (Alice) + nội dung thông điệp (đã mã hóa) để kí. Gọi cái chữ kí này là Y. Khi đó Alice sẽ truyền đi cặp (Z,Y), Khi Bob nhận được thì sẽ thử tất cả các khóa công khai mà mình có để xem ai là chủ của cái chữ kí này (ở đây là Alice), sau khi đã xác định được ai kí lên thì mới bắt đầu giải mã thông điệp
 


Nhưng cách giải thích chắc cũng tương tự + khoái vụ cái kéo kỳ diệu smilie giờ thì đã hiểu bản chất hậu quả của vụ tấn công này của bạn foaato.

mrro nghĩ sao vụ replay attack ? có thể sảy ra không anh ?
A -> B : M = [ E(P = chuyển khoản 100$ cho C) || MAC ]
C tóm được M, thấy tài khoản tăng 100, nhào dzo ngay sau đó gửi M đi 100 lần => C có 10000$ trong tài khoản.

Bạn foaato rất nên tham gia lớp crypto-class online của Stanford do mrro trợ giảng smilie. Trong đó có 1 bài giải thích sự khác nhau giữa Mac-AND-encrypt , Mac-THEN-Encrypt, Encrypt-THEN-Mac

Skype khuyến cáo người dùng cẩn thận vì đã xuất hiện một trang web cho phép bất cứ ai có thể tìm thấy thông tin địa chỉ IP của một người dùng bất kỳ. Một đoạn mã nguồn cũng đã được tải lên Github cho phép thực hiện công việc tương tự. Địa chỉ IP mạng nội bộ và mạng bên ngoài và các cổng truy cập đều có thể bị đánh cắp. (Hiện nay trang web đó đã bị gỡ xuống và không truy cập được)

Giám đốc quản lý bảo mật của Skype lên tiếng: "Chúng tôi đang điều tra sự xuất hiện của công cụ mới này. Đây là một vấn đề lâu dài và của chung mọi công ti phần mềm peer-to-peer. Chúng tôi luôn làm việc hết sức để đảm bảo an toàn và bảo mật cho người dùng và đang chuẩn bị cách tốt nhất để bảo vệ họ".

Chứng minh cách khai thác khá đơn giản. Một kẻ xấu chỉ việc tải 1 phiên bản Skype đã bị chỉnh sửa và thay đổi một số khoá trong phần Registry của Windows để tạo những tập tin mà mục đích ban đầu là để gỡ lỗi cho chương trình. Sau đó hắn sẽ gửi yêu cầu kết bạn đến account cần tấn công, giữa quá trình này thông tin về account của người đó sẽ bị lưu lại.

Chương trình và cách tấn công còn được đưa lên http://pastebin.com/rBu4jDm8 kèm theo 1 số chỉnh sửa nhỏ để kẻ tấn công có thể biết IP lấy được có đang online hay không và cách thức đơn giản 'whois' để lấy thông tin về địa chỉ vật lý như thành phố, quốc gia. Phiên bản Skype 5.5 vẫn đang bị lỗi này dù lỗ hổng đã được tìm ra và công bố tại hội nghị "Internet Measurement Conference" năm 2011 tại Berlin.

Đến giờ vẫn chưa có cách nào chống lại phương thức tấn công này ngoài cách tạo một mạng riêng ảo hoặc sử dụng proxy để che dấu IP khi vào Skype

Theo
http://thehackernews.com/2012/05/skype-vulnerability-exposing-user-ip.html
Có thể chống lại việc "đổi tên" của bạn bằng việc khi encrypt kèm thêm 1 đoạn mã [Tôi là A] vào message, thì cho dù C có sign lại message thì B vẫn biết message này đã bị ký sai sau khi giải mã message.

Nhưng nếu chỉ xem xét một lệnh send như thế thì theo mình không đủ đánh giá cả quá trình truyền thông điệp là "an toàn" hay "tối ưu".

Đầu tiên là MAC sử dụng cùng private key thì giúp đảm bảo thông điệp không bị thay đổi và đảm bảo thông điệp được gửi đi từ người ký thông điệp (integrity & authenticity). Mã hoá thì giúp bảo đảm không ai đọc được thông điệp trừ người tham gia ( confidentiality )

Nó không chống lại kiểu tấn công "replay attack" như bạn nói ( mình cũng không biết kiểu tấn công đổi tên như thế gọi là gì, nhưng cái này có vẻ gần với replay attack khi kẻ tấn công có thể lấy những thông điệp cũ à gửi như là 1 thông điệp 'valid' )

Để chống lại kiểu tấn công đó và các kiểu tấn công khác cần có 1 protocol hoàn chỉnh từ đầu quá trình gửi tin giữa 2 bên đến lúc kết thúc.
Một lỗi khá mới nhắm vào phần mềm quản trị nội dung (CMS) nổi tiếng - Joomla, được công bố từ tháng 3/2012 trên blog của Jeff Channell [1] nhưng vẫn chưa được nhiều người biết đến.

Kẻ xấu có thể khai thác lỗi bằng cách chèn thêm vào form đăng ký của Joomla trường jform[groups][] với giá trị "7" tương đương với nhóm admin và cố tình đăng nhập lỗi ( ghi sai password hay captcha ). Joomla lúc này sẽ lưu giá trị group này vào phiên làm việc và trong lần đăng ký ngay sau đó kẻ tấn công sẽ đăng ký thành công với quyền hạn cao nhất. Từ đây hắn có thể đăng nhập vào phần quản trị, upload mã độc và leo thang đặc quyền chiếm cả máy chủ.

Lỗi này nằm ở trong tập tin : /components/com_users/models/registration.php dòng số 190 trong phiên bản Joomla 2.5.2

Code:
// Get the groups the user should be added to after registration.
$this->data->groups = isset($this->data->groups) ? array_unique($this->data->groups) : array();


Thật khó hiểu lý do tại sao người thiết kế Joomla muốn để chức năng này.
Phiên bản 2.5.3 đã vá lỗi bằng cách khởi tạo 1 cách bình thường

Code:
$this->data->groups = array();


Exploit PoC được đính kèm bản tin này, viết dưới dạng chrome extension. Đã thử nghiệm trên Joomla 1.7.5 và 2.5.2.

Source Code: https://github.com/danghvu/j0wnla

[1] http://jeffchannell.com/Joomla/joomla-161725-privilege-escalation-vulnerability.html

acenux wrote:
Hiện tại ngay cả Facebook cũng chưa fix lỗi này trên sever của họ :

Code:
http://news.softpedia.com/news/Facebook-Partially-Vulnerable-to-PHP-CGI-Bug-Security-Expert-Finds-267689.shtml


Nếu truy cập http://www.facebook/?-s thì ra
Code:
<?php
include_once 'https://www.facebook.com/careers/department?dept=engineering&req=a2KA0000000Lt8LMAS';
 

LOL :trolled: by facebook.

Chỉ là trò đùa của facebook thôi smilie
Thế thì có lẽ cái hàm check của chiro8x còn yếu hơn cái trong bài này =P

Thay vì kiểm tra dữ liệu đầu vào có phải sql injection / xss / lfi / lrf không smilie sẽ tốt hơn nhiều nếu kiểm tra điều ngược lại !! ( và tốt hơn nữa nếu sử dụng cả 2).

Còn riêng về sql injection thì cách an toàn nhất là sử dụng câu truy vấn có chuẩn bị - "prepared statements" và sử dụng một cách chính xác.
=P chiro8x có thể viết hết cái

//Check Here  


được không ? chứ nhìn thế này thì không biết có gì khác cái cũ.

conmale wrote:

nvhbk16k53 wrote:

conmale wrote:
Vậy có nghĩa là máy của bồ không có đủ RAM để notepad+ sử dụng.

Thử cài VIM từ http://www.vim.org/download.php#pc để dùng nó mà mở. 

Dùng VIM mà gặp phải những dòng quá dài thì cũng treo luôn anh à smilie 


VIM không read trọn bộ file như mấy cái wordpad, notepad, word... chuối chiên của Windows mà nó chỉ read và buffer bao nhiêu dòng hiển thị trên màn hình mà thôi. Bởi vậy, dù có 1 dòng quá dài đi chăng nữa, nó cũng chỉ read và hiển thị chính xác số ký tự khít cho trang hiển thị thuộc về 1 dòng 'quá dài' nào đó. Tình trạng bị treo có lẽ là do bugs của một phiên bản VIM nào đó chớ không phải do buffer quá lớn (hết mem) mà treo đâu. 


Anh conmale xài vim phiên bản nào ? Như em thử nghiệm phiên bản 7.3 (default settings) thì nó vẫn đọc toàn bộ file cho đến khi Ctrl-C.

Khi đọc file lớn em thường xài "less"
@chiro8x:
smilie chính xác, đây mình cho rằng là điểm yếu của 'blacklist' tự tạo, nếu không "rành" thì dễ dàng bypass được.

chiro8x có giải pháp gì không ?
Nhìn vào "blacklist" này dễ thấy ngay 1 cách bypass để chèn các truy vấn sql. Xin hỏi anh em nào nhìn thấy không ?
Không thích phần "Lập trình" của anh mrro lắm, vì thiếu quyển "Introduction to Algorithms" - CLR
http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-046j-introduction-to-algorithms-sma-5503-fall-2005/

Đã từng biết 1 vài bạn rất hiểu biết các kiến thức máy tính nhưng khi đặt tay xuống chấm ngoáy 1 cái tool thì không làm được. Cơ bản là chưa đọc quyển này.
Tớ vừa đóng góp 1 challenge mới. Trong phần này bạn phải sử dụng 1 lỗi mới được phát hiện gần đây và rất nhiều ứng dụng đã từng mắc phải để giải quyết.

Mời bạn tham gia:
http://bkitsec.vn/?topic=file-manager

Phó Hồng Tuyết wrote:

MAC là dấu chân asin trong trường hợp bạn nêu ở trên.

nếu VPS Free thì yêu cầu là bạn phải đăng ký dịch vụ (dính MAC - thậm chí là IP thật), thông tin sẽ được lưu lại nơi bạn đăng ký Free VPS.

Nếu VPS do bạn của bạn share thì mức độ nguy hiểm cao hơn.

---
trở lại vấn đề :

VPS thì tất nhiên nó có ip tĩnh. khi có ip này sẽ truy ra được nhà cung cấp dịch vụ nào.

Yêu cầu xin log của người mua VPS đó hoặc log đăng ký VPS.

Khi có được log này thì sẽ có khả năng có được IP thật và MAC

* nếu dùng FAKE IP : thì khó xác định.
* IP Thật + MAC : smilie

 


Bạn có đọc kỹ tôi viết không vậy ? Tôi có nói rõ là sử dụng TOR, vậy thì trace về VPS như thế nào ? Chưa kể những dịch vụ như Amazon EC2 còn cho phép tạo và xóa VPS trong tài khoản cá nhân 1 cách tùy ý, và cũng không thấy có điểm nào đòi bạn phải đăng ký MAC address cả

Mời bạn trình bày tiếp.
Nếu kịch bản là:

- Hacker login vào một free VPS, online bằng TOR
- Cài máy ảo (VM)
- Cài 1 hệ điều hành Linux fresh vào VM
- Tấn công BKAV qua trình duyệt và application của VM
- Xóa harddisk của VM
- Ngắt kết nối với VPS
- Không bao giờ sử dụng VPS đó nữa (disable service hoặc terminate plan)

Rõ ràng cho dù có evercookie thì nó cũng chỉ save browser của máy ảo
Như vậy liệu có cách nào phát hiện được không ? Mọi người cho ý kiến ?
 
Go to Page:  2 3 4 Page 5 Last Page

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