Nytro

Kali Linux 2017.3 Release November 21, 2017dookieKali Linux Releases We are pleased to announce the immediate availability of Kali Linux 2017.3, which includes all patches, fixes, updates, and improvements since our last release. In this release, the kernel has been updated to 4.13.10 and it includes some notable improvements: CIFS now uses SMB 3.0 by default EXT4 directories can now contain 2 billion entries instead of the old 10 million limit TLS support is now built into the kernel itself In addition to the new kernel and all of the updates and fixes we pull from Debian, we have also updated our packages for Reaver, PixieWPS, Burp Suite, Cuckoo, The Social Engineering Toolkit, and more. Take a look at the Kali Changelog to see what else has been updated in this release, or read on to see what else is new. New Tool Additions Since our last release in September, we’ve added four new tools to the distribution, most of which focus on the always-lucrative open source information gathering. These new tools are not included in the default installation but after an ‘apt update’, you can check out and install the ones that interest you. We, of course, think they’re all interesting and hope you do as well. InSpy InSpy is a small but useful utility that performs enumeration on LinkedIn and can find people based on job title, company, or email address. root@kali:~# apt update && apt -y install inspy root@kali:~# inspy --empspy /usr/share/inspy/wordlists/title-list-large.txt google InSpy 2.0.3 2017-11-14 14:04:47 53 Employees identified 2017-11-14 14:04:47 Birkan Cara Product Manager at Google 2017-11-14 14:04:47 Fuller Galipeau Google 2017-11-14 14:04:47 Catalina Alicia Esrat Account Executive at Google 2017-11-14 14:04:47 Coplan Pustell Recruiter at Google 2017-11-14 14:04:47 Kristin Suzanne Lead Recruiter at Google 2017-11-14 14:04:47 Baquero Jahan Executive Director at Google 2017-11-14 14:04:47 Jacquelline Bryan VP, Google and President of Google.org 2017-11-14 14:04:47 Icacan M. de Lange Executive Assistant at Google ... CherryTree The oft-requested CherryTree has now been added to Kali for all of your note-taking needs. CherryTree is very easy to use and will be familiar to you if you’ve used any of the “big-name” note organization applications. root@kali:~# apt update && apt -y install cherrytree Sublist3r Sublist3r is a great application that enables you to enumerate subdomains across multiple sources at once. It has integrated the venerable SubBrute, allowing you to also brute force subdomains using a wordlist. root@kali:~# apt update && apt -y install sublist3r root@kali:~# sublist3r -d google.com -p 80 -e Bing ____ _ _ _ _ _____ / ___| _ _| |__ | (_)___| |_|___ / _ __ \___ \| | | | '_ \| | / __| __| |_ \| '__| ___) | |_| | |_) | | \__ \ |_ ___) | | |____/ \__,_|_.__/|_|_|___/\__|____/|_| # Coded By Ahmed Aboul-Ela - @aboul3la [-] Enumerating subdomains now for google.com [-] Searching now in Bing.. [-] Total Unique Subdomains Found: 46 [-] Start port scan now for the following ports: 80 ads.google.com - Found open ports: 80 adwords.google.com - Found open ports: 80 analytics.google.com - Found open ports: 80 accounts.google.com - Found open ports: 80 aboutme.google.com - Found open ports: 80 adssettings.google.com - Found open ports: 80 console.cloud.google.com - Found open ports: 80 ... OSRFramework Another excellent OSINT tool that has been added to the repos is OSRFramework, a collection of scripts that can enumerate users, domains, and more across over 200 separate services. root@kali:~# apt update && apt -y install osrframework root@kali:~# searchfy.py -q "dookie2000ca" ___ ____ ____ _____ _ / _ \/ ___|| _ \| ___| __ __ _ _ __ ___ _____ _____ _ __| | __ | | | \___ \| |_) | |_ | '__/ _` | '_ ` _ \ / _ \ \ /\ / / _ \| '__| |/ / | |_| |___) | _ <| _|| | | (_| | | | | | | __/\ V V / (_) | | | < \___/|____/|_| \_\_| |_| \__,_|_| |_| |_|\___| \_/\_/ \___/|_| |_|\_ Version: OSRFramework 0.17.2 Created by: Felix Brezo and Yaiza Rubio, (i3visio) searchfy.py Copyright (C) F. Brezo and Y. Rubio (i3visio) 2014-2017 This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. For additional info, visit https://www.gnu.org/licenses/agpl-3.0.txt 2017-11-14 14:54:52.535108 Starting search in different platform(s)... Relax! Press <Ctrl + C> to stop... 2017-11-14 14:55:04.310148 A summary of the results obtained are listed in the following table: Sheet Name: Profiles recovered (2017-11-14_14h55m). +---------------------------------+---------------+------------------+ | i3visio_uri | i3visio_alias | i3visio_platform | +=================================+===============+==================+ | http://github.com/dookie2000ca | dookie2000ca | Github | +---------------------------------+---------------+------------------+ | http://twitter.com/dookie2000ca | dookie2000ca | Twitter | +---------------------------------+---------------+------------------+ 2017-11-14 14:55:04.327954 You can find all the information collected in the following files: ./profiles.csv 2017-11-14 14:55:04.328012 Finishing execution... Total time used: 0:00:11.792904 Average seconds/query: 11.792904 seconds Did something go wrong? Is a platform reporting false positives? Do you need to integrate a new one and you don't know how to start? Then, you can always place an issue in the Github project: https://github.com/i3visio/osrframework/issues Note that otherwise, we won't know about it! Massive Maltego Metamorphosis One of our favourite applications in Kali has always been Maltego, the incredible open-source information gathering tool from Paterva, and the equally incredible Casefile. These two applications had always been separate entities (get it?) but as of late September, they are now combined into one amalgamated application that still allows you to run Maltego Community Edition and Casefile, but now it also works for those of you with Maltego Classic or Maltego XL licenses. As always, the tools perform wonderfully and look great doing it. Get the Goods As usual, we have updated our standard ISO images, VMware and VirtualBox virtual machines, ARM images, and cloud instances, all of which can be found via the Kali Downloads page. If you find any bugs, please open a ticket on our bug tracker. We keep an eye on social media but there is no substitute for a well-written bug report and many bugs that get reported to us end up getting fixed in Debian, which then benefits all of its derivatives. Sursa: https://www.kali.org/releases/kali-linux-2017-3-release/

