Researcher builds botnet-powered distributed file storage system using JavaScript

 The botnet-type system is called HiveMind and was built by Sean T. Malone, a principal security consultant at penetration testing firm FusionX.
HiveMind uses technologies like HTML5 WebSockets and Web Storage that are also used by legitimate Web applications.
There are no malicious exploits being used, so there is nothing that can be patched to prevent it, Malone said. However, building the botnet by getting other people's browsers to load a piece of JavaScript code and storing data on their computers falls into a legally gray area, he said.
"This was a research project, not production software" he said. "I'm not a lawyer, so I don't intend to give anyone legal advice with this," he said, adding that everyone is responsible for what they decide do with the software he plans to release later this week.
The HiveMind JavaScript code can be distributed to browsers in several ways, including hosting the JavaScript code on legitimate or compromised websites or by distributing the code through an advertising network, which would place it on multiple websites.
For his research, Malone set up an anonymous Web proxy server that later got added to proxy lists and started being used by people. Every time someone used the proxy server to browse to a Web page, the server would inject the HiveMind JavaScript code into that page.
According to the researcher, his proxy server was getting connections from 20,000 unique IP addresses every ten minutes, which then became nodes in the botnet.
HiveMind has a C&C (command and control) server that uses a SQL database to keep a record of all files and the nodes -- browsers running the JavaScript code -- they're distributed on.
When a file is uploaded to the server, it is encrypted using the AES (Advanced Encryption Standard) with a password provided by the uploader. The encrypted file then gets split into multiple blocks and those blocks are distributed across different nodes.
Every file can have a different password, Malone said.
Because the botnet is highly dynamic, with nodes constantly disappearing when users close their browsers, every file block is distributed across multiple nodes to achieve redundancy.
The nodes constantly announce their presence and the list of blocks they have back to the server, so that a particular block can be redistributed to new nodes if the number of nodes storing it drops under a certain threshold.
After a file is uploaded, encrypted and distributed to the nodes, it is no longer kept on the server. Only a record of the nodes that contain its different blocks is stored, because this is necessary to rebuild the file, Malone said.
If a government agency were to seize the server and take it away, the block replication process would fail because the nodes would start going offline, which would make the file unrecoverable, Malone said. There are a few ways to recover the data, but it is very difficult and it involves seizing a large number of nodes or compromising the server while it's still online and coercing the owner to provide the passwords necessary to decrypt the files.
There is a way to provide "plausible deniability" for the owner and it involves initially seeding the server with a large number of dummy files that contain random data, but this functionality is not yet built into the system, Malone said.
The user can say that he created the system, but did not put any real data in it, even though he did also upload some real files along with the dummy ones.
Because the random data in the dummy files looks the same as the random data in encrypted files, when trying to recover a file there is no way to tell if the password supplied by the user was correct and a dummy was decrypted, or if the password was wrong, the researcher said.
In this way, the user can supply the wrong password for the files he knows are real and the other party would have no way to prove that the password was correct or incorrect.
While the legality of building such a botnet is questionable, this system could also be set up as a collaborative effort, where users volunteer their browsers themselves and are able to upload files to the system, Malone said.

Secure Code Review:Need for every application

This article is about different code review techniques and their application in the real world
What you will learn:

What is secure code review and how to deal with them in real-life scenarios
What you should know:

Basic security concepts
Secure Code Review:

Secure Code Review is a process which identifies the insecure piece of code which may cause a potential vulnerability in a later stage of the software development process, ultimately leading to an insecure application. When a vulnerability is detected in earlier stages of SDLC, it has less impact than the later stages of SDLC – when the insecure code moves to the production environment. In the SDLC (Software Development Life Cycle) process [Figure-1], the secure code review process comes under the Development Phase, which means that when the application is being coded by the developers, they can do self-code review or a security analyst can perform the code review, or both. The developers may use automated tools which can be integrated with their IDE (Eclipse, MS VS, etc…) and can do coding and code review simultaneously. After that, they can take the help of a security expert to identify more flaws in the code, as the security experts have a more intrinsic view of security issues which might be missed by the developers.
Different studies and surveys shows that approximately 75% of attacks happen due to an insecure application, inside which includes insecure code. This way, it becomes a very essential part of SDLC which should be performed rigorously. Developers mostly tend to focus on the functionality of the application and ignore the secure coding approach. But nowadays they have become more conscious about code review due to the increasing incidents of hacking and server attacks.

Figure – 1

Techniques to secure code review:

Generally, we can divide the secure code review process into two different techniques:

