Search the Community

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

# Exploit Title: OpenKM Platform Remote Reflected Cross Site Scripting # Google Dork: N/A # Date: 18-11-2014 # Exploit Author: Mohamed Abdelbaset Elnoby (@SymbianSyMoh) # Vendor Homepage: http://www.openkm.com/en <http://s.bl-1.com/h/mQ2bNXq?url=http://www.openkm.com/en>/ # Software Link: http://www.openkm.com/en/download-english.html <http://s.bl-1.com/h/mQ2bTws?url=http://www.openkm.com/en/download-english.html> # Version: All versions < 6.4.19 (built 23338) # Tested on: All OS # CVE : 2014-9017 -About OpenKM OpenKM is a Free/Libre document management system that provides a web interface for managing arbitrary files. OpenKM includes a content repository, Lucene indexing, and jBPM workflow. The OpenKM system was developed using Java technology. In 2005 two developers involved in open source technologies and expertise with some commercial document management solutions (Sharepoint, Documentum, Hummingbird, among others) like Excalibur search engine or Kofax OCR engine decided to start an open source project based on high level technologies to build a document management system that they decided to call OpenKM. "-Wikipedia" -Reference: http://en.wikipedia.org/wiki/OpenKM <http://s.bl-1.com/h/mQ2bYKv?url=http://en.wikipedia.org/wiki/OpenKM> -Vulnerability: Remote Reflected/Stored Cross Site Scripting with no remote interaction -Severity: Very Critical -Vulnerable Parameter(s)/Input(s): Tasks -Info: https://www.owasp.org/index.php/Cross-site_Scripting_%28XSS%29 <http://s.bl-1.com/h/mQ2cfkx?url=https://www.owasp.org/index.php/Cross-site_Scripting_%28XSS%29> -Impact: Remote Admin or Users Full Account Takeover with no interaction. -Attack Scenario: 1. User#1 "Attacker" : Creates a task with a vulnerable name and assign it to another User/Admin "Targeted Victim". 2. User#2 "Victim" : Got Exploited with the vulnerable Task made by the Attacker "User#1" since the Task notification will automatically appears to the assigned user side "Victim" also the notification popup displays the vulnerable task name and the victim will be exploited with no interactions. -PS: This is the most critical attack you will see on OpenKM platform because it will work remotely against users even with the same scenario described in the report you can steal/execute a JS in the Administrator's session. -PoC Video: http://youtu.be/3jBQFAAq23k Thanks -- *Best Regards**,**,* *Mohamed Abdelbaset Elnoby*Guru Programmer, Information Security Evangelist & Bug Bounty Hunter. LinkedIn <http://s.bl-1.com/h/mQ2ck6z?url=https://www.linkedin.com/in/symbiansymoh>Curriculum Vitae <http://s.bl-1.com/h/mQ2coW1?url=http://goo.gl/cNrVpL> <http://s.bl-1.com/h/mQ2ctv3?url=https://www.linkedin.com/in/symbiansymoh> Facebook <http://s.bl-1.com/h/mQ2cyJ5?url=https://fb.com/symbiansymoh>Twitter <http://s.bl-1.com/h/mQ2c3j7?url=https://twitter.com/symbiansymoh> Source