Probabil daca o sa crape emag, o sa vedeti asta:

La Altex a inceput. Eu am gasit ceva ce cautam cu 200 RON mai ieftin, redus de la 700 la 500.

Ati avut azi probleme cu reteaua telefonica? Aveti Telekom? Eu am patit sa ma sune cineva si sa aud pe altcineva. Si alte persoane au patit la fel. Stie cineva ce se intampla?

1. Descarcati APK-ul de la eMag. 2. Uitati-va prin el M-am uitat putin aseara, functionalitatea de BlackFriday e implementata. Nu am gasit URL undeva vizibil, poate sa nici nu fie, dar daca veti cauta dupa "[bB][fF]" o sa gasiti cate ceva.

https://www.amazon.com/Serious-Cryptography-Practical-Introduction-Encryption/dp/1593278268

RST a fost mentionat in (cel putin) doua dintre prezentarile de la Defcamp: - @TheTime - @Matasareanu

O zi de munca mai putin.

VeraCrypt ar trebui sa fie versiunea continuata a TrueCrypt (care fixeaza problemele gasite in TrueCrypt): https://www.veracrypt.fr/en/Home.html Daca vrei modul "hardcore", OpenSSL iti ofera tot ce iti trebuie.

Poate sa arate cum vrei tu cat timp inveti sa: 1. Specifici un fisier (care sa arate cum vrei tu) pe un server 2. Sa te conectezi la server si sa citesti acel fisier (care sa contina ultima versiune si sa o compari cu versiunea actuala) 3. Sa afisezi un mesaj (care sa arate cum vrei tu) de "New update available: Download /Cancel" 4. Sa descarci un fisier (in cazul in care se vrea Download) folosind un progressbar (aici poate deveni mai dificil, dar cred ca gasesti multe exemple utile) 5. Sa instalezi noua versiune

