AUSCERT in Korea for the 2017 APISC/TRANSITS Security Training Course AUSCERT participated in the APISC Security Training Course [1], organised by KrCERT/CC [2], operated by the Korea Internet & Security Agency [3] in the last week of July 2017.  AUSCERT sent a team member to join three (3) other instructors to facilitate the TRANSITS I [4] material to twenty-one (21) recipients CERT/CSIRT from across the globe. Along with the instruction of TRANSITS I material, there were also other CERT/CSIRT exercises and economy reports of CERT/CSIRT operations, that helped share experience in organising and operating CERT/CSIRT.  AUSCERT is honored to have been part of the APISC Security Training Course organised by KrCERT. [1] APISC Security Training Course – Asia Pacific Internet Security Conference Security Training Course. A yearly CERT capacity building initiative from South Korea that is run in conjunction to a yearly conference that bears the same name APISC.  [2] KrCERT/CC – Korean Computer Emergency Response Team / Coordination Centre. KrCERT/CC, created in 2010 and operates as the National CERT for South Korea. KrCERT is managed by KISA. https://www.krcert.or.kr/krcert/intro.do [3] KISA – Korean Internet & Security Agency. KISA sponsored by the South Korean Ministry of Science and ICT, commenced operation in 2009 and is responsible for the private sector of the Internet in South Korea. http://www.kisa.or.kr/eng/main.jsp [4] TRANSITS I. TRANSITS I course, created in 2001 is maintained by members of European CERTs with modules that deal with the Organization, Operation Legal and Technical aspect of CERT/CSIRT operation. https://www.terena.org/activities/transits/transits-i/

How to check if your site is vulnerable to a POODLE attack How to check if your site is vulnerable to a POODLE attack Following the introduction of AUSCERT’s new Member Security Incident Notifications (MSINs), some members have asked us how they can confirm the accuracy of the POODLE reports. This is the incident type with the highest occurrence rate among AUSCERT members. The Padding Oracle On Downgraded Legacy Encryption or POODLE attack can lead to decryption of HTTPS connections between clients and servers by exploiting a weakness in SSL 3.0 with cipher-block chaining (CBC) mode ciphers enabled. While we’re confident that our data sources are high quality, you can use the methods below to manually check your publicly facing services for poodle exposure if you wish. If you believe the information we have provided in the report is incorrect then please let us know. Manual methods for testing poodle exposure Qualys SSL Labs test Note that as at 23 September 2015, the information contained in the SSL Labs report requires careful analysis to interpret correctly. The “Summary” section may indicate “This server uses SSL 3, which is obsolete and insecure” when a poodle attack is possible. Later in the report a line entry may indicate “poodle (SSLv3): No, mitigated” if the service supports a secure protocol upgrade.  However, since this relies upon the client correctly negotiating one of the secure protocols, the service should still be considered vulnerable to poodle attacks. OpenSSL and nmap Use the command-line OpenSSL client and an nmap scan to attempt connection using SSL 3.0 and enumerate available ciphers.  The OpenSSL command just checks if SSLv3 is enabled; nmap returns all possible ciphers with SSL v3, TLS1.0, TLS1.1 or TLS1.2. OpenSSL can be used to check each individual cipher but it would take more time. ~$ openssl s_client -ssl3 -connect your.domain.here:443 A successful connection indicates that SSL 3.0 is enabled and that a poodle attack is possible. ~$ nmap --script ssl-enum-ciphers -p 443 your.domain.here A server should be considered vulnerable to a poodle attack if CBC ciphers are offered while using SSLv3.  Please note that CBC ciphers, AES128-SHA and AES256-SHA, often don’t mention CBC in their names, but their presence does indicate a poodle vulnerable service. If no CBC ciphers are offered then it wouldn’t be vulnerable to a poodle attack (but most other ciphers are vulnerable to different attacks like RC4:BEAST). As you’ll already be aware, there is currently no fix for the vulnerability SSL 3.0 itself therefore disabling SSL 3.0 support is the most viable solution currently available. This means that even with up-to-date patches applied, it is possible to fail a poodle vulnerability scan if SSL 3.0 is still enabled. References and additional information https://www.us-cert.gov/ncas/alerts/TA14-290A https://www.openssl.org/~bodo/ssl-poodle.pdf https://www.ssllabs.com/ssltest https://www.tinfoilsecurity.com/blog/how-to-fix-poodle-and-why-you-are-probably-still-vulnerable