1. Automated tool based/ Black Box: In this approach, the secure code review is done using different open source/commercial tools. Mostly developers use them while they are coding, but a security analyst may also take help of them. Tools are very useful while doing code review when we implement the secure SDLC process in the organization and provide the tool to developers themselves to do a “self-code” review while they are coding. Also, the tools are useful in analyzing large codebase (millions of lines). They can quickly identify potential insecure pieces of code in the codebase, which may be analyzed by the developer or a security analyst.
2. Manual/ White Box: In this technique, a thorough code review is performed over the whole code, which may become a very tedious and tiresome process. But in this process, logical flaws may be identified which may not be possible using automated tools, such as business logic problems. Automated tools are mostly capable of finding technical flaws such as injection attacks but may miss flaws like authorization problems. In this process, instead of going line by line through whole code base, we can concentrate on potential problems in the code. Those potential vulnerabilities can be given a high priority. For example, in C/C++, if we try to find any copying function in the code and check whether it’s using functions such as, strcpy() for performing copy function. As we know, strcpy() is known to be vulnerable to buffer overflow attacks. We may also want to check if any customized encryption is being used in the application, which automated tools may miss as they can identify standard algorithms only.
   So the best approach will be a mix of both, depending on the volume and criticality of data. In today’s world where many complex applications are developed, we can’t ignore any of the above mentioned techniques.

Benefits of Secure code review:

There are some factors that should be taken into consideration while developing a robust access control mechanism in the web application:

1. Effort benefit: The effort to fix the vulnerabilities in the earlier stage of the SDLC process is much less than the later stage of the process. Once the code is complete and the flaw is not identified, it’s a very tedious and time consuming process to find problems once the application is ready to move into production. Also, last minute fixing may affect the entire functionality of the program and hamper deadlines set for product release. Who knows, it may create another security flaw, which can easily be possible with a large and complex code.
2. Cost benefit: Cost is directly proportional to effort required. Not only development cost, but also, a vulnerability identified in the production environment may involve more costs. Again, it’s well worth it, as the costs associated with an attack can be much steeper.
3. Compliance: Some compliance, such as PCI, makes it necessary to do a secure code review before launching the product. So an organization following complete SDLC has better chance of being certified.
4. Reputation: Secure code review removes most of the security flaws in the earlier phase, making it more secure than just doing black box assessments. So there is less chance of the product being compromise, hence lesser chance of reputation damage.

Approach:

These are based on mix of standard process and my own approach. It may differ from person to person.
Standard process [Figure-2]:

Figure-2

Define scope: First, you need to understand and come up with a rough estimate about the scope of the code review and the efforts involved in it. Also, budget constraints may be defined. What type of code review may be performed? Black box or white box? Try to understand the business logic of the application. Remember which vulnerabilities you need to look for, such as OWASP Top 10, SANS, etc… One can try to review them as much as possible, if not all of them. Then you can deduce how many of them can be detected using tools and which are best suited for manual review.
Categorize the vulnerabilities: What is your priority, meaning what type of vulnerabilities you will take as a priority? For example, in business applications, you may concentrate mostly on the business logic of the application and dive deep into it, as the technical ones are easily detected by tools. Prioritize them.
The following are a few categories you can look at:

• Authorization
• Authentication
• Injection flaws
• Improper error handling/Exception flaws
• Encryption (Cryptography)
• Auditing and Logging
• Session related flaws (Session management)
• Insecure configuration

