Fwd: Urgent message from Ministry of Education on Cyber Security

[Pete Mundy]

For those of you whose principals haven't forwarded it to you yet ;)

Begin forwarded message:

From: Katrina Casey, Acting Secretary for Education <bull...@education.govt.nz>

Subject: Urgent message from Ministry of Education on Cyber Security

Message from Ministry of Education on Cyber Security Background We have been made aware of a number of cyber-attacks that have led to school servers being compromised. Where we become aware that a school’s server is potentially affected, we will contact you immediately. Cybercriminals will attack your servers for a number of reasons however our initial assessment is that it is more likely they are motivated to use them as staging posts for other attacks (eg sending spam) or for pure financial gain (eg ransomware), rather than to illegally obtain school data per se. Recommended action We recommend that you: Firstly check ALL school servers for any signs of compromise, specifically remote access logs, processes consuming high amounts of processor time (potential Bitcoin mining) and unusual outbound communication including software / applications contacting overseas IP addresses. Your IT provider or school IT staff will be best placed to assist with this. We also recommend the following to improve your resilience to cyber-attacks. Enforce a complex password policy and ensure that default passwords for system accounts are changed. Implement two-factor authentication for remote access, such as Remote Desktop Protocol (RDP) and Virtual Private Network (VPN). For more details on VPN go to NetSafe Apply regular updates to applications and operating systems to ensure up to date protection against known vulnerabilities. Restrict accounts with administrative privileges to make it more difficult for an attacker to install malware and gain access to the wider network. Ensure backups are run regularly with separate backups of both data and server images. Check backups on a regular basis to ensure the backups are successful and can be used to restore data. Ensure a secure configuration of servers by blocking or disabling all externally facing services and ports by default, and only enabling those actually required. This can include whitelisting or blocking external access to administration panels and not using default login credentials. Ensure antivirus software is installed and updated regularly and in all cases no later than 7 days from release of an update from the anti-virus provider. Enable comprehensive logging and ensure that at least three months logs are retained and backed up. Logging is critical in a forensic context to establish the cause, extent and duration of any future incident. What to do if a compromise is identified If you identify any signs of compromise, we recommend the following: Immediately isolate the compromised server(s) from the internet. Force a password change for all user accounts, including network accounts. Rebuild the server. Rebuilding the server is crucial to ensure removal of all malware and methods of access created by the attackers. If your school seeks to enlist the services of a security provider to conduct a forensic investigation of the incident, they will require access to the server to conduct analysis prior to the server being rebuilt. If ransomware is identified If you identify ransomware has been installed: Advise the New Zealand Police. Advise Netsafe, using ‘The Orb’ It is strongly recommend that you DO NOT pay the ransom under any circumstances. Undertake the steps outlined above. Forensic analysis The priority is remediation of any compromised servers. For schools that require information on the method in which they were compromised, please contact us via our details below. Schools IT Helpdesk 0800 CALLICT (0800 225 542) or 09 356 3167, email:cal...@tki.org.nz NetSafe has additional information on steps to protect your school from cybercriminals. Information Sharing If you identify any server that has been compromised, we request that you advise the Ministry’s Security and Privacy team via email security...@education.govt.nz. The information that you provide to us will be used to help with advice and guidance for any other affected schools. This information will be shared with appropriate organisations for coordination of response. Contact us at: bull...@education.govt.nz | education.govt.nz | Follow us on Twitter You can update your preferences or unsubscribe from this list You are receiving this email because you are a key school leader and subscribe to the Ministry Bulletin for School Leaders | He Pitopito Kōrero.

[WHS Ict Technician]

Guidance from the Ministry on best practice? They must be reading this forum...

[gre...@staff.cbhs.school.nz]

Regarding separate server image backups: does anyone have a good procedure for testing these?

What springs to mind:

a) Test that you can restore to a new VM; cursory glance at the file system; spot check of application-specific data/configuration.
This would confirm that the backup media was good, the backup was complete and restore-able, and the captured state/point in time was as-expected.
But it wouldn't prove that the machine actually worked.

OR
b) Restore and boot the VM with no network connection; log in locally and perform spot checks as per (a).
This would confirm 95% of operation, but still doesn't prove that the machine works as intended.

OR
c) During a designated testing period, bring down the live server and boot a restored copy, check, then revert.
This would prove application-level operation, but might cause undesired side-effects in relation to other systems (particularly related databases/storage/cloud replication) so could only be used for certain servers.

OR
d) Maintain a segregated testing network capable of running enough of the server infrastructure to live-test any given restored machine at any time.