Phone scams targeting a variety of organisations in the Health industry AUSCERT has recently received numerous reports of phone scams targeting a variety of organisations in the Health industry. The exact nature of the unsolicited calls varies but has included conference and event invites, training sessions, and attempts to confirm personal details of the callee or others in the organisation.  The callers have claimed to be associated with varied groups including GE Healthcare (who have been alerted to this), NEOH and the called organisation itself. Organisations should also be aware that fraudsters claiming to be from various GE businesses (including public reports of criminals using the name of GE Healthcare) often commit recruitment fraud and may do so as part of this activity. While phone scams such as these are ever present this recent spate of reports we have received specifically from the Health industry suggests the current need for increased awareness amongst Health industry organisatons. AUSCERT encourages members to review their current security awareness of their staff in relation to phone scams and consider alerting staff to this current activity. Guidelines for staff would include what steps to take when receiving unsolicited calls, the type of information that can and can not be provided, and any reporting guidelines. AUSCERT recommends staff are encouraged to report unsolicited or suspicious calls so that organisations can monitor for concerted attacks. AUSCERT has received reports of numerous calls to the same organisation (and individual) over a very short period of time. Information on what to do should also be provided for staff that have been defrauded or provided personal or organisational information. Useful resources include: https://www.scamwatch.gov.au/ https://www.staysmartonline.gov.au/ http://www.fairtrading.nsw.gov.au/ftw/Businesses/Scams/Business_scams To help gauge how wide spread this activity is AUSCERT would appreciate any feedback from organisations that have been targeted.  

Ongoing ransomware campaign with worm capabilities | Petya For the latest AUSCERT updates on NotPetya / GoldenEye see our bulletin. We will keep it updated as more information becomes available.   ALERT [Win] Ongoing ransomware campaign with worm capabilities “Petya”

DDoS Mitigation Denial of service (DoS) attacks have hit the news in Australia, yet again. But what is a DoS attack? A DoS attack is designed to deny access to a computing resource from its intended users. A distributed DoS (or DDoS) attack is conducted by numerous (could be in the tens of thousands) computers against a single host or network. It’s not possible to prevent DDoS attacks, we can only be prepared to mitigate them. Types of DDoS attacks An attacker may use a stateless protocol like ICMP or UDP with spoofed source addresses, but it is also common for an attack to be carried out with legitimate network traffic (like HTTP GET requests). In the latter case it can be difficult to block malicious traffic without impacting legitimate traffic. A DDoS is commonly directed at a web site, with a sufficiently large number of requests to overwhelm the capacity of the web server to handle them. In extreme cases, the site’s network equipment may be made unavailable by the volume of traffic they are attempting to filter. Preparing for a DDoS attack There are a number of steps that you can take to prepare for a DDoS attack, including: Ensure that senior management is aware of the impact of a DDoS attack and will support your steps to mitigate one Understand your network – knowing what is normal for your network will enable a threshold of activity that indicates the start of a DDoS Keep your OS up to date and hardened – disable any unneeded services Implement firewall measures on your host – an example for linux Implement application protection, like ModSecurity web application firewall and mod_evasive for Apache – note that a large DDoS attack will quickly overwhelm these measures Run a dedicated network firewall that is able to handle a greater load than the one on the host itself Set up your border router with ACLs to allow only valid traffic into your network eg filter bogons and unused protocols Establish contact details for your upstream network provider so that they may be readily contacted in an emergency. Containing a DDoS attack The scale of the attack will determine the effectiveness of mitigation measures. It may be possible to contain the attack on the affected host itself, or it may require upstream filtering. Implement filtering based on the attack eg blocking UDP packets Consider disabling the targeted application until the attack stops Implement rate limiting for network traffic to the target Contact your ISP for traffic filtering Other resources are available; these are recommended reading – Factsheet Technical measures for the continuity of online services, Mitigation Guidelines for Denial-of-Service Attacks and Network DDoS Incident Response Cheat Sheet List of useful links from the blog + one more 1 https://javapipe.com/iptables-ddos-protection2 https://www.modsecurity.org/3 https://www.zdziarski.com/blog/?page_id=442 (andhttps://www.digitalocean.com/community/tutorials/how-to-protect-against-dos-and-ddos-with-mod_evasive-for-apache-on-centos-7)4 https://www.ncsc.nl/english/current-topics/factsheets/factsheet-technical-measures-for-the-continuity-of-online-services.html5 https://www.publicsafety.gc.ca/cnt/rsrcs/cybr-ctr/2012/tr12-001-en.aspx6 https://zeltser.com/ddos-incident-cheat-sheet/