Sincer, nu ma pricep (desi m-am gandit si eu sa imi iau si urma sa fac putin research), dar am inteles ca Nikon D3*** si D5*** sunt pentru incepatori, foarte bune. De asemenea mi s-a spus sa aleg D5*** in locul unui D3*** daca am posibilitatea. Am cativa prieteni pasionati de fotografie.

"using 111 compromised unique certificates issued by recognized CAs and used to sign legitimate software" Acele CA-uri par sa fie importante: Thawte, VeriSign... Oare chiar au pus mana pe cheile private ale root CA-urilor? Nu cred, as merge mai degraba pe coliziuni de hash-uri. "The trio researchers—Doowon Kim, BumJun Kwon and Tudor Dumitras from the University of Maryland, College Park—said they found a total of 325 signed malware samples, of which 189 (58.2%) carried valid digital signatures while 136 carry malformed digital signatures." Avem si romani (asa suna numele) care fac treaba.

Sunt diferente semnificative cand vine vorba de fotografii in coditii de lumina scazuta. DxOMark nu se adreseaza utilizatorilor incepatori, dar cu cateva cunostiinte de nivel mediu legate de o camera, poti sa intelegi cam care ar fi diferentele si pe ce sa mergi mai departe. De asemenea, multe camere frontale (inclusiv iPhone) nu sunt tocmai excelente. Din punctul meu de vedere, camera e unul dintre cele mai importante lucruri cand vine vorba de un telefon. Chiar daca pe Facebook o sa arate nasol, cel putin daca le savezi si te uiti peste ani la ele, o sa ai niste fotografii de calitate. In plus, nu mai trebuie sa cari o camera foto (compacta) ca sa faci poze decente cand calatoresti.

Nikon D5300? Sau D3400?

Din punct de vedere "security", as merge pe iPhone. Insa e cam limitat cand vine vorba de functionalitati. Toate telefoanele enumerate stau bine la capitolul "Camera": https://www.dxomark.com/category/mobile-reviews/ Iar despre procesor, RAM etc., suntem in perioada in care un telefon bun nu ar trebui sa aiba astfel de probleme.

Ce telefon v-ati dori? Am facut un poll, sunt curios ca ce pareri sunt pe aici.

Azi e ultima zi in care puteti lua bilet la pret mai mic.

Da, acolo l-am prezentat, mersi. Momentan, din cand in cand mai lucrez la el. Daca aveti sugestii, sau daca are probleme, puteti posta aici si ma ocup cand am timp de ele.

La pagina de Speakers: .ts-speaker-image img { height: 200px; width: auto; margin-left: auto; margin-right: auto; } Lipsesc acele "margin-*". @Andrei , pentru cei cu OCD.

Am adaugat suport pentru Chrome 62.

Stupid. Toate firmele de AV (de exemplu) pot sa isi instaleze un Root CA si gata.

Unde ai gasit acea legatura cu codette? PS: De la 1 noiembrie cresc preturile, sugestia mea ar fi sa luati bilete mai devreme: https://def.camp/tickets/

ASLRay Linux ELF x32 and x64 ASLR bypass exploit with stack-spraying Properties: ASLR bypass Cross-platform Minimalistic Simplicity Unpatchable Dependencies: Linux 2.6.12+ - would work on any x86-64 Linux-based OS BASH - the whole script Limitations: Stack needs to be executable (-z execstack) Binary has to be exploited through arguments locally (not file, socket or input) No support for other architectures and OSes (TODO) Need to know the buffer limit/size Sursa: https://github.com/cryptolok/ASLRay#aslray

