STE WILLIAMS

A Security-First Approach to DevOps

Aware of the risks inherent in software, businesses are recognizing the need for application security.

It has long been common for developers to operate with tunnel vision: Driven by the demand to get their products to market first, security has traditionally been either tacked on at the end or not considered at all.

This lack of a security mandate in the development process has given rise to the recognized need for application security. Some have questioned whether institutionalized security is in order to reshape the software development culture.

While there is some legislation and governance around data loss accountability and liability as a result of a breach, these existing laws are typically regionalized, says Dan Kuykendall, senior director of application security at Rapid7. As a result, they are neither prescriptive nor effectively enforced.

“They also do nothing to promote the idea of building security into the software development culture or incentivize businesses to mandate a security-first approach,” Kuykendall says. “Providing prescriptive guidelines and principles on how to build security into the software development culture and institutionalizing these practices would place everyone on equal footing when it comes to releasing software safely with regard to both liability and innovation.”

Stunted Creativity: Myth or Reality?
Many have bought into the idea that secure software development stymies innovation. Kuykendall agrees that certain security approaches can slow innovation — “particularly if an organization has adopted a continuous integration/continuous deployment [CI/CD] software development process but is unwilling to invest in and adopt security approaches and tools to keep up with the speed of delivery.”  

However, “The CISO’s Ultimate Guide to Securing Applications” report, published by Synopsys, states that the opposite is true: “Finding and fixing application vulnerabilities during development and testing is more efficient and less expensive than doing so at the end of the process, when an application is already in production.”

The key is to synchronize security with the development process. “Automate where you can and integrate into the tools the developers use every day,” Kuykendall advises. Security doesn’t have to impede innovation; when implemented correctly, security can seamlessly integrate as part of the process developers follow and into the tools they use every day.  

Putting Security into DevOps
With DevSecOps, security is at the center of development and operations, ensuring that it is part of the development life cycle. The movement was birthed from a culture of collaboration driven by those who recognize the value of an agile relationship uniting the development, quality engineering, and operations teams.

Integrating security into DevOps begins with a set of processes that foster high levels of communication and collaboration. “Organizations that are getting DevSecOps right are leveraging security as a differentiator to their customers and users,” Kuykendall says. “Developers in a DevSecOps team are more mindful of risk and how their code can introduce unnecessary risk to the business and the individuals using the software they build.”

More and more customers want to see that developers are very much engaged in the security conversation, not only from a “will this solution hold me up” mindset, but with a more strategic vision in mind, according to Kuykendall. “They want to know if the solutions they use will be able to scale and evolve in a way that supports their own growth and innovation,” he says.

Minimizing Risk During Development
According to Verizon’s “2019 Data Breach Investigation Report,” Web applications were among the top three attack patterns that lead to data breaches across every sector. In the professional services industry, “Web Applications, Everything Else, and Miscellaneous Errors represent 81% of breaches,” it states.

As the industry continues to see progress in building more secure applications, a focus on both people and technology will help to advance the DevSecOps movement.

“To address application security before development is complete, it’s essential to build security into your development teams (people), processes, and tools (technology). An increasingly popular term for that is “shift left” — make security part of the software development life cycle (SDLC) from the concept and design stage right through the entire development process to production,” the Synopsys report states.

Aware of the risks inherent in software, businesses are recognizing the need for application security and developing what WhiteHat Security says resembles a “software production line,” according to a 2018 report, “The Evolution of the Secure Software Lifecycle.”

Security organizations that have started to move the needle on application security are “working hand-in-hand with operations to automate security testing, packaging, and delivery of these applications. In concert with this trend, application security testing is becoming embedded into each phase of the Software Production Line rather than getting bolted on at the end,” the report states.

Related Content:

(Image: Adobe Stock)

Kacy Zurkus is a cybersecurity and InfoSec freelance writer as well as a content producer for Reed Exhibition’s security portfolio. Zurkus is a regular contributor to Security Boulevard and IBM’s Security Intelligence. She has also contributed to several publications, … View Full Bio

Article source: https://www.darkreading.com/edge/theedge/a-security-first-approach-to-devops/b/d-id/1335188?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

9 Things That Don’t Worry You Today (But Should)

There are security concerns that go far beyond the usual suspects. Here are some that should be on your list of scary things.PreviousNext

(Image Source: Sergey Nivens via Adobe Stock)

There are lots of things to keep a security professional up at night, from virulent malware to zero-day vulnerabilities to users wildly clicking on every attachment that hits their in-boxes. Unfortunately, the well-known hazards aren’t nearly all that security folks should be worried about.

Constantly expanding capabilities in computing have given rise to a constantly growing list of threat sources. From misapplied technologies that normally serve worthwhile purposes to poor behavior on the part of users (there’s that word, again), security issues abound in places both expected and unexpected.

This time, we’re looking at the “unexpected” side of the ledger. Beginning with a way in which one of the basic tools of transferring and storing files (the .ZIP compression method) and including technologies that should protect you but probably won’t (passwords and OpenPGP) there are plenty of things to think about when it comes to your enterprise security.

For better or for worse — possibly both — this list is not filled with technologies, products, and activities that can simply be carved out of every enterprise activity. It is, for example, highly unlikely that you’ll simply be able to leave passwords in history’s dustbin anytime soon. But that doesn’t mean that you shouldn’t be aware of the various ways in which passwords can fail your organization and make it more vulnerable than you believe it to be.