Recommendation: As a security analyst, it’s our duty filter false positives generated by tools and validate them in order to confirm that they are actual flaws. After doing a proper code review, you should document the vulnerabilities found in a comprehensive report coating the category of the vulnerability and their mitigation. You may go one step ahead and suggest a sample secure code. I personally include the code snippets as well in the report, preferably in an excel file and then attach it.
This is how I personally go about it. The points below are based on my experience till date in doing code review. I have still a lot to learn and the points below may or may not hold true in every condition:
Always perform manual reviews: Automated code review is a process where you run the scanning tools like Rational, Ounce Labs, and Parasofton the code base followed by a manual auditing of the results. The scanner flags the whole code with vulnerabilities based on its perception. Now it’s the job of the auditor to differentiate between real issues and false positives. Here is where the real pain starts. You don’t have command over each and every language. So taking help of language specific resources is required. Now, I have got familiar with almost all major languages (.NET, Java, PHP) specific vulnerabilities. Doing a black box assessment you never come to know where the real problem lies.
Talk to developers first: The more you involve developers in your code review process, the more effective the analysis will be. You get confidence that whatever you are doing is based on the right understanding of the code. On the other hand, developers also get happy that you are taking theminto confidence instead of declaring something vulnerable straightaway.
Have a notebook and pen handy to understand the flow of the program. Understanding the source of the taint and where does it reflects in the code is necessary to catch the real vulnerabilities. Just seeing that the taint is entering the program and reflecting in some other part of the program doesn’t always mean that it is vulnerable to Cross Site Scripting, for example. Again here, talking to developers helps, as they might be implementing some centralized input filtering/validation mechanism. So don’t just jump to any conclusions.
Use an advance text editor: The text editor should be capable of searching a term in the whole code base. One such text editor is Notepad++. It searches the term and highlights them so that you can see where all places the particular term is being used. It helps you in joining the pieces and seeing the complete picture.
Have sufficient time to do code review, as you need to apply your thoughts more than once to pick up real vulnerabilities. So always ask your customers for sufficient time in fully completing the project.
Being connected to Internet always helps at the time of code review. Certain terms, functions or methods always annoy you as you might have not have seen them before. Google helps a lot in understanding them.
Find vulnerabilities in context of the application: Not only should you pick up real and applicable vulnerabilities in the context of the application – as it decreases the number of issues – but also, you should propose the countermeasures in the report. That makes developers happy and confident. The scanner may flag any issue as High, Medium or Low. It’s your responsibility to give them appropriate ranking based on applications context.
Everybody loves his own program: Programs are like a developers baby. Don’t always pinpoint the weaknesses of the program, also appreciate them if you find any robust mechanism used in the program. That way, you can make them friendly and they will always come to use to get their code reviewed. So both are then happy.
Train them: Last but not least, train developers about the vulnerabilities in the real world. Give them training, involve them and encourage them to review their codes before production. Tell them how it saves effort and money. If you have a scanning tool that supports plug-ins for IDE, install it at their machines so that they can do proper development and a hand by hand review.
A Sample Illustration:

Consider this example( Owasp WebGoat Project):
String username = “”;

String password = “”;
username = s.getParser().getRawParameter(USERNAME);
password = s.getParser().getRawParameter(PASSWORD);

……………..

………..……

String query = “SELECT * FROM user_system_data WHERE user_name = ‘”

+ username + “‘ and password = ‘” + password + “‘”;

ec.addElement(new StringElement(query));

The inputs from the user are requested through getRawParameter, and assigned to the ‘username’ and ‘password’ variables. Again, they are being used directly in the SQL query without any input validation and also being embedded into the dynamic query. Any malicious user can tamper with this query to run his own arbitrary SQL codes. So if we try to find all the entry points into the codebase (getRawParameter in this case), we may detect injection flaws. Even if we search for SQL queries being used in the code, if we find that they are being used as dynamic queries, they may be a case of a possible SQL injection.

On the Net:
 https://www.owasp.org/index.php/Category:OWASP_Code_Review_Project
https://www.owasp.org/images/2/2e/OWASP_Code_Review_Guide-V1_1.pdf

Keep your laptop safe while using Wi-Fi hotspots

The relaxing atmosphere of surfing at the beach makes it easy to forget about the sharks. Connecting to an unsecured network poses serious risks to your laptop and data. In a recent study, Bitdefender labs revealed 85% of people choose to connect to a free Wi-Fi, despite clear warnings that their data can be viewed and accessed by a third party.



Surfers can lose sensitive information to hackers in a bewildering variety of ways - especially if they access the Wi-Fi networks available in public locations:

• Around you, others connect to the same network, and one of them might happen to have the proper tool to scan your laptop for vulnerable software and use it to plant backdoors or access login credentials if, for instance, they are sent unencrypted.
• A mid-level techie can set up a network, give it a generic name such as “free Wi-Fi” or “Secure public Wi-Fi,” and monitor the traffic of all users that connect to his network in sniffing or man-in-the-middle attacks. They can read all data sent in that network.
• Someone sniffing data packets can snatch session cookies to access your resources, including social networking, online banking and online shopping accounts during that open session. Imagine someone changing your status or uploading a photo on your behalf.
• Accessing online banking and online payment websites or making e-shopping transactions through public Wi-Fi hotspots might be convenient, but cyber-criminals can still use a fake SSL certificate to circumvent a secure connection, have the user approve it and use it to sniff login data and such.

Best practices to protect your data while using a Wi-Fi connection:

1. Access only encrypted websites while on public hotspots. Make sure you type ‘https://’ before the URL of the website or look for the locked padlock that shows you are using a secure connection, meaning you are using encryption over a public Wi-Fi.

2. Ask an employee (bartender, hotel receptionist) for the exact name of the hotspot you intend to use so you don’t accidentally access a network set up by someone with a secret agenda. You can also ask the hotel receptionist if they use AES with their wireless network. But if you access over a wireless connection websites that are not using encryption, someone in the same network can still sniff data packets and see what you send in the network.

3. Make sure the Wi-Fi, or the automatic sharing options are switched off when you are not using them. With Wi-Fi automatically enabled, you risk having your laptop trying to connect to an unsecure network without you even realizing it.