Introducing New Packing Method: First Reflective PE Packer Amber October 24, 2017 Ege Balci Operating System, Research, Tools Because of the increasing security standards inside operating systems and rapid improvements on malware detection technologies today’s malware authors takes advantage of the transparency offered by in-memory execution methods. In-memory execution or fileless execution of a PE file can be defined as executing a compiled PE file inside the memory with manually performing the operations that OS loader supposed to do when executing the PE file normally. In-memory execution of a malware facilitates the obfuscation and anti-emulation techniques. Additionally the malware that is using such methods leaves less footprints on the system since it does not have to possess a file inside the hard drive. Combining in-memory execution methods and multi stage infection models allows malware to infect systems with very small sized loader programs; only purpose of a loader is loading and executing the actual malware code via connecting to a remote system. Using small loader codes are hard to detect by security products because of the purpose and the code fragments of loaders are very common among legitimate applications. Malware that are using this approach can still be detected with scanning the memory and inspecting the behaviors of processes but in terms of security products these operation are harder to implement and costly because of the higher resource usage (Ramilli, 2010[1]). Current rising trend on malware detection technologies is to use the machine learning mechanisms to automate the detection of malwares with feeding very big datasets into the system, as in all machine learning applications this mechanism gets smarter and more accurate in time with absorbing more samples of malware. These mechanisms can feed large numbers of systems that human malware analysts can’t scale. Malware Detection Using Machine Learning[2]paper by Gavriluţ Dragoş from BitDefender Romania Labs widely explains the inner workings of machine learning usage on malware detection. According to the Automatic Analysis of Malware Behavior using Machine Learning[3] paper by Konrad Rieck, with enough data and time false positive results will get close to zero percent and deterministic detection of malware will be significantly effective on new and novel malware samples. The main purpose of this work is developing a new packing methodology for PE files that can alter the way of delivering the malware to the systems. Instead of trying to find new anti-detection techniques that feed the machine learning data-sets, delivering the payload to the systems via fileless code injections directly bypasses most of the security mechanisms. With this new packing method it is possible to convert compiled PE files into multi stage infection payloads that can be used with common software vulnerabilities such as buffer overflows. Known Methods Following techniques are inspiration point of our new packing method. Reflective DLL Injection[4] is a great library injection technique developed by Stephen Fewer and it is the main inspiration point for developing this new packer named as Amber. This technique allows in-memory execution of a specially crafted DLL that is written with reflective programming approach. Because of the adopted reflective programming approach this technique allows multi stage payload deployment. Besides the many advantages of this technique it has few limitations. First limitation is the required file format, this technique expects the malware to be developed or recompiled as a DLL file, and unfortunately in most cases converting an already compiled EXE file to DLL is not possible or requires extensive work on the binary. Second limitation is the need for relocation data. Reflective DLL injection technique requires the relocation data for adjusting the base address of the DLL inside the memory. Also this method has been around for a long time, this means up to date security products can easily detect the usage of Reflective DLL injection. Our new tool, Amber will provide solutions for each of these limitations. Process Hollowing[5] is another commonly known in-memory malware execution method that is using the documented Windows API functions for creating a new process and mapping an EXE file inside it. This method is popular among crypters and packers that are designed to decrease the detection rate of malwares. But this method also has several drawbacks. Because of the Address Space Layout Randomization (ASLR) security measure inside the up-to-date Windows operating systems, the address of memory region when creating a new process is randomized, because of this process hollowing also needs to implement image base relocation on up-to-date Windows systems. As mentioned earlier, base relocation requires relocation data inside PE files. Another drawback is because of the usage of specific file mapping and process creation API functions in specific order this method is easy to identify by security products. Hyperion[6] is a crypter for PE files, developed and presented by Christian Amman in 2012. It explains the theoretic aspects of runtime crypters and how to implement it. The PE parsing approach in assembly and the design perspective used while developing Hyperion helped us for our POC packer. Technical Details of our new packing method: Amber The fundamental principle of executing a compiled binary inside the OS memory is possible with imitating the PE loader of the OS. On Windows, PE loader does many important things, between them mapping a file to memory and resolving the addresses of imported functions are the most important stages for executing a EXE file. Current methods for executing EXE files in memory uses specific windows API functions for mimicking the windows PE loader. Common approach is to create a new suspended process with calling CreateProcess windows API function and mapping the entire EXE image inside it with the help of NtMapViewOfSection, MapViewOfFileand CreateFileMapping functions. Usage of such functions indicates suspicious behavior and increases the detection possibility of the malware. One of the key aspects while developing our packer is using less API functions as possible. In order to avoid the usage of suspicious file mapping API functions our packer uses premapped PE images moreover execution of the malware occurs inside of the target process itself without using the CreateProcess windows API function. The malware executed inside the target process is run with the same process privileges because of the shared _TEB block which is containing the privilege information and configuration of a process. Amber has 2 types of stub, one of them is designed for EXE files that are supporting the ASLR and the other one is for EXE files that are stripped or doesn’t have any relocation data inside. The ASLR supported stub uses total of 4 windows API calls and other stub only uses 3 that are very commonly used by majority of legitimate applications. ASLR Supported Stub: VirtualAlloc CreateThread LoadLibraryA GetProcAddress Non-ASLR Stub: VirtualProtect LoadLibraryA GetProcAddress In order to call these API’s on runtime Amber uses a publicly known EAT parsing technique that is used by Stephen Fewer’s Reflective DLL injection[4] method. This technique simply locates the InMemoryOrderModuleList structure with navigating through Process Environment Block (PEB) inside memory. After locating the structure it is possible to reach export tables of all loaded DLLs with reading each _LDR_DATA_TABLE_ENTRY structure pointed by the InMemoryOrderModuleList. After reaching the export table of a loaded DLL it compares the previously calculated ROR (rotate right) 13 hash of each exported function name until a match occurs. Amber’s packing method also provides several alternative windows API usage methods, one of them is using fixed API addresses, this is the best option if the user is familiar on the remote process that will host the Amber payload. Using fixed API addresses will directly bypass the latest OS level exploit mitigations that are inspecting export address table calls also removing API address finding code will reduce the overall payload size. Another alternative techniques can be used for locating the addresses of required functions such as IAT parsing technique used by Josh Pitts in “Teaching Old Shellcode New Tricks”[7] presentation. Current version of Amber packer versions only supports Fixed API addresses and EAT parsing techniques but IAT parsing will be added on next versions. Generating the Payload For generating the actual Amber payload first packer creates a memory mapping image of the malware, generated memory mapping file contains all sections, optional PE header and null byte padding for unallocated memory space between sections. After obtaining the mapping of the malware, packer checks the ASLR compatibility of the supplied EXE, if the EXE is ASLR compatible packer adds the related Amber stub if not it uses the stub for EXE files that has fixed image base. From this point Amber payload is completed. Below image describes the Amber payload inside the target process, ASLR Stub Execution Execution of ASLR supported stub consists of 5 phases, Base Allocation Resolving API Functions Base Relocation Placement Of File Mapping Execution At the base allocation phase stub allocates a read/write/execute privileged memory space at the size of mapped image of malware with calling the VirtualAlloc windows API function, This memory space will be the new base of malware after the relocation process. In the second phase Amber stub will resolve the addresses of functions that is imported by the malware and write the addresses to the import address table of the mapped image of malware. Address resolution phase is very similar to the approach used by the PE loader of Windows, Amber stub will parse the import table entries of the mapped malware image and load each DLL used by the malware with calling the LoadLibraryA windows API function, each _IMAGE_IMPORT_DESCRIPTOR entry inside import table contains pointer to the names of loaded DLL’s as string, stub will take advantage of existing strings and pass them as parameters to the LoadLibraryA function, after loading the required DLL Amber stub saves the DLL handle and starts finding the addresses of imported functions from the loaded DLL with the help of GetProcAddress windows API function, _IMAGE_IMPORT_DESCRIPTOR structure also contains a pointer to a structure called import names table, this structure contains the names of the imported functions in the same order with import address table(IAT), before calling the GetProcAddress function Amber stub passes the saved handle of the previously loaded DLL and the name of the imported function from import name table structure. Each returned function address is written to the malwares import address table (IAT) with 4 padding byte between them. This process continuous until the end of the import table, after loading all required DLL’s and resolving all the imported function addresses second phase is complete. At the third phase Amber stub will start the relocation process with adjusting the addresses according to the address returned by the VirtualAlloc call, this is almost the same approach used by the PE loader of the windows itself, stub first calculates the delta value with the address returned by the VirtualAlloc call and the preferred base address of the malware, delta value is added to the every entry inside the relocation table. In fourth phase Amber stub will place the file mapping to the previously allocated space, moving the mapped image is done with a simple assembly loop that does byte by byte move operation. At the final phase Amber stub will create a new thread starting from the entry point of the malware with calling the CreateThread API function. The reason of creating a new thread is to create a new growable stack for the malware and additionally executing the malware inside a new thread will allow the target process to continue from its previous state. After creating the malware thread stub will restore the execution with returning to the first caller or stub will jump inside a infinite loop that will stall the current thread while the malware thread successfully runs. Non-ASLR Stub Execution Execution of Non-ASLR supported stub consists of 4 phases, Base Allocation Resolving API functions Placement Of File Mapping Execution If the malware is stripped or has no relocation data inside there is no other way than placing it to its preferred base address. In such condition stub tries to change the memory access privileges of the target process with calling VirtualProtect windows API function starting from image base of the malware through the size of the mapped image. If this condition occurs preferred base address and target process sections may overlap and target process will not be able to continue after the execution of Amber payload. Fixed Amber stub may not be able to change the access privileges of the specified memory region, this may have multiple reasons such as specified memory range is not inside the current process page boundaries (reason is most probably ASLR) or the specified address is overlapping with the stack guard regions inside memory. This is the main limitation for Amber payloads, if the supplied malware don’t have ASLR support (has no relocation data inside) and stub can’t change the memory access privileges of the target process payload execution is not possible. In some situations stub successfully changes the memory region privileges but process crashes immediately, this is caused by the multiple threads running inside the overwritten sections. If the target process owns multiple threads at the time of fixed stub execution it may crash because of the changing memory privileges or overwriting to a running section. However these limitations doesn’t matter if it’s not using the multi stage infection payload with fixed stub, current POC packer can adjust the image base of generated EXE file and the location of Amber payload accordingly. If the allocation attempt ends up successful first phase is complete. Second phase is identical with the approach used by the ASLR supported stub. After finishing the resolution of the API addresses, same assembly loop used for placing the completed file mapping to the previously amended memory region. At the final phase stub jumps to the entry point of the malware and starts the execution without creating a new thread. Unfortunately, usage of Non-ASLR Amber stub does not allow the target process to continue with its previous state. Multi Stage Applications Security measures that will be taken by operating systems in the near future will shrink the attack surface even more for malwares. Microsoft has announced Windows 10 S on May 2 2017[8], this operating system is basically a configured version of Windows 10 for more security, one of the main precautions taken by this new operating system is doesn’t allow to install applications other than those from Windows Store. This kind of white listing approach adopted by the operating systems will have a huge impact on malwares that is infecting systems via executable files. In such scenario usage of multi stage in-memory execution payloads becomes one of the most effective attack vectors. Because of the position independent nature of the Amber stubs it allows multi stage attack models, current POC packer is able to generate a stage payload from a complex compiled PE file that can be loaded and executed directly from memory like a regular shellcode injection attack. In such overly restrictive systems multi stage compatibility of Amber allows exploitation of common memory based software vulnerabilities such as stack and heap based buffer overflows. However due to the limitations of the fixed Amber stub it is suggested to use ASLR supported EXE files while performing multi stage infection attacks. Stage payloads generated by the POC packer are compatible with the small loader shellcodes and payloads generated from Metasploit Framework [9], this also means Amber payloads can be used with all the exploits inside the Metasploit Framework [9] that is using the multi stage meterpreter shellcodes. Here is the source code of Amber . Feel free to fork and contribute..! https://github.com/EgeBalci/Amber Demo 1 – Deploying EXE files through metasploit stagers This video demonstrates how to deploy regular EXE files into systems with using the stager payloads of metasploit. The Stage.exe file generated from Metasploit fetches the amber’s stage payload and executes inside the memory. Demo 2 – Deploying fileless ransomware with Amber ( 3 different AV ) This video is a great example of a possible ransomware attack vector. With using amber, a ransomware EXE file packed and deployed to a remote system via fileless powershell payload. This attack can also be replicated with using any kind of buffer overflow vulnerability. Detection Rate Current detection rate (19.10.2017) of the POC packer is pretty satisfying but since this is going to be a public project current detection score will rise inevitably When no extra parameters passed (only the file name) packer generates a multi stage payload and performs an basic XOR cipher with a multi byte random key then compiles it into a EXE file with adding few extra anti detection functions. Generated EXE file executes the stage payload like a regular shellcode after deciphering the payload and making the required environmental checks. This particular sample is the mimikatz.exe (sha256 – 9369b34df04a2795de083401dda4201a2da2784d1384a6ada2d773b3a81f8dad) file packed with a 12 byte XOR key (./amber mimikatz.exe -ks 12). The detection rate of the mimikatz.exe file before packing is 51/66 on VirusTotal. In this particular example packer uses the default way to find the windows API addresses witch is using the hash API, avoiding the usage of hash API will decrease the detection rate. Currently packer supports the usage of fixed addresses of IAT offsets also next versions will include IAT parser shellcodes for more alternative API address finding methods. VirusTotal https://www.virustotal.com/#/file/3330d02404c56c1793f19f5d18fd5865cadfc4bd015af2e38ed0671f5e737d8a/detection VirusCheckmate Result http://viruscheckmate.com/id/1ikb99sNVrOM NoDistribute https://nodistribute.com/result/image/7uMa96SNOY13rtmTpW5ckBqzAv.png Future Work This work introduces a new generation malware packing methodology for PE files but does not support .NET executables, future work may include the support for 64 bit PE files and .NET executables. Also in terms of stealthiness of this method there can be more advancement. Allocation of memory regions for entire mapped image done with read/write/execute privileges, after placing the mapped image changing the memory region privileges according to the mapped image sections may decrease the detection rate. Also wiping the PE header after the address resolution phase can make detection harder for memory scanners. The developments of Amber POC packer will continue as a open source project. References [1] Ramilli, Marco, and Matt Bishop. “Multi-stage delivery of malware.” Malicious and Unwanted Software (MALWARE), 2010 5th International Conference on. IEEE, 2010. [2] Gavriluţ, Dragoş, et al. “Malware detection using machine learning.” Computer Science and Information Technology, 2009. IMCSIT’09. International Multiconference on. IEEE, 2009. [3] Rieck, Konrad, et al. “Automatic analysis of malware behavior using machine learning.” Journal of Computer Security 19.4 (2011): 639-668. [4] Fewer, Stephen. “Reflective DLL injection.” Harmony Security, Version 1 (2008). [5] Leitch, John. “Process hollowing.” (2013). [6] Ammann, Christian. “Hyperion: Implementation of a PE-Crypter.” (2012). [7] Pitts, Josh. “Teaching Old Shellcode New Tricks” https://recon.cx/2017/brussels/resources/slides/RECON-BRX-2017 Teaching_Old_Shellcode_New_Tricks.pdf (2017) [8] https://news.microsoft.com/europe/2017/05/02/microsoft-empowers-students-and-teachers-with-windows-10-s-affordable-pcs-new-surface-laptop-and-more/ [9] Rapid7 Inc, Metasploit Framework https://www.metasploit.com [10] Desimone, Joe. “Hunting In Memory” https://www.endgame.com/blog/technical-blog/hunting-memory (2017) [11] Lyda, Robert, and James Hamrock. “Using entropy analysis to find encrypted and packed malware.” IEEE Security & Privacy 5.2 (2007). [12] Nasi, Emeric. “PE Injection Explained Advanced memory code injection technique” Creative Commons Attribution-NonCommercial-NoDerivs 3.0 License (2014) [13] Pietrek, Matt. “Peering Inside the PE: A Tour of the Win32 Portable Executable File Format” https://msdn.microsoft.com/en-us/library/ms809762.aspx (1994) Sursa: https://pentest.blog/introducing-new-packing-method-first-reflective-pe-packer/