Security research is ongoing and these items came from a variety of researchers, papers, podcasts, and websites across the Internet. And this list is in no way exhaustive — there are plenty of potentially scary things out there, just waiting to bite security professionals (and their companies) who get a bit too complacent.

So, what are the scary things on your list? We’d like to see the items that you worry about that we didn’t mention. Comments are open and waiting for you to add to the body of scary knowledge at Dark Reading.

 

 

Curtis Franklin Jr. is Senior Editor at Dark Reading. In this role he focuses on product and technology coverage for the publication. In addition he works on audio and video programming for Dark Reading and contributes to activities at Interop ITX, Black Hat, INsecurity, and … View Full BioPreviousNext

Article source: https://www.darkreading.com/threat-intelligence/9-things-that-dont-worry-you-today-(but-should)/d/d-id/1335270?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

As the world secures itself, so do crims: Encrypted malware on the rise, warns Sonicwall

Scanning of random ports and the use of encrypted malware by online criminals is on the rise, according to a threat report by Sonicwall.

By the end of 2018, around 20 per cent of all malware attacks (based on Sonicwall’s sampling of what it says were 700 million such intrusions) were coming through non-standard ports – a sum which had decreased by 13 per cent compared to 2018, it said.

The company explained to The Register that “non standard” meant ports which are not in routine use by other programs, such as ports 80 and 443 for one’s web browser.

“For the first half of 2019, that share dipped to 13 per cent globally due to below-normal volume in January (8 per cent) and February (11 per cent),” Sonicwall chief exec Bill Conner told The Register. He added that in May 2019 a quarter of all his firm’s recorded malware attacks “were coming across non-standard ports, the highest volume since Capture Labs has been tracking the attack vector.”

“Those in charge of malware deployments are certainly cognizant of this blind spot and continue to actively exploit it. Organizations aren’t prepared for protecting this attack vector with the same diligence as standard ports,” added Conner.

Encrypted malware was something else that Sonicwall said was on the rise, increasing by a quarter compared to the preceding 12 months. In 2018 the company said it had logged more than 2.8 million encrypted malware attacks, a 27 per cent jump over the previous year.

The Johannesburg skyline

South Africans shivering in the dark after file-scrambling nasty hits Johannesburg power biz

READ MORE

“So far in 2019, that threat is only accelerating,” said a cheerful Conner. “Through the first six months of 2019, Sonicwall has registered 2.4 million encrypted attacks, almost eclipsing the 2018 full-year total in half the time. This marks a 76 per cent year-to-date increase and hence is only intensifying.”

A variety of factors contributed to this trend, in Sonicwall’s view: Ransomware as a Service (RaaS), open-source malware kits and cryptocurrencies “bounced back up”, the firm said, with ransomware continuing to be a successful money-maker for criminals deploying it.

“I’m certain that a number of high profile ransomware cases involving major US cities also signaled that there are still large vulnerable targets out there despite ransomware being a headline for the past 4-5 years,” bemoaned Conner.

The company also said attacks against IoT devices were up by 55 per cent year-on-year. ®

Sponsored:
Balancing consumerization and corporate control

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2019/07/29/sonicwall_threat_report/

WannaCry hero avoids prison

This article has been removed. It was the opinion of one person and doesn’t reflect the usual style of Naked Security and Sophos.


Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/2E-U5fgwrNI/

Ransomware hits Louisiana schools; state of emergency declared

Louisiana Governor John Bel Edwards on Wednesday declared a state of emergency after three public school districts were seized by ransomware.

According to local news station KSLA, one of the affected school districts, Sabine Parish in northern Louisiana, released this statement on Wednesday night:

The Sabine Parish School System was hit with an electronic virus early Sunday morning. This virus has disabled some of our technology systems and our central office phone system. The district staff reported this electronic viral attack to local law enforcement, state officials and the FBI. All available resources are being utilized to get the district systems back online. An investigation involving local, state and federal law enforcement is ongoing at this time. The school phone systems were not affected by this attack. The central office phone system is being repaired and service will be restored as soon as possible. According to the Louisiana Department of Education, several other school districts were attacked by the same virus this week.

We haven’t seen details yet on what ransomware variant was inflicted in the attack; nor have state officials released a comprehensive list of the affected systems.

Eddie Jones, principal of Florien High School in Sabine Parish, told KSLA that his technology supervisor got an alert on his phone around 4am Sunday about a surge in bandwidth usage. It was particularly unusual given the time of day and the fact that the schools are all on summer break.

When technical staff investigated, Jones said, they found ransomware on the servers.

The principal said that he doesn’t believe that any sensitive information was lost. What was lost: “anything and everything” stored on the school district’s servers, including 17 years’ worth of Jones’ personal documents – his speeches, test schedules, master schedules and more.

The declaration of a state of emergency means that state resources will be made available and that assistance will be coming from cybersecurity experts from the Louisiana National Guard, Louisiana State Police, the Office of Technology Services and others to assist local governments in responding to the crisis and in preventing further data loss.