The Address Resolution Protocol (ARP) is used to resolve IP addresses into MAC addresses (hardware addresses). Computers in a network send messages to each other through MAC addresses. At an initial stage of communication, the computers are only aware of their allocated IP addresses on the network. The ARP plays the role of making an ARP request from the requesting device on the network by querying the IP addresses on a receiving device for a MAC address. The receiving network device replies with an ARP reply for further communication. More technically, ARP resolves from a network layer into a data-link layer of the OSI model. Resolving IP addresses to MAC with the ARP is similar to how the DNS helps resolve IP address to domain names. One major similarity they both have is that they need to do the resolving job on new network connections. In order to speed up the process and avoid a repetition, a cache is stored. There is usually a DNS cache, and with ARP there is an ARP cache stored on the ARP table. ARP spoofing is where an attacker pretends to be another computer on a network by telling the network gateway to request for the victim’s MAC address from his/her machine IP address. The same process is repeated vice versa with the victim, making the victim see the attacker’s IP address as the gateway address ARP replies. The image below illustrates a typical ARP operation: This image is the same as the process above but with an attacker in the picture: At this point of interception, the attacker receives every piece of data meant for the victim from the gateway and vice versa. A default result will be disrupted communication between the victim and the gateway. Packets meant for the victim wouldn’t get to him, and the victim may get suspicious. To prevent this, the attacker forwards packets from the gateway to the victim and does the same thing back to the gateway. Bringing all that to reality! From a Windows machine, running an arp -a command will list a cache of all neighbour IP addresses with their MAC addresses. This works across Mac and Linux the same way, but our victim machine here is Windows. While we can see that the IP address 192.168.1.1 resolves into the d4:ca:6d:fc:43:9f hardware address, the attacker will begin an ARP proxy (spoof) against this address. The ARP cache on the victim PC as seen above consists of dynamic and static entries. To monitor how the victim’s machine is communicating with the gateway, I’ll run a continuous ping from the victim machine to the gateway device with the Windows ping -t command. During this test, the following IP addresses are used: 192.168.216.2 ? Gateway device 192.168.216.129 ? Victim address 192.168.216.130 ? Attacker address The continuous response from the continuous ping means there is a proper connection between the victim PC and the default gateway. Since ARP replies contain MAC address replies from a network device, the attacker’s objective is to flood ARP replies to both the target and the remote host. To achieve this, the arpspoof command line utility is used on a Linux box. The -i switch is used the specify the network interface, -t is for target host, and -r for remote host. Remote host pretends to be the one to be sending the ARP replies, and Target host is the host that receives the reply. arpspoof -i eth0 -t 192.168.216.2 192.168.216.129 The process is repeated inversely to have a bi-directional packet traffic redirection. arpspoof -i eth0 -t 192.168.216.129 192.168.216.2 At this point, the communication between the victim machine and the gateway is lost. We had created a ping to the gateway earlier from the victim machine. Requests being made are now timed out. The attacker enables IP forwarding to allow packets flow from both proxied network devices. That brings back a network communication with a Man-In-The-Middle of the victim and the gateway host. The victim now has a poisoned ARP cache From the figure above it appears that both IP addresses 192.168.216.2 and 192.168.216.130 resolve into the hardware address 00-0C-29-81-19-63 as dynamic entries. Ettercap can also be used to achieve what we have done with arpspoof, but it’s far less painful to do with arpspoof. To use ettercap we would have had to run: ettercap -i interface -Tq -M arp:remote /192.168.216.2/ /192.168.216.129/ ARP Cache Poisoning ARP cache poisoning involves poisoning the cache of a victim user by flooding it with ARP replies containing MAC addresses to a proxy host. This is what has been achieved in the last step above. ARP spoofing is a technique to achieve ARP cache poisoning. At this point, any kind of network interceptions can be done. You could view images from the victim’s browser by using driftnet, grab mails with mailsnarf, URLs with urlsnarf, IM messages with msgsnarf, sniff files from NFS traffic with filesnarf, and intercept packets with wireshark or ettercap. While I had driftnet active on the attacker machine, I opened the contributors page here at InfoSec Institute and got the following: Just to be a more prying attacker, I had a tmux session with mailsnarf, msgsnarf, and urlsnarf monitoring on 3 panes. I won’t show what the end results of those were, as I’d be putting my privacy in jeopardy by doing so. Okay, I will be nice enough to show results from urlsnarf and dsniff: While urlsnarf was grabbing the URLs, I also kept dnsiff monitoring the victim, and there was an FTP authentication attempt that prompted this: Also, the dsniff suite provides more MITM tools including sshmitm, webmitm, and webspy. An old way to achieve something similar but not quite specific enough is to use another tool from the dsniff suite called macof, and oh! I didn’t mention arpspoof is also from the dsniff suite. Macof floods switched LAN ports with random MAC addresses. That looks too noisy, and since it just starts flooding, I only take it for an option when I’m considering ARP spoofing as a Denial-Of-Service asset. ARP spoofing attacks would be impossible if there was an authentication mechanism for ARP replies. Mitigating ARP spoof attacks Prevent duplicate MAC: This can be achieved by using a good Intrusion Detection System (IDS). It can be set to detect large ARP traffics, duplicate MAC, and MAC floods. Taking a closer look at figure 9, there are two IP address entries with same MAC 00-0C-29-81-19-63 which is something to be prevented. Keep track of ethernet/IP address pairings. Arpwatch tool or ArpSNMP comes really handy when trying to use this. It is a Unix utility. Use static ARP entries. As seen above, the affected entries in the victim ARP cache were dynamic entries. Arpwatch and Arpsnmp have been mentioned earlier. Another good tool for a preventive measure on ARP attacks is Arpon. Before discussing arpon further, I will also like to discuss the arping tool. Arping works just like the ping command line utility. Unlike the ping, which checks if hosts are reachable by their domain names or IP addresses and then resolves domain names into IP addresses, the arping resolves pinged IP addresses into MAC addresses and also allows pinging MAC addresses directly with an interface specified with the -i switch. ARPON is a ARP handler inspection tool that secures the ARP. It uses two techniques to achieve this. The SARPI (Static ARP Inspection) and the DARPI (Dynamic ARP inspection). The two techniques protect against both distributed attacks and bi-directional attacks as we have demonstrated with macof and arpspoof. To properly use the bi-directional protection of Arpon, it should be installed on both network devices including the target and remote host, which are our victim machine and the default gateway. For the distributed attack prevention, Arpon should be installed on all machines in the LAN. Arpon has a daemon that runs from boot when installed on a computer. It helps fight against ARP poisoning attacks with the SARPI and DARPI by blocking them, while tools like Arpwatch and Arpsnmp will just point out the attack presence. Conclusion ARP attacks seen involved taking advantage of the fact that the ARP protocol resolves addresses from the network layer of the OSI model to the data-link layer without any form of authentication. By sending excess ARP replies, an attacker can fool a target machine that he can be addressed by the hardware address of another machine in the network. One major way to prevent this is to avoid MAC duplication in the ARP cache. Various tools were mentioned for mitigation but Arpon seems to be the most powerful tool presently. A future with IPv6 may help put an end to attacks like this. Source