Exploiting Misconfigured CORS October 25, 2017 Hi folks, This post is about some of the CORS misconfiguration which I see frequently, mostly in Django applications. Let’s assume all the test cases have been performed on the domain example.com Following are the most common CORS configurations • Access-Control-Allow-Origin: * • Remark: In this case we can fetch unauthenticated resources only. • Access-Control-Allow-Origin: * Access-Control-Allow-Credentials: true • Remark: In this case we can fetch unauthenticated resources only. • Access-Control-Allow-Origin: null Access-Control-Allow-Credentials: true • Remark: In this case we can fetch authenticated resources as well. • Access-Control-Allow-Origin: https://attacker.com Access-Control-Allow-Credentials: true • Remark: In this case we can fetch authenticated resources as well. • Access-Control-Allow-Origin: https://example.com Access-Control-Allow-Credentials: true • Remark: Properly implemented So we usually see these type of CORS configuration in response headers and most of us don’t try to exploit it because we think it’s properly implemented. But that’s not true. Let’s study some of the weird CORS misconfiguration cases. • I have found this vulnerability in one of most popular python web hosting site which has following request and response headers shown below - Original Request and response headers GET /<redacted> HTTP/1.1 Host: dummy.example.com User-Agent: <redacted> Accept: */* Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Referer: <redacted> Origin: https://www.example.com Connection: close HTTP/1.1 200 OK Server: <redacted> Date: <redacted> Content-Type: application/json; charset=UTF-8 Content-Length: 87 Connection: close Cache-Control: no-store, no-cache, must-revalidate, max-age=0 Access-Control-Allow-Credentials: true Access-Control-Allow-Origin: https://www.example.com Strict-Transport-Security: max-age=31536000; So looking at the response headers, you can see CORS is implemented correctly and most of us don’t test it further. At this point most of time I have seen that by changing the value of origin header would reflect back in response headers as following. Edited Request and response headers GET /<redacted>HTTP/1.1 Host: dummy.example.com User-Agent: <redacted> Accept: */* Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Referer: <redacted> Origin: https://attacker.com Connection: close HTTP/1.1 200 OK Server: <redacted> Date: <redacted> Content-Type: application/json; charset=UTF-8 Content-Length: 87 Connection: close Cache-Control: no-store, no-cache, must-revalidate, max-age=0 Access-Control-Allow-Credentials: true Access-Control-Allow-Origin: https://attacker.com Strict-Transport-Security: max-age=31536000; • I have found this vulnerability in one of the bitcoin website which has the following request and response headers. Original Request and response headers POST /<redacted> HTTP/1.1 Host: <redacted> User-Agent: <redacted> Accept: application/json, text/plain, */* Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate, br Content-Type: application/x-www-form-urlencoded;charset=utf-8 Referer: <redacted> Content-Length: 270 Cookie: <redacted> Connection: close HTTP/1.1 200 OK Server: nginx Date: <redacted> Content-Type: application/json Connection: close Access-Control-Allow-Credentials: true Content-Length: 128 Looking at the response you can see Access-Control-Allow-Origin header is missing so I added origin header in http request which makes it vulnerable as following. Edited Request and response headers POST /<redacted>HTTP/1.1 Host: <redacted> User-Agent: <redacted> Accept: application/json, text/plain, */* Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate, br Content-Type: application/x-www-form-urlencoded;charset=utf-8 Origin: https://attacker.com Referer: <redacted> Content-Length: 270 Cookie: <redacted> Connection: close HTTP/1.1 200 OK Server: nginx Date: <redacted> Content-Type: application/json Connection: close Access-Control-Allow-Origin: https://attacker.com Access-Control-Allow-Credentials: true Content-Length: 128 Thanks for reading Sursa: http://c0d3g33k.blogspot.de/2017/10/exploiting-misconfigured-cors.html?m=1