This is the first time that Louisiana has activated its emergency cybersecurity powers, which were created for just this type of cyberattack. The response is being handled by the state’s newly formed Cyber Security Commission, which was established in 2017. It brings together the state’s key stakeholders, subject matter experts, and cybersecurity professionals from Louisiana’s public sector, private industry, academia, and law enforcement.

The Governor’s Office of Homeland Security and Emergency Preparedness (GOHSEP) has also activated its Crisis Action Team and the Emergency Services Function-17 to coordinate a response.

Governor Edwards:

The state was made aware of a malware attack on a few north Louisiana school systems and we have been coordinating a response ever since. This is exactly why we established the Cyber Security Commission, focused on preparing for, responding to and preventing cybersecurity attacks, and we are well-positioned to assist local governments as they battle this current threat.

Ars Technica put some interesting context around Louisiana’s response: it’s modeled on Colorado’s response in the wake of two SamSam ransomware attacks. The first hit in February 2018, and the second came the following week. The attacks wound up costing the state $1.5 million to disinfect its systems after officials decided against paying nary one thin dime to the attackers.

Declaring an emergency empowered Colorado cybersecurity agencies to ask for help from the National Guard, on top of help from other security companies and the FBI.

The emergency declaration includes protection from being price-gouged for the extra help and resources. Here’s some language concerning that protection, from a Louisiana proclamation about states of emergency:

During a declared state of emergency, the prices charged or value received for goods and services sold within the designated emergency area may not exceed the prices ordinarily charged for comparable goods and services in the same market area at or immediately before the time of the state of emergency, unless the price by the seller is attributable to fluctuations in applicable commodity markets, fluctuations in applicable regional or national market trends, or to reasonable expenses and charges and attendant business risk incurred in procuring or selling the goods or services during the state of emergency.

What to do?

For information about how targeted ransomware attacks work and how to defeat them, check out the SophosLabs 2019 Threat Report.

The bottom line is: if all else fails, you’ll wish you had comprehensive backups, and that they aren’t accessible to attackers who’ve compromised your network. Modern ransomware attacks don’t just encrypt data, they encrypt parts of the computer’s operating system too, so your backup plan needs to account for how you will restore entire machines, not just data.

For more on dealing with ransomware, listen to our Techknow podcast:

(Audio player above not working? Listen on Soundcloud or access via iTunes.)

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/y4LCvRPOoLY/

WannaCry hero gets off lightly, avoids prison – was justice done?

The featured image above comes from @Doctor_Tran’s Twitter feed.

Here is a fascinating story – a morality tale, even.

What follows is quite long, we admit, but we think you’ll find it interesting, informative and intriguing in equal measure.

We’re dealing with a cybercriminal who forged his relationship with the underworld right back in childhood; a technically brilliant manouevre that happened by luck rather than by design; a sudden raft of unwanted attention; the lure of the celebrity spotlight; a VIP trip to Sin City; a dramatic arrest on the cusp of escape; a tidal wave of poor judgment from an unexpected source; two years on bail in the City of Angels; some strange but ultimately accurate premonitions by the antihero in our story…

…and an outcome that few people ever expected, even though many hoped against hope that it might happen.

Like any really good story, it’s more exciting if you start in the middle, so that’s exactly where we’ll jump into it.

The WannaCry era

Think back two years, to May 2017.

That was when the WannaCry malware appeared – and with something like 400,000 distinct new samples a day turning up at SophosLabs, it takes something really unusual or calamitous to make any one of them into a headline hogging story in its own right.

Well, WannaCry was both of those things.

WannaCry was unusual because it was a true virus, or more precisely, a computer worm, capable of spreading from network to network of its own accord, without anyone needing to click, download, import or approve anything.

And it was calamitous because it was ransomware – that fist-in-the-face flavour of malware that scrambles all your precious data files with a randomly chosen encryption key and then almost casually offers to sell the key back to you.

WannaCry asked for the Bitcoin equivalent of about $300 per computer, which may sound cheap by the standards of more recent targeted malware attacks in which the crooks often ask for $8000 to “save” one computer or $50,000 for your whole network.

But remember that WannaCry was a worm, too, and before it scrambled your computer it made a determined effort to infect as many other computers round and about as it could.

We’re assuming that the crooks chose $300 as a price point that many people might actually be willing and able to pay, and hoped to have literally millions of concurrent victims to extort.

Fortunately, the outbreak didn’t work out quite how the crooks had hoped.

SophosLabs estimated that as many as 200,000 computers in 150 countries got hit in the first few days, and our initial fears were that it was going to end up much worse than that.

It didn’t.

The sinkhole

A youngster in the UK going by @MalwareTechBlog, who was working from home for an internet threat monitoring company, spotted an unusual-looking server name hidden away as a text string inside the WannaCry executable file.

He acquired the domain name himself, fired up a server answering to that name, and watched to see what happened.

Note that this wasn’t an act of insight, of inspiration or of technical brilliance – he hadn’t actually decompiled or analysed the malware to figure out what the domain was for.

Indeed, registering and “lighting up” a server name that’s listed in a malware sample without knowing precisely what effect that will have is always a calculated risk.

You could end up being on the receiving end of masses of stolen, confidential exfiltrated data that you shouldn’t really be collecting; you might inadvertently activate a logic bomb in the malware that makes it even more destructive; and so forth.