- Ben.

[flow in]

what do you do? There doesn't seem to be an obvious solution, and best practice guides don't really help (ie, http://www.altaro.com/assets/10-Essential-Best-Practices-for-Virtual-Server-Backups.pdf)

could you restore into a virtualised hyper-v hosting environment?

[Blake Richardson]

There is an article about this in the press this morning, it seems to hint that it is only schools connected to the N4L network.

[Pete Mundy]

[citation needed]
http://www.stuff.co.nz/the-press/news/82112042/dozens-of-new-zealand-schools-hacked-access-put-up-for-online-sale

Yeah, but I'd hardly call it a well researched or well written article. It also refers to N4L as an 'education IT company'! I thought they were a network provider...

And it reports that 'School principals said their networks often contained sensitive information such as contact details, attendance records, and pupils' grades.'. Gee, you don't say. And the sky is blue too, but they left that out?!

[Matthew Strickland]

So it sounds like its brute force / dictionary attacks which is good news in a sense, as everyone is vulnerable to those. (personal accounts, banks etc)

Limiting rate of retry and lockout thresholds helps to start with, and then limiting valid users credentials to just only what they need to reduce the attack surface.

I wonder if its RDC related in these cases?

N4L I regard as a private ISP, sure they offer lots of other services that not everyone takes, but they really are just a network provider like Pete said.

I'm a little more worried about what malware, particularly that can run as local user and has access to local shares. Sure there are lots of things in place to prevent, and obviously backup if things really go wrong, but in my mind if the human user has access to it, something else can too.

Matt

[Patrick Dunford]

That I think is a nonsense. Any school is at risk.

On 15/07/16 08:00, Blake Richardson wrote:

There is an article about this in the press this morning, it seems to hint that it is only schools connected to the N4L network.

--
You received this message because you are subscribed to the Google Groups "Techies for schools" group.
To unsubscribe from this group and stop receiving emails from it, send an email to techies-for-sch...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[flow in]

i wonder if it is related to the teamviewer exploits my security appliance was stopping? lots of BYOD devices were calling russia

[Julian Davison]

Do you talk to the BYOD owners when you notice things like that? Or make a more general announcement?

On Fri, Jul 15, 2016 at 12:26 PM, flow in <i...@westlandhigh.school.nz> wrote:

i wonder if it is related to the teamviewer exploits my security appliance was stopping? lots of BYOD devices were calling russia

--

[flow in]

I send out an email to the school as a whole with links to website explaining the threat. i also disable the affected clients to force them to come and see me, then sit down with them and deal with the malware. I try and time the client disabling for breaks and lunchtimes so as to not disturb teaching. This is done in consultation with senior management so that we all know what is going on. I think that it is really important for senior management to understand the threats we face, given that most non-it people don't need to have a clue.

The reason i'm suspecting malware is because all the schools are with n4l - so a failure in n4l filtering would affect them all. We are with n4l but have our own security appliance. In the couple of years that we've had it, its gone from doing very little to stopping hundreds of events a day. The current trend seems to be malware injection via ads on websites. It may be being paranoid, but i feel that my job has shifted in nature significantly in the last few years, towards security and pro-active disaster mitigation, with the networking and sysadmin roles being less prominent (as we move to cloud services)

[Blake Richardson]

What appliance do you use if you don't mind me asking?

[flow in]

now i wonder if any hackers read this group, and we could be exposing our networks!

We use the MX100 from meraki. It is a bit of a pita - i have a restrictive policy per vlan and manually apply less restrictive ones, as it appears their AD integrated policy assignment is not 100%. But it is otherwise very useful. 

[Patrick Dunford]

They suggested a major issue for BYOD is that it was all running in one network with full access to everything else on that network. BYOD devices getting hacked sounds different from BYOD devices hacking into a school server, if the BYOD is a separate network from the servers then it has less to do with hacking the school's servers and more to do with bandwidth use or other nuisances.

[J B]

Had some cryptoware sneek in which owned the office drive and half of the student drive before it was picked up, wasted right by the AV at the time.

 

As we had shadow copy and limited user accounts by with separate non-login admin accounts for those that needed them rollback was simple but if the user had been running as admin it could have killed the shadow copies and forced us to use backups instead.

 

I also saw the possible N4L link in the media article and wondered if it was a case of schools trusting them a bit too much and not taking their own steps on top of N4L despite n4ls contention that we should all just trust their edge device to keep traffic safe.

 

Sent from my Windows 10 phone

> On 15/07/2016, at 8:00 am, Blake Richardson <bla...@stmargarets.school.nz> wrote:
>
>> There is an article about this in the press this morning, it seems to hint that it is only schools connected to the N4L network.

[flow in]

"BYOD devices getting hacked sounds different from BYOD devices hacking into a school server"

I think that BYOD devices are the way in - students have terrible 'net hygiene, downloading all sorts of app without though. Without careful client segregation, that has to be a quick and easy way in. We have full client separation and tons of security, but even with everything locked down, i dread what a compromised staff machine could do.

even with BYOD devices, it is hard to stop VLAN hopping. How many of us have simple double tagging protection in place? (https://www.nlogic.co/understanding-vlan-hopping-attacks/). We simple don't have the guidance from above on how to do it - each of us has to go and skill up. Who here knows how ruckus, aerohive, aruba, ubiquiti deal with that one problem? Who has dug into their switch capabilities to leverage them to help? As soon as compromised device joins the network, you could have any sort of attack occurring. There's just too much going on, with new threats every day, for any of us to keep up on our own. We need coordination and oversight.

I feel that the Ministry needs to provide PD and best practice guidance for network and system admins in school, plus monitor contracted services to make sure they are following it.

outgoing traffic events, initiated by malware, prevented in the last few weeks, in our small school:

--

Flow In, MA hons Cantab, MSc | ICT Technician | WESTLAND HIGH SCHOOL

Phone: 03 755 6054 | Cell: 022 027 5107 | Fax: 03 755 6269 | i...@westlandhigh.school.nz
PO Box 154, 140 Hampden Street, Hokitika 7842
http://www.westlandhigh.school.nz/

WHAKATERE I Ā TĀTOU HAERENGA - NAVIGATING OUR JOURNEYS

This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system.

--
You received this message because you are subscribed to a topic in the Google Groups "Techies for schools" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/techies-for-schools/5H0dCCyOmFI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to techies-for-sch...@googlegroups.com.

[Patrick Dunford]

The BYOD one is interesting because we think of it in terms of wireless devices but in fact a student with a laptop could plug in a cable to the wall and be on the internal network with an IP address.

It looks to me as though having a VLAN for internal wired access is a possibility that may prove to be necessary, at least in classrooms, with somewhat less restricted access in staff areas.

How far does it go, do you start looking at staff laptops as a risk for hacking your servers, as well?

Linewize has sent out an email saying the BYOD is one risk and the other one is remote access from outside NZ.

[Patrick Dunford]

Did your staff have limited accounts or just students.

One of the schools I work with the staff have been demanding their logins have admin rights to install software.

On 15/07/16 17:42, J B wrote:

[Peter Eaton]

We were affected by Malware/Ransomware that attacked files on shares - which has nothing to do with whether they are a local admin or not.  Ransomware just requires write access to a file unfortunately.

Pete

[Matthew Strickland]

I am looking at implementing 802.1x on the wired network as a ground up approach with a new appliance once most things are documented. Just need to audit all those other wired devices on the network, eftpos, apple TV's etc. Ideally an unauthenticated device gets guest access, probably just gateway but rate limited like the wireless guest account.

Then there is security vs flexibility; I'd like to continue to use PXE/SCCM but that means having ACL/ip-helpers to get to the PXE server for deployment. It also means pre-domain that this network needs access to a DC and Enterprise-CA so the task sequence can join and obtain a cert before authenticating to the correct VLAN. Seems like lots of undoing to get this working?

I don't use AMT but that adds more complexity if using 802.1x

Has anyone opened reporting to SEPM (TCP 8014) or similar for staff computers at home? Using a VPN tunnel?

I just wonder if particularly staff laptops should be able to report externally should something be detected (IPS?) before being reconnected to the school network?

I'm not so interested in remote management or definition updates (staff computers are direct from symantec) but phone home reporting could be useful.

Cryptoware variants are a concern so staff are limited to what they should have access to, rather than blanket wide access. Staff-wide shared drives are a thing of the past. It just means more groups and regular audits depending on the staff member. Versioning, offline backups are the band aids I can think of..

Matt

To unsubscribe from this group and stop receiving emails from it, send an email to techies-for-schools+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Techies for schools" group.

To unsubscribe from this group and stop receiving emails from it, send an email to techies-for-schools+unsub...@googlegroups.com.

[J B]

The tech you are after for the sepm thing is directaccess which gives the laptops a persistent background transparent tunnel back to the school if they have a net connection.

To unsubscribe from this group and stop receiving emails from it, send an email to techies-for-sch...@googlegroups.com.

[Matthew Strickland]

Thanks synack,

Yeah figured there would be something implemented like that. Be useful for staff laptops as those ones returning could cause the most damage.

Matt

On Sunday, 17 July 2016 17:57:57 UTC+12, synack wrote:

The tech you are after for the sepm thing is directaccess which gives the laptops a persistent background transparent tunnel back to the school if they have a net connection.

 

Sent from my Windows 10 phone

 

<snip>

[trevor storr]

Hi All,

for those who have not yet looked, here's the Kapersky report on the incident:

https://securelist.com/files/2016/06/xDedic_marketplace_ENG.pdf

As has been mentioned before it was a brute force attack against windows servers that had RDP accessible via a public ip.  It's been sensible for ages to only have ssh/rdp authenticate via password protected certificates, so to a large extent this particular instance was avoidable.  It would be even better to use the above in combination with a vpn (N4L can arrange this).

xdedic has now resurfaced on tor https://threatpost.com/xdedic-hacked-server-market-resurfaces-on-tor-domain/119205/

There is some evidence that it was actually 170,000 not 70,000 as originally thought.

http://www.pcworld.com/article/3086848/security/hackers-sold-access-to-170000-compromised-servers-many-in-the-us.html

[Alan at Wadestown School]

Trevor, 

that's exactly what I was thinking of posting. There's been discussion here of VLAN hopping, local admin rights, malware detection and lot of other important and worthwhile stuff but all that seems to be beside the point for this incident. If you are responding to RDP requests on the internet, with basic password authentication, and you don't have some mechanism in place to limit unsuccessful attempts, then it's pretty easy for a hacker to use brute force methods that will eventually succeed at logging in.

Alan

[flow in]

> but all that seems to be beside the point for this incident.

 

not really. discussing attack vectors and security weaknesses is pertinent. I'm sure last time someone exploited a public ftp ip, rdp came up as a weakness. Only addressing the _last_ hack is a  great way to be vulnerable, and we are very vulnerable.

[Alan at Wadestown School]

This is my opinion for what it's worth. Preventing a primitive, brute-force, RDP hack from the internet comes under 'doing the basics'. Preventing a vlan-hopping hack comes under 'following best practices'. An issue is that decision-makers, who are often non-technical people, don't normally have the technical knowledge to weigh-up these things. To them it's all just a bewildering assortment of concerning IT issues.

For that reason I think it's valuable to state clearly the reason why this hack was able to succeed. For non-technical people it's actually hard to extract that essential info.

Alan

[flow in]

59% of the servers in the xdedic marketplace were NOT running RDP. If all the NZ servers were, then that's useful information, but choosing to ignore security flaws to 'keep it simple' for management is not valid, its asking for trouble.

https://securelist.com/blog/research/75120/the-tip-of-the-iceberg-an-unexpected-turn-in-the-xdedic-story/?utm_medium=blg&utm_source=kb_post_160621&utm_campaign=ww_promo

[Patrick Dunford]

Network access protection?

[Patrick Dunford]

N4L said the issue they are dumb enough to keep RDP on the default port of 3389. No one is required to use that port for RDP.

[flow in]

"dumb enough"?

ouch. apparently lots of us are dumb enough to use the default vlan, too.

Pretty sure that paper i linked talked about hacks on variant ports, too. 

[Patrick Dunford]

People's servers getting hacked on RDP on port 3389 is quite common, and has been going on forever.

[Julian Davison]

Your typical 'hack' doesn't rely on port number so much as port-traffic.

nmap can usually fairly accurately identify your services-on-non-standard ports - it's effectively useless as a security measure and can only lead to a false sense of safety.

Unprotected services are 'dumb'. Leaving a service on a well known port is, well, irrelevant.

J,

[trevor storr]

I run fail2ban http://www.fail2ban.org/wiki/index.php/Main_Page on my linux servers (along with ssh configured to use pwd protected certs, no pwd login and no root login).  Out of interest, is there a similar programme for windows?

Cheers

trevor

[flow in]

That looks handy. I limit incoming staff connections to secured l2tp vpns, to reduce exposure, but the web services are a weak point - especially KAMAR's portal, imo. Be good to have something watching it like a hawk.

On 19 July 2016 at 16:51, trevor storr <tre...@storr.org.nz> wrote:

http://www.fail2ban.org/wiki/index.php/Main_Page

[flow in]

just a heads up, We had a hit on our web servers from china, yesterday: ip address 202.199.184.44