4. Don’t check your account balance sheet or shop online on a public Wi-Fi. If you do, use a dedicated payment solution that helps you securely connect to your bank account or e-payment website from an unencrypted hotspot.

5. Password–protect and encrypt your device. In case someone steals or finds your device, make it harder to access information stored there. Also encrypt your data with dedicated software, or – if your device supports it – with the default encryption option. Use anti-theft programs to help track your device and lock or wipe your data from afar.

6. Install anti-virus software and keep it up-to-date. Installing an antivirus and a privacy security solution on your laptop is imperative. A good security solution with anti-malware, anti-spyware and anti-spam modules offers an effective shield against all kinds of threats. This will help you steer clear of fake security apps, worms, Trojans and viruses.

By keeping your OS and apps up-to-date, you give your system the most recent patches for all known vulnerabilities to protect you against the latest threats. Many pieces of malware target unpatched vulnerabilities. Once patched, they cannot harm your device or your data.

7. Turn off the laptop when you are not using it. You want to keep your laptop always on so you can access it the instant you need or want to, but this can be a bad practice. In case your system is infected with a botnet, the malware may continue to use your resources even when you are not using it.

8. Your firewall must be on at all times. The firewall is crucial for joining this kind of network. When surfing without a firewall, your PC is visible to others, along with your network shares you might have left open for friends at the office or for your family at home.

Qualys announces WAF Beta for Amazon EC2

Qualys will release the beta of its new cloud WAF solution as an Amazon Machine Image (AMI) and as a VMware virtual image for on-premise deployments starting August 1.

Qualys’ new WAF service is delivered through the multinational, highly scalable QualysGuard Cloud Platform, providing customers centralized management capabilities, distributed protection and ease-of-use, whether applications are running on premise or in the cloud.

WAFs work by shielding web sites by applying a set of rules to HTTP conversations to prevent them from being attacked. However, WAF technology is costly and complex to apply because these rules need to be customized to the applications, and they must be updated often to cover changes to the applications and to address new and emerging threats. As a result, many organizations cannot afford to deploy WAFs, or they can only deploy them on a select number of mission critical web properties.

The new QualysGuard WAF is designed to provide:

• Real-time application defense, blocking attacks against websites as they happen.
• Application hardening, minimizing application attack surfaces by providing a shield around coding defects, application framework flaws, web server bugs and loose configurations.
• Low-cost, automated service maintained and updated by Qualys’ security experts providing new defenses and features transparently to users and site visitors.
• A multitude of deployment options for distributed WAF protection points managed through a common, central policy administration and reporting interface with APIs for integration.

Customers using WAF will experience benefits including:

• Always up-to-date rules.
• Immediate rules deployment on all WAFs connected to QualysGuard.
• Maximum efficiency as rules are strengthened with security events from all WAF customers.
• In-cloud or on-premise web site protection, with a SaaS platform providing centralized management for distributed WAF virtual appliances.

“Qualys is committed to delivering powerful, effective cloud solutions that remove the cost and complexity associated with IT security and compliance, and we are excited to provide an affordable, automated solution with our next generation WAF,” said Philippe Courtot, chairman and CEO for Qualys. “The debut of our WAF service in beta for Amazon EC2, as well as with an on-premise virtual appliance image, will offer customers the flexibility they need to protect their applications no matter where they reside.”

FBI uses malware to spy on suspects via their phones

he FBI has been known to use malware to spy on suspects via their computers but mobile phones make even better sources of information.

Just think about it: the great majority of people carries their mobile phones everywhere with them, and surreptitiously turning on the device's microphone can result in crucial information being gathered.

Former US officials have revealed that the FBI has been using mobile malware to compromise suspects' Android-based phones to record conversations happening in the presence of the device and to exfiltrate data from it that might offer more insight into the suspects' potential criminal activities.

According to the WSJ, a permission to do that is more easily secured from a court that that for listening into the suspects' communications made via the device.

It's interesting to note that this approach is used in organized crime, child pornography or counter terrorism cases, and rarely - or possibly never - to target hackers.

The thing is that in order to install such spyware on the device, there has to be some user interaction. The target must follow a web link or a link delivered to him via email in order to land on a website that will exploit a vulnerability in his software to make the malware download on the device - and hackers are more likely to detect the attempt, look into it and publicize it.

A former official in FBI's cyber division claims that the Bureau creates some of the hacking tools internally, and buys additional ones as well as exploits for zero-day vulnerabilities from private companies such as HackingTeam SRL and Gamma International, both of whom were recently dubbed "corporate enemies of the Internet" by Reporters Without Borders for selling products that are liable to be (and have been) used by governments to violate human rights and freedom of information.