Nevertheless, registering malware-related domain names is what @MalwareTechBlog and the company he worked for were accustomed to do.

As unscientific and reckless as this might sound, the process of snapping up or taking over malware domains, known by the jargon name of sinkholing, often works out well.

After all, one common purpose for hidden domain names in malware is to provide the crooks with an off-the-radar contact point “for later”, by means of which they can exert what’s known as Command and Control (usually abbreviated to CnC or C2).

If you register their off-the-radar domains before they do, you may be able to stop stolen data getting into their hands, as well as preventing them from using those domains as control servers to keep their zombie networks alive.

You also get a chance to measure how the malware is spreading and behaving, which is often useful threat intelligence, and you may even be able to use the sinkhole to push out warnings to potential victims or stop them suffering further damage.

Set the emergency brake

Time is of the essence, so @MalwareTechBlog did the right thing, for the right reasons…

…but just how right, our soon-to-be-hero was yet to find out.

It turned out that the domain he registered, activated and sinkholed was used by WannaCry as a sort of “emergency brake”.

When the virus loaded up, it tried to contact the mysteriously named server, and only continued with its file-scrambling ransomware attack if the server was not active.

Bingo!

A significant majority of the computers in the world – any of them that had a working internet connection – suddenly acquired what amounted to immunity from WannaCry.

As an aside, this is the exact opposite of a failsafe, so never code safety valves into your own software that work this way. Most countries have the rather obvious rule that if a set of traffic lights is blacked out, i.e. none of the lights are working, then you are to treat it as a red, never as a green, and software protections ought to work that way round.

So, the magic sinkhole gave potential WannaCry victims time to find and remove the malware (and, we hope, to apply the patch that Microsoft had already provided a month before).

Our reluctant hero

At first, no one knew much about @MalwareTechBlog, except that he was apparently a quiet and unassuming young man somewhere in England, working from home for a somewhat mysterious cybersecurity company with no given address, but apparently registered in the US.

@MalwareTechBlog shunned the limelight, didn’t want his name to be publicised, and politely declined to be lauded and feted for what was, after all, merely his good fortune in clipping WannaCry’s wings while doing his normal day job.

To many people, that was quite a surprise.

After all, researchers in the cybersecurity scene often go out of their way to attract PR attention for what seem like feats of derring-do: fighting off government hackers! finding new bugs with impressive names! hacking planes! taking control of cars on the freeway!

But here was a guy who didn’t seem impressed by the cybersecurity rock star bandwagon, even though he could have climbed aboard, and to many of us that that made him yet more deserving of respect and recognition.

Sin City calling!

Of course, this being the era of search engines and social media, it wasn’t long before @MalwareTechBlog was outed as a likeable youth called Marcus Hutchins…

…and after that it wasn’t long before he’d been invited to the hugely popular Black Hat and DEF CON events, held annually in Las Vegas, USA.

Who wouldn’t go, especially if they were going as a valued guest and a celebrity who’d received their fame rather than chased after it themselves?

Hutchins couldn’t regain his anonymity, so his decision to attend was hardly surprising, but it was one he was soon to regret.

What he knew, but the rest of us didn’t, is that there were other reasons than modesty for him to have stayed out of the public eye until that point.

Although he was now uncontroversially considered one of the “good guys”, he hadn’t got there by a conventional route.

As a youth and at the very start of his adulthood, he’d been part of the cybercriminal underground – simply put, he’d accepted money from illicit sources for writing malware.

So he had to take a gamble about accepting the trip.

What was the chance of his shabby past emerging during the few days he was on US soil, leaving him vulnerable to arrest by the US authorities, who have a reputation for playing hardball with cybercriminals?

Even if something did leak out due to a careless word during one of Black Hat’s or DEF CON’s legendary parties, surely he’d be back in the UK by the time the story broke, and long before the cops had time to put enough evidence together to get an arrest warrant?

And what better destination to roll the dice than Las Vegas?

Sadly for Hutchins, if that was the way he figured it, he crapped out as soon as he touched down in US territory at McCarran International Airport in Clark County, Nevada.

Person of interest

The US authorities, it seems, were already interested in Hutchins, based on evidence they had collected of cybercrimes they suspected he’d committed both as a minor and after he’d turned 18.

No matter that he wasn’t a kingpin, that he hadn’t made very much money, if any at all, and that he was operating only on the fringes of cybercrookery.

They cops surely weren’t going to miss the opportunity to nab him, and they didn’t.

They got their warrant; they knew when he was set to return home; and so they arrested him at the airport, just when he probably figured he’d rolled a seven and won his bet.

At this point, a surprising number of people in the cybersecurity scene jumped to the conclusion that the FBI was over-reaching, that the charges must be bogus and that Hutchins was clearly not a crook.

We saw an efflux of scorn and hatred against American law enforcement, with numerous “experts” assuring us that they and any number of others could vouch for Hutchins, and that he was being falsely accused simply because he seemed to know something about WannaCry that no one else did.

Hutchins, as a stranger in serious trouble in a strange land, must have been happy to have so many visible and vocal supporters, but the blind prejudice of some of the “support” he received must also have caused him some concern.

In truth, most of the people leaping to declare his innocence didn’t really know him at all, and were in no position to vouch for him in any meaningful way other than to say, “We first heard of him only recently, but we quite like him. He’s easy-going, helpful and works hard.”

Those are great character references to have, but they don’t speak to guilt or innocence.

Well-known investigative journalist Brian Krebs admitted at the time that he too wanted to believe in @MalwareTechBlog’s innocence, but figured that he’d better dig into Hutchins’s background a bit before forming an opinion.

After three weeks of “joining the dots”, Krebs published a piece in which he said:

At first, I did not believe the charges against Hutchins would hold up under scrutiny. But as I began to dig deeper into the history tied to dozens of hacker forum pseudonyms, email addresses and domains he apparently used over the past decade, a very different picture began to emerge.

Out on bail

For almost the next two years, Hutchins was permitted to remain on bail in Los Angeles, California, and indeed to continue working to defray the cost of staying in the country for his trial.

As Hutchins himself wryly quipped at the time, it was like he’d landed a much-sought-after work permit, but one with the strings of Damocles attached.

Then, in April 2019, Hutchins reached a deal with the prosecutors, and pleaded guilty to two criminal charges; the other charges that he faced were dropped as part of the deal.

His sentencing was set for July 2019, and many of us hoped that he would be treated leniently, given his apparently improved behaviour as a gainfully employed adult.

At the time, we offered the opinion that:

We’re not expecting Hutchins to get away with a suspended jail term or a fine followed immediately by deportation to the UK, however effective such a sentence might sound. After all, the US courts may want to establish a clear disincentive for other youngsters who are toying with the idea of a “career” that involves attacking the online lives of innocent victims with malware.

So we’re guessing that he’ll go to prison to serve some sort of custodial sentence, although we can’t see him getting a full five-year stretch, and given his guilty plea and his public admission of wrongdoing, we hope he doesn’t.

In the past few weeks, we started to think that Hutchins and his legal team might have known ahead of time how his sentencing would turn out, because he started talking wistfully about “going home soon”, as though he was expecting to be deported immediately.

Indeed, that’s sort of how it ended.

Hutchins was sentenced to “time served”, meaning that he has, technically, received and served a prison sentence, with the time he spent in custody before getting out on bail considered to be sufficient incarceration.

He was also sentenced to a year of supervised release, meaning that although he’s free from prison, he’s not legally free in every sense.

But he can leave the US, and presumably will have to do so soon.

After all, he no longer has the “work permit” that he was afforded by being out on bail, and it’s unlikely he’ll ever get a US work permit in the future – or even a visitor’s visa – given that he’s a convicted felon.

Here’s what Hutchins himself said:

Sure, he’d be a fool indeed to say anything negative at this point, so cynics will probably dismiss this tweet with the words, “But he would say that.”

Nevertheless, he did say it, and we’re willing to assume he really meant it.

Was justice done?

We think he got off lightly; we think that for years to come he’ll benefit from the rock star status he initially sought to avoid; and we suspect that he will, perhaps unfairly, now enjoy very much better career prospects than cybersecurity researchers of equivalent ability who have scrupulously done the right thing all their lives…

…but we also recognise that he’s spent the last two years on bail in the US, facing serious criminal charges and an uncertain future that might very well have included a spell in a US prison.

A commenter on an earlier article we wrote about Hutchins demanded:

Please stop glorifying what he did and treating him as a hero. He is a criminal and deserves jail time.

At the time we replied by saying:

Do we think he’s a gifted and excellent cybersecurity researcher? No. He doesn’t yet have the knowledge or experience. (If you look at his recent posts about learning to code, we think he agrees with that.) Do we think he’s a prolific and unreconstructed cybercrook who will inevitably be a recidivist? No. We don’t have any science for that and we can’t prove it – but on the balance of probabilities we think he was a small-time player drawn into the malware scene as a kid and that he’d be nuts to try to get back into that game when he gets out.

So we’re going to finish by saying, “Yes. We think justice was done.”


Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/2E-U5fgwrNI/

Sysadmins need to know – how DO you pronounce “sudo”?

Most of the year, sysadmins have to worry about things that are bugging YOU.

They have to worry about the things that YOU need fixed right now, that YOU have decided are more important than everyone else’s problems put together, and that YOU shouldn’t have to put up with if only the world were fair, etc.

No matter that the problem YOU are having is caused by a problem that YOU created.

If your sysadmins were any good they’d have set things up so that YOU couldn’t have got it wrong in the first place.

No matter that they did, indeed, set it up just like that but YOU complained about feeling stifled…

…and YOU turned off the safety feature all by yourself, with the help of your neighbour’s friend’s cousin’s 9-year-old child, who’s just happens to be a computer whizzkid.

Well, today is #SysAdminDay, which means that it’s time for us to do something for those sysadmins for once.

So we thought we’d get to the bottom of a thorny problem that has provoked a number of arguments that we’ve deliberately started been caught in the middle of.


What is the right way – the ONE TRUE WAY, in fact – to pronounce the word sudo?

To explain.

Today’s operating systems – yes, O Beardy Ones, that includes Windows! – don’t routinely let you login as a system administrator, also known as the superuser, also known as root.

You logon as a regular user, which is the account you use for regular work such as keeping your resumé tweaked in LibreOffice, checking the Bitcoin price in Firefox, watching cat videos in VLC, playing retro games in MAME and recompiling the kernel.

To get rootly powers, you need to tell the computer that what you are going to do next should be boosted to run under the admin account.

On Windows, you can use the aptly named and easy-to-say runas command:

C:Usersduckrunas /?
RUNAS USAGE:

RUNAS [ [/noprofile | /profile] [/env] [/savecred | /netonly] ]
        /user: program

RUNAS [ [/noprofile | /profile] [/env] [/savecred] ]
        /smartcard [/user:] program

RUNAS /trustlevel: program

   /user             UserName should be in form USER@DOMAIN or DOMAINUSER
   /noprofile        specifies that the user's profile should not be loaded.
                     This causes the application to load more quickly, but
                     can cause some applications to malfunction.
   /profile          specifies that the user's profile should be loaded.
                     This is the default.
   /env              to use current environment instead of user's.
   . . . . 

On OpenBSD, which favours an approach based on the strip-back-the-fluff-and-keep-it-lean-mean-and-clean (if that is not a tautologically convoluted way of describing the OpenBSD view of life), it’s just doas.

But Linux, and macOS for that matter, steers you towards the sudo command.

Now, sudo is often misconstrued to mean “superuser do”, or “do the next command as the superuser”, but that’s not strictly correct.

The sudo command is short for “substitute user and do…”, or more precisely “set UID and do…” the command that follows.

You can therefore run sudo to switch temporarily to any other user, subject to the privileges you have been granted, though the default user you’ll turn into is, indeed, root.

Now, on most Linux systems, regular users get complete control over their own files but very little control over the system at all.

On the other hand, the superuser, or root, is pretty much Prime Minister, Minister of Defence, Minister of Finance, Chief Justice and Head of State (that’s His/Her Majesty to you or me) all at the same time.

There’s not really any sort of in-between user – you don’t get an account called demiroot or hemidemisemisuperuser – it’s everything or nothing.

That’s why, in the XKCD cartoon above, the person who’s being asked to make the sandwich collapses, in an instant, from “make it yourself” rejection into abject subservience.

Because root.

So, to the burning question.

If you need to read out a command line aloud, you need to know how to pronounce it, like this:

$ gzip -c blah | tar xvf -

gee-zip minus sea blah pipe tar exvieff dash

But you also need to know how to read out something more dramatic, like:

sudo rm -rf /var/log/webfilter/*.urls

Do you pronounce the first word as “Sue do”?

After all, the “do” part quite literally means “do”, as in, Ours not to reason why/Ours but to do and die.

Or do you get all metaphorical and treat the whole sudo thing as if it were a game, as in Ludo or Cluedo or Sudoku? Or a fighting style such as Taekwondo or Kendo?

That would make sudo come out more like “soo dough.”

Well, we’re delighted to sort this out for once and for all, now and for ever, until the end of time.

The ONE TRUE WAY to say sudo is as follows:

+++ATH0

OK

CARRIER LOST


By the way, if you’re wearing a cool T-shirt, give yourself and all your fellow sysadmins a shout by replying to our tweet below:

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/X-3KtNl5ZDM/

He’s coming home, he’s coming home … Hutchins’ coming home: British Wannacry killer held in US on malware dev rap set free by judge

Marcus Hutchins is on his way home to England after a judge spared him a stretch behind bars in America for developing the Kronos banking trojan.

Hutchins, the British malware reverse-engineer who shot to fame in May 2017 for thwarting a global Wannacry epidemic by discovering and activating its kill switch, was facing up to 10 years in the clink after earlier admitting he crafted the online-bank-account-raiding software nasty years ago as a teenager.

Today, however, Judge Joseph Stadtmueller, in a Wisconsin federal district court, sentenced Hutchins, 25, to one year of supervised release, and time served, plus ordered him to cough up $100 for each count as restitution to victims of his code. This effectively spared the Brit prison in the US, a country he has been forced to live in while awaiting trial since his dramatic arrest by the FBI in Las Vegas in August 2017.

“We see all sides of the human existence, both young, old, career criminals, those who strayed,” Judge Stadtmueller said, investigative journalist Marcy Wheeler reported from the courtroom. “I appreciate the fact that one might view ignoble conduct against backdrop as work a hero, a true hero. That is, at the end of the day, what gives this case its uniqueness.”

Turned a corner

The judge acknowledged that Hutchins had already turned from the dark side of malware development during his teenage years to become a respected professional white-hat infosec researcher, well before the Feds collared him. Hutchins, the judge said, was now using his intimate knowledge of malware and related skills to study and kill off software nasties, rather than creating more of them. Such skills are sorely needed, the judge noted, to help society tackle its woeful state cyber-security, before passing sentence.

“It’s certainly to your credit that without any encouragement … you stepped up to plate without expectation of notoriety,” Judge Stadtmueller added. “It is important to keep in mind the relative age of a young person who may not have matured to the point of being able, at end of day, to exercise good judgment.”

It is understood Hutchins will be able to return to the UK as soon as possible to serve his year of probation, after spending the past two years in the US without his passport. Judge Stadtmueller said nothing in today’s judgment forces him to remain in the States, though warned that the criminal conviction may well preclude the Brit from ever visiting the US again once he leaves. The judge even suggested Hutchins consider seeking a pardon or some kind of waiver in order to return – a comment Hutchins’ legal team called “unprecedented.”

arrest

WannaCry kill-switch hero Marcus Hutchins collared by FBI on way home from DEF CON

READ MORE

Hutchins became a computer security celebrity when he discovered Wannacry was checking for the existence of a particular domain name, and by registering it, he activated a kill switch in the ransomware worm that stopped it from spreading further. The malicious code had trashed computers in more than 70 countries, and had crippled large chunks of the UK’s National Health Service. By triggering the kill switch, he halted what could have been a terrible global epidemic.

Later that year, he was invited to the DEF CON conference in Las Vegas, USA, and spent the week hobnobbing with fellow hackers and doing the usual tourist stuff. When he was about to board a flight home, the FBI swooped and arrested him.

Unbeknownst to Hutchins, the g-men had been investigating him, and suspected he had played a role in the creation of two pieces of malware: the Kronos bank-account-draining trojan, and the UPAS Kit malware. The agents had obtained chat logs showing Hutchins had developed part of the code as a teenager, and had sold copies of it to crooks for a few thousand quid.

While Hutchins initially denied the accusations, he later pleaded guilty. That admission, the fact he built the code when he was teenager, and his subsequent work fighting malware and educating others on how to thwart software nasties, before he was even aware the Feds had him in their sights, counted heavily toward today’s verdict.

“Incredibly thankful for the understanding and leniency of the judge, the wonderful character letter you all sent, and everyone who helped me through the past two years, both financially and emotionally,” Hutchins, aka MalwareTechBlog, said after the verdict.

“Hopefully I can work on finding some way to come back to the US. But until then, back to work!”

Meanwhile, his lawyers tweeted:

Hutchins’ tearful mother was in court to see her son freed. He will now returning to Los Angeles, where he has been staying, to pick up his stuff, before heading back to Blighty.

Today’s verdict is a rare sign of sense from an American legal system that all too often seems more focused on hard punishment rather than perspicacity. There is little sense in locking away a talented researcher, who has much to offer the world, over youthful indiscretions. ®

PS: The judge was keen to allow Hutchins to smoothly return to the UK, via LA to pick up his belongings, without him being intercepted by America’s feisty border cops, ICE, who have no tolerance for criminal immigrants. “Nothing in the judgment requires he stay in US. I’m seeking to avoid him being taken into custody by ICE. We don’t need any more publicity or another statistic,” he said.

Sponsored:
Balancing consumerization and corporate control

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2019/07/26/hutchins_sentencing/

3 Takeaways from the First American Financial Breach

Data leaks from business logic flaws are not well understood and difficult to identify before they reach production environments. Here’s how to find and prevent them.

On the eve of Memorial Day weekend earlier this summer, Brian Krebs of the Krebs on Security website dropped a bombshell tweet that held the security community in suspense for several hours.

Krebs doesn’t use hyperbole often. The data exposure he later reported on was at First American Financial Corp., whose website was exposing highly sensitive mortgage transaction documents (including wire transfers, Social Security numbers, bank account numbers, and more) to anyone who knew the URL, without authentication. Moreover, each document’s URL was serialized and therefore easy to guess.

The data leak was the result of a business logic flaw, which is a category of vulnerabilities specific to an application and business domain. A business logic flaw allows an attacker to misuse the application by circumventing the business rules of the application. These attacks are disguised as syntactically valid web requests that carry malicious intentions to violate the intended application logic.

Business logic security issues are not well understood by the industry and difficult to identify before they reach production environments. The First American Financial exposure provides several valuable lessons on how to manage business logic risk in DevOps pipelines that seem to accelerate every day. Here are three:

Takeaway No. 1: Ensure Business Logic Flow Control
Broadly speaking, the First American Financial example falls into a type of business logic vulnerability called insufficient process validation, which occurs when an application fails to enforce business process rules, enabling an attacker to circumvent the intended flow or business logic of the application.

To correct this type of vulnerability, a security team needs to ensure flow control, multistep processes that require each step to be performed in a specific order by the user. Examples of multistep processes include order/transactions lookups, wire transfers, password recovery, purchase checkout, and account sign-up. Without validating the flow control, an attacker can perform a step incorrectly or out of order to bypass access controls.

Flow control is a part of business logic, which refers to the context in which a process will execute as governed by the business requirements. Exploiting a business logic flaw generally requires knowledge of the business but not technical skill. The person who discovered the First American Financial website flaw was a real estate developer, and, in fact, many business logic flaws are exploited by non-technical customers who find them during normal use. But this is what makes flow control issues so dangerous. Because the flow is being manipulated in unintended ways, validation and security checks baked into other processes may not be taking place.

Takeaway No. 2: Understand Authentication and Authorization Flaws
Traditional code analysis tools can’t uncover business logic flaws because they have no context of how the application is supposed to work. The tools don’t understand what data is critical, how it should be handled, when to authenticate access requests, and what appropriate authentication measures are.

Modern omnichannel applications must account for many different authentication points, such as the browser, iOS/Android devices, APIs, and deep embedded links. Are all these paths authenticated and authorized? Although we cannot definitely determine the cause of First American Financial’s breach, it likely stems from lack of authentication for embedded email links.

For example, with nonsensitive data, an email to a customer might include links to documents with only contextual authentication (e.g., clicking the link in a known valid customer’s email) for ease of use. However, even when properly authenticated, referential integrity checks must still be performed to ensure that any lookup or action is associated to the specific user tenant in question. In other words, once authenticated, users should not be able to access data from others’ accounts.

Lacking referential integrity checks, an insecure direct object reference (IDOR) occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as was the case with First American Financial’s URL or form parameter. An attacker can manipulate direct object references by merely changing the predictable sequence in order to access other objects without authorization, unless an access control check is in place. Here are three examples:

URL parameter-based: Let’s say you are an online banking customer for a (very insecure) bank. Upon login, you are taken to a URL that looks like https://onlinebanking/customer/27. Looking at the URL, you can tell that you are customer number 27. What would happen if you changed the URL to https://onlinebanking/customer/28? If you are able to see customer 28’s data, then you have definitely found an instance of IDOR.

Query parameter-based: Imagine that your name is John Smith and you want to access your annual review by going to https://mycompany/reviews?employee=jsmith. You are very curious about whether your coworker, Amy Jones, has received a better review than you. You change the URL to https://mycompany/reviews?employee=ajones. Voila! You now have access to Amy’s review.

Resource-based: If your website has an admin page with a URL of https://mywebsite/admin, which is normally accessed by a menu item that is only visible when the user has admin privileges, see what happens if you log in as a non-admin user and then manually change the URL to point to the admin page. If you get to the admin page, you found another instance of IDOR.

This type of IDOR exposure is increasingly common, as we saw with breaches at Fiserv, LifeLock, Panera Bread, and Kay Jewelers, all within the last several months. In fact, the Kay Jewelers breach suggests that First American Financial may not be out of the woods. When Kay Jewelers first learned of its IDOR vulnerability, it corrected it for new transactions but did not initially fix it for pre-existing transactions.

Takeaway No. 3: Characterize and Measure Logic Flaws for Decisioning
For an existing web application, finding business logic flaws is costly and cumbersome for developers because these flaws are inherently linked to the application business logic. This calls for high-level characterization and measurement for decisioning.

For a web application under development, it’s important for developers to seek guidance during the design of the authentication procedures. The goal is to enforce the security of the design of the authentication procedure by considering human factors and design errors. For example, to discover business logic flaws associated with authentication and authorization, we would need to correlate usability issues (lost phone, security unawareness) with human behaviors (active session, autocomplete forms).

On this basis, we can provide a set of security and usability requirements developers and architects can use during the early design of the end-user authentication procedure to prevent business logic flaws.

Related Content:

 

Black Hat USA returns to Las Vegas with hands-on technical Trainings, cutting-edge Briefings, Arsenal open-source tool demonstrations, top-tier security solutions, and service providers in the Business Hall. Click for information on the conference and to register.

Chetan is a serial entrepreneur with over 20+ years of experience in authoring and architecting mission critical software. His expertise includes building web-scale distributed infrastructure, personalization algorithms, complex event processing, fraud detection, and … View Full Bio

Article source: https://www.darkreading.com/breaches/3-takeaways-from-the-first-american-financial-breach/a/d-id/1335278?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

FormGet Storage Bucket Leaks Passport Scans, Bank Details

Exposed files include mortgage and loan information, passport and driver’s license scans, internal corporate files, and shipping labels.

A cloud security mishap at FormGet has exposed sensitive user-uploaded files dating back to 2013 through a misconfigured Amazon S3 storage bucket, TechCrunch reports. It’s the latest company to leave troves of data open to the Internet, signifying a concerningly common trend.

Bhopal, India-based FormGet provides online form creation and email marketing services to around 43,000 customers. People can use its tools to create forms for job applications, online shopping, and other processes. An anonymous security researcher found its S3 bucket had been left online sans password and contacted TechCrunch in an attempt to address the issue.

The bucket contained “hundreds of thousands” of files and documents dating back to 2013, packing a broad range of sensitive user-uploaded files: scans of passports, driver’s licenses, paychecks, and Social Security numbers; details of obtained loans and mortgages, bank account statements, and utility bills; UPS shipping labels with names and phone numbers; resumes containing contact information; and internal corporate documents containing cybersecurity assessment notes for multiple banks and financial firms, the report states.

“The problem of misconfigured cloud storage is often exacerbated by trusted third parties,” says Ilia Kolochenko, founder and CEO of ImmuniWeb. Businesses often need to share data with vendors like FormGet, which may often prioritize performance over data protection to keep up with a competitive market. Most companies have a vendor risk management policy, he adds, but these are rarely monitored for noncompliance, and few are properly enforced.

Given the frequency at which these data exposures happen, Amazon and other cloud providers have taken steps to lock down storage buckets by default. Businesses storing data in the cloud are urged to double-check their configuration settings to be sure information is private.

Read more details here.

 

Black Hat USA returns to Las Vegas with hands-on technical Trainings, cutting-edge Briefings, Arsenal open-source tool demonstrations, top-tier security solutions, and service providers in the Business Hall. Click for information on the conference and to register.

Dark Reading’s Quick Hits delivers a brief synopsis and summary of the significance of breaking news events. For more information from the original source of the news item, please follow the link provided in this article. View Full Bio

Article source: https://www.darkreading.com/cloud/formget-storage-bucket-leaks-passport-scans-bank-details/d/d-id/1335358?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple