Portshift brings a new identity-based application security model from code to runtime. Cloud or on-prem, Portshift works. In this DevOps Chat we speak with CEO Ran Ilany and VP Business Ops Eran Grabiner about what is unique to the Portshift solution and why you should consider it for your own application security, especially for your DevOps teams.

As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

Alan Shimel:Hey, everyone, it’s Alan Shimel, DevOps.com, Security Boulevard, and you’re listening to another DevOps Chat. In today’s DevOps Chat, we actually have a new company to introduce to our audience anyway and that company is Portshift. And I’m joined by two of the key folks at Portshift. We have Eran Grabiner, who’s VP of Business Ops, and Ran Ilany or Ilani I mispronounce your name, I apologize Ran Ilany, CEO and

Ran Ilany:Ilany.

Shimel:Ilany, great. CEO and cofounder. Gentlemen, welcome.

Ilany:Thank you.

Eran Grabiner:Thank you, Alan. Thank you for having us.

Shimel:Oh, my pleasure. So, Ran, you’re the CEO. I’m gonna let you kick off. A lot of people in our audience may not be familiar with Portshift. Fundamentally, what’s Portshift about?

Ilany:So, fundamentally, Portshift is trying to solve solving a problem which is a hard problem that wasn’t solved in the last couple of decades and was very much introduced as a solution, during early ’90s, with the firewalls technology. And now we’re moving to the cloud infrastructure, we see that the same firewalls that were used 20 years ago are not longer, I would say, valid, in order to run a application. And, essentially, there are, I would say, two to three reason that to that and I will let Eran elaborate about the reason of why.

Grabiner:Yeah. Sure, so, you know, Alan, when speaking about the cloud, there are two things that fundamentally changed everything for IT folks and DevOps engineers. The first thing: you don’t own the infrastructure, so the level of network and infrastructure, you simply don’t control it.

And, secondly, a lot of change through time in the world of compute. If I don’t know ten years ago, we had the monolithic application sit down in our data centers in the office, right now, when we’re in the cloud, our application is broken into many different pieces, many different _____ services. Everything is much more automated. Software is being updated on an hourly basis. And developers and engineers, they have much more power to do things with their software. So, because those two reasons that the old tools that we had, in order to orchestrate security in our network, simply doesn’t work.

Ilany:Yeah, and

Shimel:Agreed. Ran?

Ilany:And just to add to those points, there are two layers that essentially impose the challenge. The first one is the fact that, if you’d really like to, I mean, to use firewalls within the cloud environment, you really need to understand the network infrastructure. To understand the network infrastructure, you need to understand what is the application is doing out there in the cloud, and, in order to do this, you need to configure those IPs and those ports, which actually create a very, very close binding to the actual network infrastructure, for one hand.

And, for the other hand, you obviously need to have this type of discussion between the security folks to the actual operation folks, which actually creates a lot of bureaucracy that was possibly valid, you know, 15 years ago in the data center, but, now we’re moving to the cloud and everything is automated with CI/CD, you need something else. Okay? You need to break the paradigm, at least from being tied to the actual network, from one hand, and, from the other hand, you need to make things to be much more fast and much more intertwined with the development life cycle. Which is essentially the primary objective that Portshift’s have put in as a target and as a solution.

Shimel:Absolutely. So, guys and, look, I’ve been in this a while myself. You know, when we first started with the next-gen firewall, right, and that was sort of the premise, is that we were gonna get the developers involved and application-aware firewalls and all that, but it didn’t translate to the cloud. You’re right. But, Ran, I’m interested, as the CEO/cofounder, so this is obviously a problem, right? How do we do this in a cloud environment, at cloud scale, at cloud speed and all of that?

Ilany:Yeah.

Shimel:How did this affect you personally or in your kind of journey to where you’ve got here today, where you recognized and said, “Hey, we gotta do something about this, that this is a problem looking for a solution here”?

Ilany:Yeah. So, essentially, we understand that there is a problem that requires a solution, you know, while talking with customers. I mean, those are usually the No. 1

Shimel:That’s the way

Ilany:Yeah, and

Shimel: the best way to do it.

Ilany:And we saw that there are and we call it “the impossible tradeoff,” okay? They either need to be very, very fast they want to run very, very fast in the cloud, from one hand, but then they have a security constraint. They really want to control, I mean, the communication between the application and where the application should run. And there, there is the where to be in the curve of being Agile and being secure every organization has to find itself, in this type of curve, and to find what is the level of security that it wants to enforce or impose.

And this is, I would say, what led us to think of changing the paradigm or breaking the paradigm or making a solution that the customer will not have to make this type of tradeoff or make this type of decision and target to be both fast and Agile but also secure from the other way around _____ _____.

Grabiner:And we basically looked at what’s going on in the cloud from the DevOps perspective and we saw that many things changed to be better, with automation, with CI/CD tools, and we ask ourselves why, with security, this is not happening? Why the workstation or the tools that the DevOps engineer is now using to deploy software, why security tools can’t look the same? Why they can’t be part of the same idea and the same work cycles? And this is what got us to think that we need to, in a sense, push security to the left, shift left, and take it to be something that is part of the DevOps life cycle and part of the CI/CD infrastructure of the organization.

Shimel:Sure. So, guys, obviously so we call this “DevSecOps,” right? Is part of it.

Grabiner:Yeah, right. Yeah.

Shimel:It’s something that I you know, between DevSecOps Days and events we put on at RSA and so forth, it’s something we’re very involved in. My question for you then is, so it sounds like Portshift is really aimed at helping DevOps engineers, DevOps teams, developers, get more involved in the security or in the cloud firewall kind of paradigm for security. Is Portshift aimed then at the security team, the developer team, or both?

Ilany:So I think well, obviously, the focus of Portshift is not to try to educate Dev and DevOps to be security folks this is obviously not the target but think the good news is the fact that Dev and DevOps have the knowledge, okay? And the knowledge is where, essentially, they know their intention. They know where, essentially, they want to deploy the application and, essentially, who should talk to who, in terms of application containers or processors, depending, obviously, on your infrastructure. And this is, I would say, the basic assumption that the whole concept of Portshift is based on, okay? We actually take this type of knowledge, okay? We create from this knowledge or this attributes, we create the actual identity of the application, which is essentially a signed infrastructure or crypto-signature of those attributes. And we use those intentions that are described by DevOps, in their own natural language I mean, a recipe in Cookbooks with, you know, _____

Shimel:A Chef or a Puppet.

Ilany:Yeah, of course. Or Ansible or Kubernetes, obviously, infrastructure. We use this type of information while creating the crypto-identity, in order to deploy those application or signed application in the cloud and enforce the actual security that we describe formally. And the whole point is, essentially, that those folks don’t have to change the way that they work, okay? The security is more intertwined with their own system, the CI/CD system.

We leverage this type of information in order to create the security and the actual security folks will actually define guardrails. Okay? They will define operational environment in high level the production environment, the testing environment, or the preproduction environment where the actual application should run within. And the security will be sort of enforced and be visible automatically, without the pingpong, okay, or without the never-ending discussion between the security and the DevOps folks, which we all know it’s part of the problem, okay? It’s part of the challenge of securing the application in the cloud prams.

Shimel:Absolutely. So I guess this well, let me back up a sec. I just wanna make sure. Portshift, I know you work with AWS, obviously.

Ilany:Mm-hmm.

Shimel:Microsoft Azure, Google Cloud as well?

Grabiner:Yeah.

Ilany:Mm-hmm.

Grabiner:We’re totally agnostic to the infrastructure.

Shimel:Okay. And what I’m curious ’cause this is something that we going back and forth on, back and forth on. The attitude of the developers, the DevOps teams. I mean, you never meet a developer who says, “Oh, I’d wanna make an insecure application or I want my stuff to be hacked,” right?

Ilany:Mm-hmm.

Shimel:And you’re right they’re not security people, but they’re security-aware and they need to be security-responsible.

Ilany:Mm-hmm.

Shimel:Right? On the other hand, look, we all know security people who’ve said, “The developers will do what I tell them,” right? “And they’ll be secure when I tell them they’re secure.” But that doesn’t work either in this new world. Right? It’s gotta be together. So you talk about integrating with the CI/CD process. Give us an idea of how you work within the CI/CD process.

Grabiner:Got it. Yeah, so, basically, what we’re doing, we are asking the developers, the DevOps engineers, to use a very simple set of APIs, whenever they are using their infrastructure as a code or whatever the tools that they’re using, to send Portshift the relevant information that we need, in order to identify the piece of application that they’re deploying. This information can be technical information about the build, the version, the namespace of the application, and other attributes, that will allow us to rip up an identity that is unique, for each and every one of the pieces of the application. So this is the first part, where we learn your application logic, where we understand who should speak with who, and we know your business.

Now, when we take this identity and we move into runtime, we see all the different pieces and, first of all, we see them for sure. We know because we find them during CI/CD. If something didn’t go through CI/CD, if a developer deployed a container without asking, if, god forbid, an attacker is moving in the network, we would immediately see that because we signed the components during CI/CD. And we can see them. We can see them communicate. And now security folks and also DevOps engineers, they can easily define their agenda and their rules, based on their application logic.

A simple example: if they want their billing app to speak with their financial database, something that can take days just to config because your application is broken into different pieces and you need to config security groups and make sure you did it right and so on, with Portshift, you would simply write this sentence. You would just say, in English, “I want my billing application to speak with financial database,” and that’s it. Everything will work from then on.

Shimel:So it sounds magical, right?

Grabiner:Yeah.

Shimel:You know, I’m too old to believe in magic. What’s going on behind the scenes, though? When I write that, what’s actually happening behind the scenes?

Ilany:Yeah. So, essentially, what happens behind the scenes is we have two phases for this identity bit generation. As eloquently mentioned by Eran, the first phase is done by offline, okay? We take this type of attributes, which are sort of the intention, okay, in the CI/CD. We grab those as attributes of the identity and this is essentially the description of the application wherever the application should run, who should it talk to within the actual environment that we’re targeting to.

And then we have the correlation with the runtime properties. Every process, every containers have runtime characteristics for instance, the process ID, the UID, memory footprint, and stuff like that so we combine all together the offline attribute that was created with the ICD, with runtime attribute. We sign them all together.

And this essentially creates one unique entity that is running out there and this is what we’re using in order to enforce. We are transferring this type of identity in the traffic stream so that a conversation between two different application is, first and foremost, authenticated, okay, and only then authorized. Okay? This is what we call the classical “zero-trust” approach, okay? We’re not trusting the IP; we’re trusting the identity on the counterpart.

And this brings another where we talked, I believe, a little bit about the operational benefits and the fact that it’s very Agile and useful for the Dev and DevOps and the security collaboration. But there is another very important advantage and it’s the fact that, now that we are not talking about an attack surface which are segments, network segments, we are talking about type of access. Okay? So, if an attacker, for instance, get into one of my workloads or one of my application, we are not losing the whole segment, okay? We are losing a single part.

And now we have, I would say, less we’re much less concerned from the extent that we are exposed, okay, because we are talking about only point-to-point access permitted. They’re not network segments, which are open and, from the attacker perspective, it’s like a dream come true. If I find a flat network and I get into your flat network in some miraculous way, then I can get into every resource or application that is out there.

Shimel:A good target.

Ilany:Yeah. And this is, essentially, the basic concept of the security perspective of identity-based access control between different applications.

Shimel:Sure. Guys, it sounds fascinating. As I mentioned to you when we started, the time goes very quickly. We’re kind of at the end of our time.

Grabiner:Yeah.

Shimel:I apologize, but maybe we can continue the conversation. For people who are interested, Portshift, you can get more information at portshift.io. Correct?

Ilany:Right.

Grabiner:That is correct.

Shimel:And you guys will be at AWS Reinvent, though

Grabiner:Correct.

Shimel: _____ _____ after. Will you be at RSA conference?

Grabiner:Yes. We will also be presenting there, at a startup venue.

Shimel:Oh, the Launchpad or the Sandbox?

Grabiner:The I think it’s called I think it’s the Launchpad. Yeah, it’s where all the early-stage companies are. Yeah.

Shimel:Yep. Sandbox that might be the Innovation Sandbox. Launchpad is more for ideas.

Grabiner:Oh, yeah.

Shimel:I think you fit more in yeah, we’re a big part of RSA, so, yeah, I just did a podcast with them about both of those, so little bit I know. Anyway I’m sorry. Thank you very much for joining us and we will if we don’t see you at AWS, we’ll see you then at RSA. Well, we’d like to probably hear more because this kinda fits right into our sweet spot. Ran, Eran, thank you for joining us on DevOps Chat today. Good luck with Portshift. This is Alan Shimel for DevOps.com. Have a great day, everyone.

Sponsored Content

Featured eBook

Extreme IT Automation

DevOps has transformed the way organizations create, test, deploy, monitor and update software. It has fundamentally changed corporate IT culture―breaking down roadblocks and barriers between teams and compressing timeframes to enable companies to function more efficiently. The fuel that drives DevOps is automation. This complimentary resource is offered by DevOps.com ...Read More

Adoption of Internet by businesses and enterprises has made mobile-banking, online shopping, and social networking possible. Whilst it has opened up a lot of opportunities for us, itsnot altogether a safe place because its anonymity also harbors cybercriminals.So, toprotect yourself against the cyber threats of today, you must have a solid understanding of cybersecurity. This article will help you get a grip on cybersecurityfundamentals.

Let’s take a look at the topics covered in this cybersecurity fundamentals article:

About fortyyears ago words like worms, viruses, trojan-horse, spyware, malware weren’t even a part of conventional information technology (IT) vocabulary.Cybersecurity only came into existence because of the development of viruses. But how did we get here?

The history of cybersecurity began as a research project. Inthe 1970’s, Robert Thomas,a researcher for BBN Technologies in Cambridge, Massachusetts,created the first computer “worm”. It was called The Creeper . The Creeper, infected computers by hopping from system to system with the message “I’M THE CREEPER: CATCH ME IF YOU CAN.” Ray Tomlinson, the inventor of email,created a replicating program called The Reaper , the first antivirus software, which would chase Creeper and delete it.

Late in 1988, a man named Robert Morris had an idea: hewanted to test the size of the internet.To do this, he wrote a programthat went through networks, invaded Unix terminals, and copied itself. The Morris worm was so aggressive that it slowed down computers to the point of being unusable.He subsequently became the first person to be convicted underComputer Fraud and Abuse Act.

From that point forward, viruses became deadlier, more invasive, and harder to control. Withit came the advent of cybersecurity.

Cybersecurity Fundamentals | Understanding Cybersecurity Basics | Edureka

Cybersecurity is the body of technologies, processes, and practices designed to protect networks, computers, programs and data from attack, damage or unauthorized access.

The term cybersecurity refersto techniques and practices designed to protect digital data. The data that is stored, transmitted or used on an information system. After all, that is what criminal wants, data . The network, servers, computers are just mechanisms to get to the data.Effective cybersecurity reduces the risk of cyber-attacks and protects organizations and individuals from the unauthorized exploitation of systems, networks, and technologies.

Robust cybersecurity implementation is roughly based around three key terms: people, processes, and technology .This three-pronged approach helps organizations defend themselves from both highly organized attacks and common internal threats, such as accidental breaches and human error.

The attacks evolve every day as attackers become more inventive, it is critical to properly define cybersecurity and understand cybersecurity fundamentals.

Listed below are the reasons why cybersecurity is so important inwhat’s become a predominant digital world:

Because of the above reasons, cybersecurity has become an important part of the business and the focus now is on developing appropriate response plans that minimize the damage in the event of a cyber attack. But, an organization or an individual can develop a proper response plan only when he has a good grip on cybersecurity fundamentals.

Now that we know what cybersecurity is and why it is important, let’s take a look at fundamental objectives of cybersecurity.

5 (1050)

3k Learners Enrolled Live Class

Best Price 289 289

Confidentiality, integrity, andavailability , also known as theCIA triad, is a model designed to guide companies and organizations to form their security policies. Technically, cybersecuritymeans protecting information from unauthorized access, unauthorized modification, and unauthorized deletion in order to provide confidentiality, integrity, and availability.

Let’s explore thesecomponents and some of the information security measures which are designed to assure the safety of each component.

Confidentiality is about preventing the disclosure of data to unauthorized parties. It also means tryingto keep the identity of authorized parties involved in sharing and holding data private and anonymous. Often confidentiality is compromised by cracking poorly encrypted data,Man-in-the-middle(MITM) attacks, disclosing sensitive data.

Standard measures to establish confidentiality include:

Integrity refers to protecting information from being modified by unauthorized parties. It is arequirement that information and programs are changed only in a specified and authorized manner. Challenges that could endanger integrity include turning a machine into a “zombie computer”,embedding malware into web pages.

Standard measures to guarantee integrity include:

Availability is making sure that authorized parties are able to access the information when needed.Data only has value if the right people can access it at the right time.Information unavailability can occur due to security incidents such as DDoS attacks,hardware failures, programming errors, human errors.

Greg is a drilling engineer responsible for monitoring production systems for an oil rig. His business intelligence (BI) dashboard refreshes every 30 minutes. At 3:30 PM, the dashboard refreshes and he notices a spike in a pump ’s temperature and pressure, which means it needs to be replaced ― right now. But the information is already too old; the pump has stopped working and production must cease, resulting in valuable production loss.

The ability to analyze real-time data has become paramount in use cases like Greg’s and countless others to keep businesses competitive . With the rise of IoT and ever-increasing data from customer interactions streaming across the enterprise, if we wait to capitalize on it, data loses its value, leading to missed opportunities and significant problems.

TIBCO Spotfire X now makes it easy to connect and visually analyze data in motion like never before. With native support of real-time streaming data, Spotfire Data Streams pushes continuous updates into Spotfire for real-time analysis. The result is live dashboards of streaming data that allow business users and frontline staff to analyze and act on data insights while they are still relevant. So Greg can anticipate the problem, fix the pump before it fails, and even increase production.

The first truly real-time BI implementation in the industry

The response to Spotfire X has been resoundingly positive, including analyst feedback that validates it as the first truly real-time BI implementation in the industry. There are other technologies that provide streaming dashboards, but none compare to Spotfire’s ability to deliver streaming analytics and explore the data.

Spotfire X and Spotfire Data Streams let you analyze real-time and historical data together, for full situational awareness so you can better respond to conditions in real time, get to the root cause of problems or issues and predict what might happen next. No other BI tool today applies analysis through direct manipulation to streaming and to historical data at the same time. Only Spotfire X allows you to understand all your data as it changes and apply artificial intelligence (AI) and natural language in one beautiful, easy-to-use tool.

From inventory management to financial fraud detection to ground-staff operations and more, the possibilities are endless.

How it Works

Spotfire Data Streams has pre-built connectivity to over 80 data sources as well as custom connectors. The Spotfire Data Streams Server manages data connectivity, storage, continuous queries, alerts, client connectivity, user authentication, and security. At the heart of the server is the continuous query engine that processes high-speed streaming data, creates fully materialized live data tables, manages ad-hoc queries from Spotfire, and continuously pushes live results as conditions change in real time.

To learn more about real-time Analytics with Spotfire X watch the webinar, Real-time Analytics with Spotfire X and Spotfire Data Streams , and try a free 30-day trial of Spotfire X .

Facebook was lucky when the Information Commissioner’s Office (ICO)―the UK’s independent authority set up to uphold information rights in the public interest―hit the U.S. social media company with a 500,000 fine.

Related: Zuckerberg’s mea culpa rings hollow

This penalty was in connection with Facebook harvesting user data, over the course of seven years ― between 2007 and 2014. This user data became part of the now infamous Cambridge Analytica scandal.

Facebook was very lucky, indeed, that its misdeeds happened before May 25, 2018. On that date, the EU General Data Protection Regulation (GDPR) came into force .

According to research by one law firm, pre-GDPR regulatory fines hadalmost doubled, on average, between 2017 and 2018, up from 73,191 to 146,412. Those figures pale when stacked against the potential bottom line impact that now exists.

Safa

This complacency appears to stem from an apparent misunderstanding of requirements to employ cybersecurity technology and procedures that will be effective in preventing, or mitigating the impact, of a data breach. Compliance checkbox ticking is alive and well, making up the sagging security posture in many enterprises.

Heathrow Airport was fined 120,000 when it lost a USB stick containing non-encrypted and sensitive data. The BBC reported at the time a Heathrow statement as saying it “regretted the breach.”

Even with sharper teeth attached to the regulatory fining regime, companies still operate as if non-encrypted data, on a non-password protected USB stick, should be considered acceptable. The ICO found that there was a “catalogue of shortcomings in corporate standards, training and vision.”

Even those organisations involved in law enforcement don’t seem to get it. Earlier this year the Crown Prosecution Service (CPS) was fined 325,000 after it ‘lost’ a stack of DVDs containing police interview recordings of child sex abuse victims ― after this evidence got left in reception for a couple of days and then vanished.

Adjusting the books to compensate for a fine is one thing. But it’s a lot harder to compensate for the damage to brand reputation after a breach of any kind. And compensation claims can add litigation costs into the mix; customers are, quite rightly, a very compensation-happy crowd when they’ve been short-changed with respect to data protection measures.

With Gartner predicting that the worldwide security spend will reach more than 71 billion by the end of 2018, organizations really do need to get to grips with three words: risk, cost and value.

Complacency, or using inadequate solutions when it comes to securing data and content of whatever form, can be much costlier than immediately apparent.

About the essayist:John Safa is founder and chief technology officer at Pushfor , a London-based supplier of messaging and content security systems. He considers himself a maverick with high ideals, seeking to completely change the dynamic of online communication.

当用户在安装森海塞尔的HeadSetup软件时，很少有人知道这个软件还会在“受信任的根证书颁发机构存储库”中安装一个根证书。除此之外，它还会安装一个加密版本的证书私钥，而这是一种非常不安全的行为。

没错，这种证书及其对应的私钥对于任何安装了这款软件的用户来说都是相同的。这样一来，攻击者就可以在成功解密密钥之后，颁发一个其他网站域名下的伪造证书了，而此时，当用户访问了这些网站的时候，攻击者将能够通过执行中间人攻击来嗅探目标用户的网络通信流量。

解构

虽然这些证书文件会在用户卸载HeadSetup软件时被删除，但是可信任的根证书却不会被移除。这将使得拥有正确私钥的攻击者在目标用户卸载了HeadSetup这款软件之后，继续实现嗅探攻击。

当HeadSetup安装完成之后，它会在目标计算机中存放两个证书。该软件会使用这些证书以及TLS加密的Web套接字来与耳机通信。第一个证书名为SennComCCCert.pem，它是一个根证书，而SennComCCKey.pem是证书的私钥。

研究人员在分析这个私钥文件时发现，它采用了AES-128-CBC加密，而且需要找到正确的密码才能解密。由于HeadSetup程序同样需要使用这个解密密钥，因此这个密码肯定存储在软件里的某个地方，研究后发现密码存储在一个名叫WBCCListener.dll的文件里。

研究人员解释称：“为了解密私钥文件，我们需要弄清楚它所使用的加密算法以及密钥，我们首先猜测，供应商采用的是常见的AES加密算法（CBC模式，128位密钥）。在HeadSetup安装目录内，我们只发现了一段可执行代码中包含有文件名‘SennComCCKey.pem’和DLL文件‘WBCCListener.dll’。我们搜索了这个DLL中包含“AES”的字符串，最终发现了AES-128.cbc的标志，而且还是以明文形式存储的。”

在把解密私钥转换为标准OpenSSL PEM之后，研究人员还需要一个密码来使用它。这个密码存储在一个名叫WBCCServer.properties的文件中：

得到了访问根证书的私钥之后，研究人员就可以生成大量可用于对google.com、sennheiser.com、以及其他耳机厂商的流量进行签名的证书了，比如说jbl.com、harmankardon.com和bose.com等等。

由于这个证书使用的相同私钥创建的，那么其他设备同样也无法幸免。接下来，攻击者将能够利用这个证书来执行中间人攻击，最终实现拦截和篡改用户访问目标站点的通信流量。

这也就意味着，攻击者还可以创建银行网站的伪造证书，然后窃取目标用户的网银登录凭证、信用卡信息和其他敏感信息。

目前，研究人员已经将相关问题上报给了森海塞尔公司，该漏洞分配到的ID为CVE-2018-17612。森海塞尔公司也表示，更新版本将在12月初发布，更新版本将移除可信任的根证书，并确保在软件卸载之后不会遗留任何证书。

与此同时，森海塞尔还发布了一份Batch文件，广大用户可以使用该文件来移除相关证书。研究人员强烈建议安装了HeadSetup的用户尽快运行该脚本来保护自己的安全。

微软方面也发布了相关的安全公告（ADV180029）,并解释称，微软已经发布了更新版本的可信证书列表，并从原先列表中移除了相关的恶意证书。

* 参考来源： bleepingcomputer ，FB小编Alpha_h4ck编译，转载请注明来自CodeSec.Net

九个亿财经消息――黑客已经设计出一种窃取加密货币的新方法。这一次，他们正在进行大规模扫描活动，挑选出具有特定漏洞的以太坊钱包和矿工。

根据ZDNet的报道，加密黑客的目标是Etherum钱包和采矿设备通过具有暴露端口8545的设备，这是JSON-RPC接口的标准端口 - 位于本地设备上的编程API，可用于查询挖掘-相关信息。

以太坊 开发人员警告用户在使用采矿设备和以太坊软件时暴露JSON-RPC接口的危险，指示用户为接口启用密码或激活防火墙以过滤进入易受攻击端口的互联网流量。

根据设计，JSON-RPC接口没有默认密码。这取决于用户设置一个，他们很少这样做。对于其端口在互联网上暴露的以太坊钱包或采矿设备，黑客可以向API发送命令并从钱包中远程转移资金。

报告指出，采矿钻机生产商和以太坊钱包开发商已经做了一些工作，通过警告用户需要添加密码来限制这个有问题的界面造成的损害。其他人已经完全消除了界面的极端路线，但由于这不是一个团结的努力，问题仍然存在。

虽然在过去的两年中有大量的以太坊扫描活动，但这是熊市首次报道扫描。事实上，该报告引用了Bad Packets LLC的联合创始人Tory Mursch的数据，他告诉新闻媒体，12月份的扫描活动比上个月价格稳定时增加了两倍。

“尽管加密货币的价格冲到了阴沟里，但免费资金仍然是免费的，即使它是一天的便士。”

让这些扫描难以置信的原因是人们可以通过暴露的端口8545获取开发以太网客户端所需的工具是多么容易。根据报告，超过4,700台设备（主要由Geth采矿设备和Parity钱包组成）是最易受攻击的设备将他们的界面暴露给入侵者。

去年，黑客通过Parity流行的多重签名钱包中的一个漏洞偷走了3200万美元以太，导致开发团队指示持有Parity钱包客户ETH的用户将他们的资金转移到安全地址。

本文来源：比特币小白

密码学具有各种优点，包括信息的机密性。然而，过度依赖密码学来保护应用程序是一个坏主意。今天我们就通过一个案例研究，来认识一下通过加密的有效载荷识别和利用SQL注入漏洞。

SQL注入也许很多人都知道或者使用过，如果没有了解或完全没有听过也没有关系，因为接下来我们将介绍SQL Injection。

SQL注入，就是通过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。

具体来说，它是利用现有应用程序，将恶意的SQL命令注入到后台数据库引擎执行的能力，它可以通过在Web表单中输入恶意SQL语句得到一个存在安全漏洞的网站上的数据库，而不是按照设计者意图去执行SQL语句。

那SQL注入会在什么时候发生呢？

假设我们在浏览器中输入URL www.sample.com，由于它只是对页面的简单请求无需对数据库动进行动态请求，所以它不存在SQL Injection，当我们输入www.sample.com?testid=23时，我们在URL中传递变量testid，并且提供值为23，由于它是对数据库进行动态查询的请求（其中?testid＝23表示数据库查询变量），所以我们可以在该URL中嵌入恶意SQL语句。

不过要提前说明一下，我们不会在本文中讨论加密问题，而是只讨论应用程序缺陷，我们会先生成加密的有效载荷，然后将其用于识别和利用SQL注入。

在最近我们接触到的一个电子商务应用程序中，观察了该网站的大多数请求参数值已被加密。当请求参数被加密时，很难对应用程序进行模糊测试，除非我们可以去除加密，不过这需要知道密钥和加密算法。

下图就是我们所找的样本网站的详细信息页面，该页面就是以加密格式发送id（orderid）参数的。

注意：参数值（BDKfx3xNKsc =）是加密的，而不是简单的base64编码。ID参数的加密值以base64编码格式表示。

我们还注意到，如果我们退出应用程序，然后以相同的用户登录并导航到完全相同的页面，则加密参数（nPBri1km2ic =）的值现在不同，如下所示。

正如上图所示，随机密钥在每个成功的登录或会话ID（cookie的一部分）中用于加密，以某种方式用作密钥的一部分。这看起来很安全，不过还是让我们尝试着SQL注入。

首先，我们尝试在多个位置注入单引号（'）以测试输入验证，但请求参数被拒绝，因为这些参数需要加密格式（即有效的密文）。

不过我们在这里可以使用购物车的一个分享功能，此功能允许用户与其他人共享购物车项目。当用户保存购物车进行共享时，会产生一个带有随机查询令牌的链接。通过访问此链接（URL），用户可以访问彼此的购物车。在购物车被要求保存之前，用户被要求在购物车上标记一个名字。

由于这是接受明文输入的罕见输入字段之一，所以我们将其编码为SQLi，XSS。在更深入的检测中，我们发现生成的URL中的令牌共享购物车实际上是我们为购物车选择的购物车名称的密码。

不过请注意，共享购物车功能可不会轻易受到任何攻击的影响，但可以用于为给定输入（明文）生成加密的有效内容（密文）。现在，可以共享购物车功能的链接就可以生成一个加密的攻击有效载荷来检查应用程序对SQL注入，绕过授权等漏洞行为进行验证了。为了测试SQL注入，生成了单引号（'）的加密值。

加密的有效载荷用于模糊仅接受密文值作为输入的各种应用参数。我们花了一些时间来打到正确的位置，但是最终，orderitem页面的ID参数返回一个SQL错误消息，确认该漏洞。

该错误消息证明应用程序生成动态查询，并可能容易受到SQL注入攻击。现在是从数据库中提取信息的时候了，基于UNION的SQL查询用于从数据库中提取数据，联合运算符用于组合两个或多个select语句的结果。

第一个任务是确定作为SQL查询的一部分返回的列数，使用试错，我们在查询中返回了一些列（30）。现在是时候从数据库中提取信息了，我们创建了一个加密的有效载荷来提取数据库版本信息，如下所示。

然后，把上述有效载荷的输出生成的密文作为页面上易受攻击的ID参数输入。

然后我们使用这个漏洞来构建数据库系统，最终得到一个shell。

总结

由上面的分析可知，用加密参数来实现应用程序中的安全性其实并不像想象中的那么安全，比如用强加密算法加密的数据，恶意攻击者可以使用加密的有效载荷的方式来进行攻击。 目前，加密仍被认为是保护数据免遭篡改或欺骗的有力机制，不过由于加密执行不力和缺乏明确的使用隐私保护，所以仍有可能会造成相当危险的安全漏洞。

信用评级机构Equifax深陷全球最大数据泄露事件泥潭，美国政府官方报告称其未能实现“足够的安全措施”以保护数据。

美国众议院监管与政府改革委员会的报告称，该数据泄露本是完全可以避免的，是该公司未能完整的给系统打补丁才导致的泄露。

Equifax没能完全理解并缓解其网络安全风险。

该报告还证实，Equifax安全人员未能发现数据渗漏是因为他们用于监视网络流量的设备在19个月前就因安全证书过期而不工作了。

直到该安全证书最终得到更新，从该公司消费者自动采访系统(ACIS)流往某中国IP地址的可疑流量才被发现。

报告中称：Equifax注意到一个二级IP地址上有额外的可疑流量，该IP地址属于某德国ISP，但却租给了中国提供商。这一警报促使Equifax关闭了ACIS网页门户进行紧急维修。ACIS一下线，该网络攻击也就停止了。

缺乏领导和问责令过程失灵，使工具疏于维护，让策略形同虚设。

7月31日，证书更新后两天，该公司首席信息官 David Webb 向首席执行官 Richard Smith通告了此事，但直到9月才向公众披露该数据泄露事件。之后8天，Webb和Smith被解雇。

监管与政府改革委员会这份长达96页的报告总结道：Equifax没能完全理解并缓解其网络安全风险。但凡该公司此前曾采取措施解决其显而易见的安全问题，数据泄露事件都可以被避免。

ACIS是承自1970年代的老旧系统了，最初的攻击途径就是作为ACIS前端的 Apache Struts Web 服务器上一个未修复的漏洞。

Equifax没检测到数据渗漏，因为用于监视ACIS网络流量的设备因安全证书过期已经19个月没启动了。2017年7月29日，Equifax更新了该证书，立即注意到了可疑网络流量。

――Adrian Sanabria (@sawaba) 2018年12月11日

渗透测试公司NopSec策略副总裁 Adrian Sanabria 列出了Equifax的各种IT安全失误：

Equifax的全球威胁与漏洞管理团队(GTVM)向400多名内部员工推送了Struts警报。就像很多公司所做的一样，Equifax也就该漏洞召开了内部会议。警报邮件在该漏洞被披露2天后就发出了，并指示该漏洞应在48小时内打上补丁，但会议是在邮件发出后一周才召开。

警报邮件都在那儿了，为什么要在修复时限过去 5天 以后才开会商讨修复事宜？因为他们清楚根本没人会去修复。

无论如何，他们没有测试这一规则，所以攻击中也没有触发。测试你的控制措施！太多安全控制措施都是只部署不测试了，这很令人惊悚。

即便如此，该公司还是花了 2个多月 才最终打上补丁，但那个时候其系统已经被完全渗透，尤其是攻击者找到一个含有公司48个数据库明文用户名及口令的老文件之后。

为什么Equifax不通报该渗漏情况？老实说，大多数公司都没有设置线上数据渗漏检测。

但是，19个月，这也太夸张了。这是因为没人正式负责内部证书管理工作。对一个拥有1.7万个可路由IP的公司而言，或许内部证书管理责任是块烫手山芋吧。

还不仅仅是证书过期问题。数据泄露发生当时，Equifax还有至少 324 个SSL证书是过期的。

他们可能有做一些SSL检查，所以证书很重要。但他们不应该仅仅依赖包检测技术。

即使不解密流量，他们也应该注意到有大量数据流向了中国和德国的服务器，而且是从平时不会往这些目的地址发送大量数据的源发出的。仅仅网络流量这一条就应引起注意了。

总之，证书更新后，Equifax立即注意到了攻击，证明他们确实拥有可以检测的工具。

1. 员工注意到了缺陷；

2. 存在恰当的过程、工具和策略；

3. 缺乏领导和问责令过程失灵，使工具疏于维护，让策略形同虚设。

虽然Equifax的安全人员使用了扫描器来探测其 Apache Struts 的漏洞，该工具却配置错误，未能有效发现漏洞。且仅仅扫描根目录和异常检测是不够的，安全人员没有测试他们的措施和对策。

Equifax总共犯了34个控制与过程错误导致数据泄露。可能只需其中5个控制措施和过程做对了就能避免这场数据泄露。其他29个左右可以尽早检测到数据泄露情况，留出时间加以阻止。

https://oversight.house.gov/wp-content/uploads/2018/12/Equifax-Report.pdf

2018年网络安全“金帽子”奖年度评选活动经过紧张的投票阶段，获奖名单已新鲜出炉，本次公布的是大众评审奖的获奖得主。

根据活动评选投票规则， 大众评审奖 将选出年度新锐安全公司五名、年度最受关注安全应急响应中心五名、年度最具影响力安全会议五名、金帽子明日之星五名。四类奖项由根据 大众网络投票评选的票数排名得出 ，结果如下：

年度新锐安全公司获得者：

众安天下、世平信息、锦行科技、紫豹科技、威胁猎人。

年度最受关注安全应急响应中心获得者：

蚂蚁金服安全响应中心、补天漏洞响应平台、饿了么安全应急响应中心、百度安全应急响应中心、网易安全应急响应中心。

年度最具影响力安全会议获得者：

ISC互联网安全大会、DEF CON CHINA、CSS互联网安全领袖峰会、唯品会互联网电商安全峰会、西湖论剑网络安全大会。

金帽子明日之星获得者：

Tencent Blade Team、NU1L、复旦白泽战队、r3kapig、天枢战队。

专家评审奖票选结果将于明日公布，欢迎大家届时关注！ 2019年1月将举办现场颁奖盛典，为所有获奖者及公司颁发荣誉奖杯，庆祝激动人心的时刻。

"The HPC is down!"

"But the competition just started!"

Our high-performance computing cluster (HPC) blinked red on the big screen. Minutes ticked by.

"Get it up! Get it up! We're losing points!"

"Working on it!"

Red team had been circling since the day before, hawks swooping and diving. They'd been scanning and probing all day Friday, but weren't allowed to attack until the checkered flag dropped Saturday morning at 8 a.m. We'd hoped to evade their talons, but they wasted no time, and now one of our critical assets blinked out--a meal for a hungry predator.

Our blue team was tasked with defending a mock oil refinery's industrial control system (ICS), the HPC and the integrated back-office IT system―all of it default insecure, some of it insecure by design―and the only real defense active monitoring and split-second eviction before red team could take us down.

"The HPC isn't coming up. What is going on?"

Four Raspberry Pis running the oil refinery and HPC sat on the table in front of us, water pumps clicking on and off. Click-click. Click-click. Click-click. Someone else was in control. Not us.

Meet Big Oil Logistics and Transportation Corporation (BOLT Corp), its ICS, and an HPC running on four Raspberry Pis.

Across the country in seven different Department of Energy labs, university teams fought alongside us to defend identical infrastructure. The DoE runs its CyberForce competition every year to introduce college cybersecurity students to the challenges of securing critical energy infrastructure, and to recruit the best and brightest. We were the UC Berkeley team representing the Berkeley iSchool's new Masters of Information and Cybersecurity (MICS, pronounced "mikes") program, and I was not only reporting on the event, I was playing to win.

The six of us hunched over our laptops in the competition space at Berkeley Lab, perched cliffside just east of the UC Berkeley campus, too distracted to enjoy the view of the Golden Gate Bridge, San Francisco Bay and the iconic Berkeley Campanile, the picture postcard bell tower. For eight hours we fought to keep our systems up and red team out, until, by the end, the uncontrollable twitch in my right eye told me I had chewed on too much stress for one day.

Teammate Daren tugged at his grey goatee. "Let me check something."

I stood in the dark under the dripping canopy of the Strada Cafe in Berkeley waiting for my ride to the lab that morning. The piranha in my bowels gnawed away at my spasming entrails. How were we going to defend these completely defenseless industrial control systems? These things were running modbus, insecure by design. We weren't just sitting ducks, we were Peking ducks ready to serve with plum sauce.

This wasn't your normal capture the flag (CTF) , where teams competed to break into the systems and steal information. We weren't predators. We were the prey.

I sipped my black coffee and checked my phone: 6:12. Doors opened at 6:30, and the competition began at 8 a.m. Pacific―11 a.m. for the competitors at Brookhaven on Long Island, 10 a.m. at Argonne outside Chicago, and 9 a.m. at Sandia in New Mexico.

It was going to be a long day.

My teammate Josh rocked up with a coffee and we stood watching the rain. The darkness seemed unending. A car sloshed by. Was it―? No. Not our ride. We both pretended to be chill.

"We gonna win today, you think?"

"Gonna try."

Then "The Anvil of Crom" thumping in the car, Nathan our mentor driving, up the rainy black hillside to the unclassified cliffside lab that overlooks campus, to the guard post, documents glanced at, a flicker at us in the back seat, then up, up, up to the SOC we had laid out on two tables the day before.

Our ad hoc SOC: six laptops, two big screens, many coffees.

The music still rings in my ear, so wrong in retrospect. We were not warriors going into battle; we were lab mice in a maze with hawks circling, predators ready to crush us with their talons at any moment.

We sat down at our battle stations―two giant big screens propped up on our competition table―and prepared to defend. The piranha gnawed harder.

"They're all just kids," we muttered, glancing sideways at each other. The other three teams at Berkeley Lab were undergraduates, most of them too young to enjoy a beer after. Our team's average age was 42, and together the six of us have a combined 107 years of experience working in IT, including a couple of folks from the defense sector, a software architect, a systems integrator, an early Facebook employee, and a coder turned wordslinger―me.

We were double their age and had ten times more experience than they did. Somehow that didn't make us feel any more confident about our chances of winning.

Predator humor

"Having fun?" my teammate Karel asked. I stared at the big screens, looking for rogue logins. The log info came at us in an unending stream. On the CyberForce Slack channel for competitors, threat intel overwhelmed with gossip and meme noise. And the memes! What was with the undergraduate obsession with memes, many of dubious hilarity? Out of place, old and weary, facing an impossible task, a goshawk's meal in waiting.

"Not really," I answered.

Fear and loathing washed over me like a shower of sewage. Were we fools or tools? I shuddered. Not the lesson the DoE wanted to impart when they launched CyberForce, I felt certain.

"Team 69 help desk, can I help you?" Terry clutched the cell phone to his ear in the noisy competition space. Of the 70 teams competing, UC Berkeley had been assigned number 69.

Team 69, at your service

CyberForce awarded huge points for usability and help-desk support, not just keeping red team out. To secure the ICS modbus service in the handful of weeks we had available, we'd implemented a crude two-step authentication process. Sniffing legitimate LDAP credentials sent in the clear wouldn't be enough to pop our mock oil plant. Red team would also need to know the correct two-step authentication code listed in the user guide.

Terry muted the phone. "Green team wants the two-step auth code."

"It's in the user guide. Tell them to read the user guide."

"Says they don't have access to it."

We had written the user guide from scratch to include an easy look-up table of all the two-step authentication codes. Hacking the green team to steal the user guide was out of scope. Within the constraints of the competition, our solution was as good as it gets.

Battlestations!

Daren rose to his full height, grey goatee jutting forward, and took the phone. "Hello?" He listened for a moment. "I'm going to have to assume you are red team trying to social engineer us. The auth code you need in the user guide." He hung up and passed the phone back to Terry.

"How did they get the number?"

"It's right there on the login page, call this number if you're having troubles."

Nice try, we all thought. Not gonna get that past this team. We weren't born yesterday. Try to socially engineer us ...

Until we read our scoring feedback the day after the competition. It included this nugget: “Tried calling help desk on HMI authentication problem, but another user was logged in and they thought I was from red team.”

Turned out the caller really was green team.

The competition kicked off with a red-tied Rick Perry beaming on the screen.

"Oh, look it's Trump's Secretary of Energy," I said.

"No time. Less than an hour before things get underway."

A week later, while writing this story, I hunted up Perry's opening remarks . Watching him struggle to read a teleprompter made my eye twitch again.

"Today the digital infrastructure that serves this country is literally under attack," Perry intones. "Protecting our energy infrastructure against those threats is my highest priority as Secretary."

"You are this nation's next generation of innovators, defenders, cyberwarriors"―a twinkle in his eye when he says the sexy cyber word―"We need you to bring your knowledge, passion, competitive spirit to, uh, the job at hand."

The worst part of it is, though, Perry's not wrong. Behind the puzzling upbeat muzak in the video and the "howdy, partner" political happy-clappy lurks a truth to wipe the smile off your face: America's critical infrastructure was never meant to be plugged into the internet. Next door to every spy and gangster on the planet, the energy systems on which our economy―and lives―depend are about as secure as a wet paper bag.

Worse, the massive skills shortage in cybertown means few qualified workers have any interest in building a career in OT/ICS/SCADA security. If Google and Facebook pay top dollar for security talent, a water treatment facility in southwestern Montana pays bottom dollar. The DoE wants to expose cybersecurity students to the problem in the hopes of attracting them to the ICS security space―or at least raising awareness of the issue more broadly among career beginners.

CyberForce ―cue flexing muscular men and women on the cover of a vintage Conan the Barbarian pot boiler, oil glistening on scantily-clad physiques, blades flashing, stentorian voice like Zeus announcing their presence―"SIGH BURR FORSS"―launched in 2016, and the December 2018 competition was the fourth so far, and saw double the number of participants as the April competition. The next competition will be held in November 2019.

"The competition is meant for collegiate students to defend and secure an energy-simulated environment," Amanda Joyce, CyberForce Competition Director and Strategic Cybersecurity Analysis and Research Group Lead at Argonne National Laboratory, says in the video. "So every year we change the scenario to be a different energy-based component, this year being oil and high-performance computing. Their job is to take a vulnerable system and to secure it to the best of their ability within realistic environment restrictions."

One surprise gotcha―CyberForce competitors were also lab rats being studied as part of an experiment. I growled at my laptop when I discovered this tidbit buried in a wordy research consent form. Recruiting talent? Cool. Stimulating innovation? Even better. Watching all our VPN traffic and studying us as research subjects? Creepy. Were we the researchers, or the lab mice? Maybe both....

Prey to both red team and researchers.

Out of equal parts alarm and curiosity, I called the Institutional Review Board (IRB) manager at the DoE, a woman with a thick Southern accent by the name of Lindsay Motz. I told her the consent form was opt-out, not opt-in. She seemed genuinely surprised. "You don't have to opt-in in order to compete," she told me over the phone, and encouraged me to reach out to the academic researcher in charge of the project.

"Talk to the pee-AHH," she told me.

I blinked. "The, uh... the who?"

"The pee-AHH."

"I'm sorry, I mean, I, uhh―"

"The principal investigator. The pee-AHH."

"Right, the PI, of course, right... thanks."

The pee-AHH, Benjamin Blakely of Argonne National Lab, sent me a copy of the HRP-503 form, which crisply informs the reader that "gaining an understanding of how to better measure cybersecurity expertise....will help many stakeholders improve training programs, accreditation programs, and workforce frameworks."

Considering the US government's long history of unethical experiments on unwitting human subjects, not to mention totalitarian mass surveillance, giving the DoE the benefit of the doubt was beyond my poor power. The explanations tally, the words all seem correct, but it still felt like they were trying to pull a fast one.

"I don't mind," Karel said. "I've got nothing to hide."

The white-on-black console text blurred together. "I suppose since you've got nothing to say, you don't care about free speech either?"

A shrug. "I think maybe you're reading too much into it."

Then the sCOARboard went down, and a swarm of piranhas feasted on my spleen.

"sCOARboard is down."

"What do you mean sCOARboard is down?"

"It's down. Everyone on Slack is complaining."

"How are we supposed to submit our incident reports?"

Want to check the real-time score updates? Only a refresh-refresh-refresh away―F5 the badly acronymized s COAR board, the competition's score-tracking system. Teams could also earn points by submitting intrusion reports, or bonus points for solving so-called "anomalies"―discrete security problems like analyzing a pcap file in Wireshark , extracting a message from steganography, etc.

In a recent blog post, the Hyperledger project has announced their latest project, Hyperledger Ursa , has been accepted by the Technical Steering Committee (TSC). Ursa’s primary objective is to simplify and consolidate cryptographic libraries in a trusted, consumable manner for use in distributed ledger technology projects in an interoperable way.

Within Project Ursa, a comprehensive library of modular signatures and symmetric-key primitives will be available so developers can swap in and out different cryptographic schemes through configuration and without having to modify their code. In addition to this base library, Ursa will also include newer cryptography, including pairing-based , threshold , and aggregate signatures. In addition to these signatures, zero-knowledge primitives including SNARKs will also be included.

Blockchain security is highly dependentupon cryptographic operations, but for developers, choosing the correct implementation is a challenge. Hart Montgomery , a cryptographic researcher at Fujitsu and a member of the Hyperledger TSC, explains:

The Hyperledger Ursa project has identified the following benefits:

As Hyperledger Ursa is in its infancy, the project has broad future plans, including further investments in modularizing Minicrypt , Montgomery explains:

Project Ursa does not include raw crypto implementations within their library, but chooses to use wrappers for code from existing libraries instead. Montgomery characterizes the benefit as:

Ursa is mostly written in Rust but will have interfaces in all of the different languages that are commonly used throughout Hyperledger including Go, python and Java. The repository for Ursa is available on GitHub .

There is no such thing as a bullet proof system in today’s connected world even banking institutions are not spared. When an incident like what has transpired today with CIMB Malaysia comes to light, you would expect the organisations involved to be well prepared to deal with it in the best interest of everyone involved.

But, that’s always easier said than done, and once again we are faced with yet another security incident that is being poorly handled by those who are tasked with protecting the privacy as well as the financial information of their customers.

Before we get down to the nitty-gritty details, this is what CIMB should have told you weeks ago, but even today, after the social media storm that has taken place, they have yet to enforce a mandatory password change for ALL their users. So if you haven’t already done so, do it NOW. Please change your CIMB Clicks password immediately. ‘Encouraging’ is not an option, as they have so gently requested in their FAQ . We also strongly recommend that if you do not conduct overseas online transactions, to disable overseas transaction option for your CIMB Debit Cards. Whenever possible, set your CIMB Debit card transaction limit to the lowest possible value.

We are aware of the other issues related to CIMB Malaysia, but to avoid any overlaps, we will only be looking at the password issue in this post.

The 8 character issue with CIMB Malaysia’s password is not something new. Frankly speaking, we were able to trace it back all the way to 2011 based on complaints on social media in relation to their constant changing of their password policy.

@CIMB_Assists , did u guys change the length of the password on the login form? It seems now it's limited to 8 characters. I can't login

― Imran Syed Jaafar (@imranjaafar) May 20, 2011

All the passwords i have used with CIMB Clicks Malaysia myself have always been more then 12 characters. Never have i had an 8 character password, but at some point in time, the policy did change and the passwords were limited to 8 characters. Now this in itself is not a simple exercise to do, because even based on the above tweet, when the password length was trimmed down to 8 characters, those with longer passwords were not able to login (without having to change their passwords).

So, CIMB Malaysia, has claimed, that they have once again updated their password policy, and it is now a requirement that the password be between 8-20 characters, and require a combination of letters, numbers and special characters. While it is not specifically mentioned in the FAQ, there is now a mandatory requirement for the new password to contain at least one special character. Why? More on that later.

So, when the new password policy came into effect, CIMB Malaysia somehow decided that instead of compelling all users to do a password change to adhere to the new policy, they would instead allow both new and old passwords to co-exist simultaneously. And instead of making massive changes to how their system would allow this to be done securely, they chose a very simple, insecure, and downright nasty way of doing it.

Essentially, what the code does is this.

So, when this code came into effect, even if you had a password of 15 or 20 characters before November 18, 2018, only the first 8 would be need to be correct to gain access to your account. While this does not automatically grant anybody access to your account, it greatly increases the chances of someone who more or less knows your password habits to guess the right password.

Now, if your password was a combination of letters and numbers, it would be harder to crack, but there are a lot of people who use just numbers as their password. How long does it take to crack a 8 character all number password about 5 minutes.

One of the first tell tale signs that something was seriously wrong with CIMB Clicks Malaysia was when they suddenly, without any warning decided to implement a reCaptcha authentication on their site. This of cause was after the CIMB Clicks platform was completely inaccessible for most of Saturday.

Some smaller banks around the world do turn to Google’s reCaptcha to keep away unwanted traffic because its free, and extremely easy to implement, but to say reCaptcha has been implemented to enhance customers’ security is nothing but a blatant lie.

What reCaptcha does is slows down spam bots (and in the case of CIMB Clicks brute force scripts) from hammering their system with millions of queries as it tries every single password combination to get into a customers account.

There are so many more elegant, secure and much more effective ways to keep spam bots, nasty scripts and even malicious users away, and reCaptcha does not figure anywhere on this list for an organisation of this size.

We are going to get a little technical here for the last bit, so turn away now if you must. Based on the minified javascript we went through on the CIMB Clicks site, we are fairly certain that post 18th November, the passwords are now stored in a one way hash algorithm, making them quite secure in the event of any future breaches.

However, we are now somewhat concerned on how the passwords were stored before November 18th. There are generally two ways that passwords are usually stored on the backend databases of any systems (we say two, because we are hoping to God that it isn’t stored in plaintext). It could have been encrypted, or it could have been hashed.

There's little argument that Social Security is a financial pillar for most seniors. Each month, more than 43 million retired workers receive a benefit check, with more than 60% of these retirees leaning on the program to account for at least half of their income.

There's also little disagreement that Social Security is in trouble and needs Congress to fix it.

According to the latest annual report from the Board of Trustees, Social Security is set to hit an inflection point this year that sees more money spent than is collected for the first time since 1982 . Although the amount of money flowing out of the Trust's asset reserves is estimated to be relatively small ($1.7 billion) compared to the nearly $2.9 trillion currently in asset reserves, this net cash outflow is expected to accelerate in the years to come. By 2034, ongoing demographic and economic changes are forecast to have completely exhausted Social Security's almost $2.9 trillion in excess cash. Should this happen, and if Congress fails to act, an across-the-board benefits cut of up to 21% may be needed to sustain payouts through the year 2092.

View photos

A Social Security card wedged between IRS tax forms and lying next to a pair of glasses and a twenty-dollar bill.

Image source: Getty Images.

To be certain, there are solutions aplenty that have been proposed by Democrats and Republicans to resolve the estimated $13.2 trillion cash shortfall between 2034 and 2092. But ask the average retired American what he or she wants, and they're liable to retort that they'd like to see the taxation of Social Security benefits done away with. Some 91% of retired Americans favored an end to the taxation of benefits in a survey conducted by The Seniors Center, a Washington, D.C.-based nonprofit organization that looks out for senior interests, last year.

So why doesn't the federal government abide by the will of the people? Frankly, it's because the taxation of benefits has put Social Security between a rock and a hard place.

Who faces this tax, you ask? Single taxpayers whose adjusted gross income (AGI) plus one-half of their benefits exceeds $25,000 and couples filing jointly whose AGI plus one-half of benefits tops $32,000 could have up to 50% of their Social Security payout taxed at federal ordinary income rates. This initial level of taxation was signed into law in 1983 during the last major overhaul of the program by then-President Ronald Reagan.

View photos

A worried senior man tightly gripping his piggy bank as outstretched hands reach for it.

Image source: Getty Images.

Since then, a second tier of taxation was added in 1993 under the Clinton administration that allows up to 85% of benefits to be taxed. The income thresholds here are more than $34,000 for single beneficiaries and in excess of $44,000 for couples filing jointly. When first implemented in 1984, the taxation of benefits impacted about 1 in 10 senior households. As of 2018, The Senior Citizens League estimates that 56% of senior households are facing some degree of taxation on their Social Security benefits.

The reason for this disparity is simple: The income thresholds noted above haven't once been adjusted for inflation since being introduced. As such, more and more retired workers are becoming subject to some level of taxation on their benefits as income levels have grown.

So why not just adjust these income thresholds for inflation -- or better yet, remove the tax entirely and allow beneficiaries to keep their entire benefit? Doing so would, presumably, give more than half of all Social Security recipients a "raise." Even just adjusting the income thresholds for inflation would stop exposing middle-income seniors and couples to taxation.

But herein lies the problem . With Social Security facing a $13.2 trillion cash shortfall between 2034 and 2092 and the program forecast to begin running in the red in 2018, adjusting the income thresholds for inflation or removing this tax entirely means giving up precious revenue -- revenue that simply can't be tossed out right now.

View photos

A worried mature couple closely examining their finances.

Image source: Getty Images.

As a reminder, Social Security only has three sources of revenue : (1) the 12.4% payroll tax on earned income of up to $128,400 (as of 2018), (2) the taxation of benefits, and (3) interest income earned on its asset reserves. By 2034, assuming the Trustees are correct about the Trust's excess cash being depleted, there will no longer be any interest income flowing into Social Security. If the taxation of benefits were removed, too, it would leave the payroll tax as the sole provider of the program.

Over time, the taxation of benefits is projected to play a larger role in revenue collection. Last year, it was responsible for $37.9 billion of the $996.6 billion collected. By 2027, it's forecast to bring in $88.1 billion of the $1.55 trillion collected that year. As a percentage of revenue collected, and in nominal terms, the taxation of benefits is only growing in importance.

Thus the dilemma: Removing this tax or adjusting it for inflation would provide a short-term boost for existing retirees, but over the long run would cause the program to generate even less revenue and burn through its asset reserves even faster. Chances are that more than a 21% across-the-board cut would be needed to sustain payouts through 2092 without the taxation of benefits.

This tax may be a sore spot among retirees, but it's not going anywhere anytime soon.

The Motley Fool has a disclosure policy .

答：网络安全是指网络系统的硬件、软件及其系统中的数据受到保护，不因偶然的或者恶意的原因而遭到破坏、更改、泄露，系统可以连续可靠正常地运行，网络服务不被中断。

答：计算机病毒(Computer Virus)是指编制者在计算机程序中插入的破坏计算机功能或者破坏数据，影响计算机使用并且能够自我复制的一组计算机指令或者程序代码。

答：木马是一种带有恶意性质的远程控制软件。木马一般分为客户端(client)和服务器端(server)。客户端就是本地使用的各种命令的控制台，服务器端则是要给别人运行，只有运行过服务器端的计算机才能够完全受控。木马不会像病毒那样去感染文件。

答：使用防火墙(Firewall)是一种确保网络安全的方法。防火墙是指设置在不同网络(如可信任的企业内部网和不可信的公共网)或网络安全域之间的一系列部件的组合。它是不同网络或网络安全域之间信息的惟一出入口，能根据企业的安全政策控制(允许、拒绝、监测)出入网络的信息流，且本身具有较强的抗攻击能力。它是提供信息安全服务，实现网络和信息安全的基础设施。

答：后门(Back Door)是指一种绕过安全性控制而获取对程序或系统访问权的方法。在软件的开发阶段，程序员常会在软件内创建后门以便可以修改程序中的缺陷。如果后门被其他人知道，或是在发布软件之前没有删除，那么它就成了安全隐患。

答：入侵检测是防火墙的合理补充，帮助系统对付网络攻击，扩展系统管理员的安全管理能力(包括安全审计、监视、进攻识别和响应)，提高信息安全基础结构的完整性。它从计算机网络系统中的若干关键点收集信息，并分析这些信息，检查网络中是否有违反安全策略的行为和遭到袭击的迹象

答：数据包监测可以被认为是一根窃听电话线在计算机网络中的等价物。当某人在“监听”网络时，他们实际上是在阅读和解释网络上传送的数据包。如果你需要在互联网上通过计算机发送一封电子邮件或请求下载一个网页，这些操作都会使数据通过你和数据目的地之间的许多计算机。这些传输信息时经过的计算机都能够看到你发送的数据，而数据包监测工具就允许某人截获数据并且查看它。

答：NIDS是Network Intrusion Detection System的缩写，即网络入侵检测系统，主要用于检测Hacker或Cracker通过网络进行的入侵行为。NIDS的运行方式有两种，一种是在目标主机上运行以监测其本身的通信信息，另一种是在一台单独的机器上运行以监测所有网络设备的通信信息，比如Hub、路由器。

答：TCP连接的第一个包，非常小的一种数据包。SYN攻击包括大量此类的包，由于这些包看上去来自实际不存在的站点，因此无法有效进行处理。

答：加密技术是最常用的安全保密手段，利用技术手段把重要的数据变为乱码(加密)传送，到达目的地后再用相同或不同的手段还原(解密)。

加密技术包括两个元素：算法和密钥。算法是将普通的信息或者可以理解的信息与一串数字(密钥)结合，产生不可理解的密文的步骤，密钥是用来对数据进行编码和解密的一种算法。在安全保密中，可通过适当的钥加密技术和管理机制来保证网络的信息通信安全。

答：蠕虫病毒(Worm)源自第一种在网络上传播的病毒。1988年，22岁的康奈尔大学研究生罗伯特。莫里斯(Robert Morris)通过网络发送了一种专为攻击UNIX系统缺陷、名为“蠕虫”(Worm)的病毒。蠕虫造成了6000个系统瘫痪，估计损失为200万到6000万美元。由于这只蠕虫的诞生，在网上还专门成立了计算机应急小组(CERT)。现在蠕虫病毒家族已经壮大到成千上万种，并且这千万种蠕虫病毒大都出自黑客之手。

答：这种病毒会用它自己的程序加入操作系统或者取代部分操作系统进行工作，具有很强的破坏力，会导致整个系统瘫痪。而且由于感染了操作系统，这种病毒在运行时，会用自己的程序片断取代操作系统的合法程序模块。根据病毒自身的特点和被替代的操作系统中合法程序模块在操作系统中运行的地位与作用，以及病毒取代操作系统的取代方式等，对操作系统进行破坏。同时，这种病毒对系统中文件的感染性也很强。

答：它的编写者是美国康乃尔大学一年级研究生罗特。莫里斯。这个程序只有99行，利用了Unix系统中的缺点，用Finger命令查联机用户名单，然后破译用户口令，用Mail系统复制、传播本身的源程序，再编译生成代码。

最初的网络蠕虫设计目的是当网络空闲时，程序就在计算机间“游荡”而不带来任何损害。当有机器负荷过重时，该程序可以从空闲计算机“借取资源”而达到网络的负载平衡。而莫里斯蠕虫不是“借取资源”，而是“耗尽所有资源”。

答：DDoS也就是分布式拒绝服务攻击。它使用与普通的拒绝服务攻击同样的方法，但是发起攻击的源是多个。通常攻击者使用下载的工具渗透无保护的主机，当获得该主机的适当的访问权限后，攻击者在主机中安装软件的服务或进程(以下简称代理)。这些代理保持睡眠状态，直到从它们的主控端得到指令，对指定的目标发起拒绝服务攻击。随着危害力极强的黑客工具的广泛传播使用，分布式拒绝服务攻击可以同时对一个目标发起几千个攻击。单个的拒绝服务攻击的威力也许对带宽较宽的站点没有影响，而分布于全球的几千个攻击将会产生致命的后果。

答：ARP协议的基本功能就是通过目标设备的IP地址，查询目标设备的MAC地址，以保证通信的进行。

基于ARP协议的这一工作特性，黑客向对方计算机不断发送有欺诈性质的ARP数据包，数据包内包含有与当前设备重复的Mac地址，使对方在回应报文时，由于简单的地址重复错误而导致不能进行正常的网络通信。一般情况下，受到ARP攻击的计算机会出现两种现象：

1.不断弹出“本机的XXX段硬件地址与网络中的XXX段地址冲突”的对话框。

2.计算机不能正常上网，出现网络中断的症状。

因为这种攻击是利用ARP请求报文进行“欺骗”的，所以防火墙会误以为是正常的请求数据包，不予拦截。因此普通的防火墙很难抵挡这种攻击。

答：网络欺骗的技术主要有：HONEYPOT和分布式HONEYPOT、欺骗空间技术等。主要方式有：IP欺骗、ARP欺骗、DNS欺骗、Web欺骗、电子邮件欺骗、源路由欺骗(通过指定路由，以假冒身份与其他主机进行合法通信或发送假报文，使受攻击主机出现错误动作)、地址欺骗(包括伪造源地址和伪造中间站点)等。

My so far last BugBountyNotes challenge is called Can you get the flag from this browser extension? . Unlike theprevious one, this isn’t about exploiting logical errors but the more straightforward Remote Code Execution. The goal is running your code in the context of the extension’s background page in order to extract the flag variable stored there.

If you haven’t looked at this challenge yet, feel free to stop reading at this point and go try it out. Mind you, this one is hard and only two people managed to solve it so far. Note also that I won’t look at any answers submitted at this point any more. Of course, you can also participate in any of the ongoing challenges as well.

Still here? Ok, I’m going to explain this challenge then.

This browser extension is a minimalist password manager: it doesn’t bother storing passwords, only login names. And the vulnerability is of a very common type: when generating HTML code, this extension forgets to escape HTML entities in the logins:

Since the website can fill out and submit a form programmatically, it can make this extension remember whichever login it wants. Making the extension store something like login<img src=x onerror=alert(1)> will result in javascript code executing whenever the user opens the website in future. Trouble is: the code executes in the context of the same website that injected this code in the first place, so nothing is gained by that.

What you’d really want is having your script run within the content script of the extension. There is an interesting fact: if you call eval() in a content script, code will be evaluated in the context of the content script rather than website context. This happens even if the extension’s content security policy forbids eval: content security policy only applies to extension pages, not to its content scripts. Why the browser vendors don’t tighten security here is beyond me.

And now comes something very non-obvious. The HTML code is being inserted using the following:

One would think that jQuery uses innerHTML or its moral equivalent here but that’s not actually true. innerHTML won’t execute JavaScript code within <script> tags, so jQuery is being “helpful” and executing that code separately. Newer jQuery versions will add a <script> tag to the DOM temporarily but the versions before jQuery 2.1.2 will essentially call eval() . Bingo!

So your payload has to be something like login<script>alert(1)</script> , this way your code will run in the context of the content script.

The content script can only communicate with the background page via messaging. And the background page only supports two commands: getLogins and addLogin . Neither will allow you to extract the flag or inject code.

But the way the background page translates message types into handlers is remarkable:

So here is my complete solution. As usually, this is only one way of doing it.

The Trail of Bits cryptographic services team contributed two cryptography CTF challenges to the recent CSAW CTF . Today we’re going to cover the easier one, titled “Disastrous Security Apparatus Good luck, ‘k?”

This problem involves the Digital Signature Algorithm (DSA) and the way an apparently secure algorithm can be made entirely insecure through surprising implementation quirks. The challenge relies on two bugs, one of which was the source of the Playstation 3 firmware hack , while the other is a common source of security vulnerabilities across countless software products. Despite both of these issues having been known for many years a large number of software developers (and even security engineers) are unfamiliar with them.

If you’re interested in solving the challenge yourself get the code here and host it locally. Otherwise, read on so you can learn to spot these sorts of problems in code you write or review.

Participants were given the source code ( main.py ) and an active HTTP server they could contact. This server was designed to look roughly like an online signing server. It had an endpoint that signed payloads sent to it and a partially implemented login system with password reset functionality.

The enumerated set of routes:

To capture the flag we’ll need to recover the DSA private key and use that to sign an encrypted payload from the /challenge endpoint. We then submit both the challenge value and the signature to /capture . This allows the server to verify you’ve recovered the private key. Let’s go!

A complete DSA key is made up of 5 values: p , q , g , x , and y .

p , q , g , and y are all public values. The /public_key endpoint on the server gives these values and can be used to verify that a given signature is valid. The private value, x , is what we need. A DSA signature is normally computed as follows

The signer implementation in main.py conveniently possesses this exact code

To confirm that r and s are correct you can also perform a DSA verification.

At this point v should be equal to r .

We’ve seen the math involved in generating and verifying a DSA signature, but we really want to use the set of values we know to recover a value we do not ( x , the private scalar). Recall this equation?

s = (kinv * (h + r * x)) % q

A DSA signature is composed of two values: r and s . We also know h is the value that is being signed and with a signing oracle we pick that value. Finally, we know q as that is part of the public key that is used to verify a DSA signature. This leaves us with two unknowns: kinv and x . Let’s solve for x :

rinv is calculated just like kinv (the modular multiplicative inverse ).

As you can see from the final equation, if we can determine the k used for any given signature tuple (r, s) then we can recover the private scalar. But k is generated via random.randrange so it’s not predictable.

近日，互联网上爆发了一种名为 lucky 的勒索病毒，该病毒会将指定文件加密并修改后缀名为 .lucky 。

知道创宇 404 实验室的炼妖壶蜜罐系统最早于 2018.11.10 就捕捉到该勒索病毒的相关流量，截止到 2018.12.04 日，该病毒的 CNC 服务器依然存活。

根据分析的结果可以得知 lucky 勒索病毒几乎就是 Satan 勒索病毒，整体结构并没有太大改变，包括 CNC 服务器也没有更改。Satan 病毒一度变迁：最开始的勒索获利的方式变为挖矿获利的方式，而新版本的 lucky 勒索病毒结合了勒索和挖矿。

知道创宇 404 实验室在了解该勒索病毒的相关细节后，迅速跟进并分析了该勒索病毒；着重分析了该病毒的加密模块，并意外发现可以利用伪随机数的特性，还原加密密钥，并成功解密了文件，python 的解密脚本链接： https://github.com/knownsec/Decrypt-ransomware 。

本文对 lucky 勒索病毒进行了概要分析，并着重分析了加密流程以及还原密钥的过程。

lucky 勒索病毒可在 windows 和 linux 平台上传播执行，主要功能分为「文件加密」、「传播感染」与「挖矿」。

文件加密

lucky 勒索病毒遍历文件夹，对如下后缀名的文件进行加密，并修改后缀名为 .lucky ：

为了保证系统能够正常的运行，该病毒加密时会略过了系统关键目录，如：

传播感染

lucky 勒索病毒的传播模块并没有做出新的特色，仍使用了以下的漏洞进行传播：

挖矿

该勒索病毒采用自建矿池地址： 194.88.105.5:443 ，想继续通过挖矿获得额外的收益。同时，该矿池地址也是 Satan 勒索病毒变种使用的矿池地址。

运行截图

lucky 勒索病毒的整体结构依然延续 Satan 勒索病毒的结构，包括以下组件：

流程图大致如下：

lucky 勒索病毒的每个模块都使用了常见的壳进行加壳保护，比如 UPX ， MPRESS ，使用常见的脱壳软件进行自动脱壳即可。

对于一个勒索病毒来说，最重要的就是其加密模块。在 lucky 勒索病毒中，加密模块是一个单独的可执行文件，下面对加密模块进行详细的分析。(以 Windows 下的 cpt.exe 作为分析样例)

1.脱去upx

cpt.exe 使用 upx 进行加壳，使用常见的脱壳工具即可完成脱壳。

2.加密主函数

使用 IDA 加载脱壳后的 cpt.exe.unp ，在主函数中有大量初始化的操作，忽略这些操作，跟入函数可以找到加密逻辑的主函数，下面对这些函数进行标注：

generate_key : 生成 60 位随机字符串，用于后续加密文件。

wait_sleep : 等待一段时间。

generate_session : 生成 16 位随机字符串，作为用户的标志(session)。

lucky_crypto_entry : 具体加密文件的函数。

send_info_to_server : 向服务器报告加密完成。

大致的加密流程就是函数标注的如此，最后写入一个文件 c:\\_How_To_Decrypt_My_File_.Dic ，通知用户遭到了勒索软件加密，并留下了比特币地址。

3.generate_key()

该函数是加密密钥生成函数，利用随机数从预设的字符串序列中随机选出字符，组成一个长度为 60 字节的密钥。

byte_56F840 为预设的字符串序列，其值为：

4.generate_session()

加密模块中使用该函数为每个用户生成一个标识，用于区分用户；其仍然使用随机数从预设的字符串序列中随机选出字符，最后组成一个长度为 16 字节的 session，并存入到 C:\\Windows\\Temp\\Ssession 文件下。

其中 byte_56F800 字符串为：

该函数为加密文件的函数入口，提前拼接加密文件的文件名格式，如下：

被加密的文件的文件名格式如下：

其中 filename 是文件本身的名字，后续的字符串是用户的 session。

在加密前，还会首先向服务器发送 HTTP 消息，通知服务器该用户开始执行加密了：

HTTP 数据包格式如下：

在加密模块中，lucky 对指定后缀名的文件进行加密：

被加密的后缀名文件包括：

6.AES_ECB 加密方法

lucky 使用先前生成的长度为 60 字节的密钥，取前 32 字节作为加密使用，依次读取文件，按照每 16 字节进行 AEC_ECB 加密。

除此之外，该勒索病毒对于不同文件大小有不同的处理，结合加密函数的上下文可以得知，这里我们假设文件字节数为 n：

对于每个文件在加密完成后，lucky 病毒会将用于文件加密的 AES 密钥使用 RSA 算法打包并添加至文件末尾。

7.加密完成

在所有文件加密完成后，lucky 再次向服务器发送消息，表示用户已经加密完成；并在 c:\\_How_To_Decrypt_My_File_.Dic ，通知用户遭到了勒索软件加密。

加密前后文件对比：

在讨论密钥还原前，先来看看勒索病毒支付后流程。

如果作为一个受害者，想要解密文件，只有向攻击者支付 1BTC，并把被 RSA 算法打包后的 AES 密钥提交给攻击者，攻击者通过私钥解密，最终返回明文的 AES 密钥用于文件解密；可惜的是，受害者即便拿到密钥也不能立即解密，lucky 勒索病毒中并没有提供解密模块。

勒索病毒期待的解密流程：

在完整的分析加密过程后，有些的小伙伴可能已经发现了细节。AES 密钥通过 generate_key() 函数生成，再来回顾一下该函数：

利用当前时间戳作为随机数种子，使用随机数从预设的字符串序列中选取字符，组成一个长度为 60 字节的密钥。

随机数=>伪随机数

有过计算机基础的小伙伴，应该都知道计算机中不存在真随机数，所有的随机数都是伪随机数，而伪随机数的特征是「对于一种算法，若使用的初值(种子)不变，那么伪随机数的数序也不变」。所以，如果能够确定 generate_key() 函数运行时的时间戳，那么就能利用该时间戳作为随机种子，复现密钥的生成过程，从而获得密钥。

当然，最暴力的方式就是直接爆破，以秒为单位，以某个有标志的文件(如 PDF 文件头)为参照，不断的猜测可能的密钥，如果解密后的文件头包含 %PDF (PDF 文件头)，那么表示密钥正确。

还有其他的方式吗？文件被加密后会重新写入文件，所以从操作系统的角度来看，被加密的文件具有一个精确的修改时间，可以利用该时间以确定密钥的生成时间戳：

如果需要加密的文件较多，加密所花的时间较长，那么被加密文件的修改时间就不是生成密钥的时间，应该往前推移，不过这样也大大减少了猜测的范围。

利用文件修改时间大大减少了猜测的范围；在实际测试中发现，加密文件的过程耗时非常长，导致文件修改时间和密钥生成时间相差太多，而每次都需要进行检查密钥是否正确，需要耗费大量的时间，这里还可以使用用户 session 进一步缩小猜测的范围。

回顾加密过程，可以发现加密过程中，使用时间随机数生成了用户 session，这就成为了一个利用点。利用时间戳产生随机数，并使用随机数生成可能的用户 session，当找到某个 session 和当前被加密的用户 session 相同时，表示该时刻调用了 generate_session() 函数，该函数的调用早于文件加密，晚于密钥生成函数。

找到生成用户session 的时间戳后，再以该时间为起点，往前推移，便可以找到生成密钥的时间戳。

补充：实际上是将整个还原密钥的过程，转换为寻找时间戳的过程；确定时间戳是否正确，尽量使用具有标志的文件，如以 PDF 文件头 %PDF 作为明文对比。

还原密钥

通过上述的方式找到时间戳，利用时间戳就可以还原密钥了，伪代码如下：

文件解密

拿到了 AES 密钥，通过 AES_ECB 算法进行解密文件即可。

其中注意两点：

勒索病毒依然在肆掠，用户应该对此保持警惕，虽然 lucky 勒索病毒在加密环节出现了漏洞，但仍然应该避免这种情况；针对 lucky 勒索病毒利用多个应用程序的漏洞进行传播的特性，各运维人员应该及时对应用程序打上补丁。

除此之外，知道创宇 404 实验室已经将文中提到的文件解密方法转换为了工具，若您在此次事件中，不幸受到 lucky 勒索病毒的影响，可以随时联系我们。

References:

tencent: https://s.tencent.com/research/report/571.html

绿盟: https://mp.weixin.qq.com/s/uwWTS_ta29YlYntaZN3omQ

深信服: https://mp.weixin.qq.com/s/zA1bK1sLwaZsUvuOzVHBKg

Python 的解密脚本: https://github.com/knownsec/Decrypt-ransomware

图为病毒作者被捕照片

有些事从开始就注定了结局，年仅22岁的罗生（化名）可能没想到这一天来的这么快，刺激、兴奋、担忧、害怕、恐惧、麻木、坦然，仅仅5天这个年轻人可谓体会了一把“人生巅峰”。

他出于什么目的开发的病毒？

为什么他选择微信支付来作为勒索收款？

真如安全专家所述“入门小学生级”的病毒？

勒索了多少钱，有多少人因此支付索金？

图为12月4号跟病毒作者的QQ聊天记录

图为12月4号跟病毒作者的QQ聊天记录

“平安东莞：获悉省厅网警总队下发线索后，东莞网警快速反应，立即启动网络安全事件应急处置预案，调集骨干警力，对涉案线索开展排查，于12月4日22时准确摸排出嫌疑人真实身份为罗某某（男，22岁，广东茂名人），其主要在我市东坑镇活动。12月5日凌晨，东莞网警联合东坑分局连夜展开抓捕行动，经十小时连续奋战，于15时将嫌疑人罗某某抓获。

――这可能是第一个也可能是最后一个，在他被捕之前的对话。

我实在过于好奇，到底罗生是怎么样一个人，从如何学会的开发病毒，到敢正大光明的用实名微信支付作为勒索收款，然后又堂而皇之的在论坛大肆传播病毒（论坛名就是自己的QQ号）。

当他当知道自己出名了（被媒体报道），开发的病毒也被破解了，个人隐私信息被公之于众了，他该如何面对这一切？在12月4日23点寒冷的夜晚，我只等到轻飘飘的一句话：“打lol中，再见”。

同作为90后的程序员，这种种离奇现象和小说般跌宕起伏的故事，促使我想要了解真相。

图为勒索病毒界面

时间回到12月月初，由火绒安全发出的一则通告在微博备受关注“国内首款勒索病毒要求微信支付”，这一事件经过微博的连续多天爆料，多篇技术文章介绍，短短1、2天，安全领域的专家就将病毒破解，并把病毒的运作原理和开发者的详细个人资料被公之于众，引发大量网友参与讨论和关注。

图为大量新闻标题

其实每天都有成千上万的病毒诞生，按常理来看一个病毒不该如此备受关注，可谁也没想到，病毒居然贴上了微信支付二维码用于勒索，而微信是家喻户晓，大家最常用的软件，而勒索病毒跟微信支付扯上关系以后，普通人对此不了解，再加以某些媒体的标题误导，大伙还以为是微信支付出了问题，因此引发大量网友关注。

图为豆瓣网传播中间页

通过分析病毒本身原理得知，主要利用了豆瓣网进行中介传播，其作恶方式不仅对用户电脑资料加密勒索钱财，还盗取电脑存储的淘宝、支付宝、百度云网盘账号密码，这样一来，牵扯到了微信、支付宝、豆瓣、百度，四大互联网公司，一个小病毒也能掀起大风浪，导致人心惶惶。

与此同时，国内的其他安全厂商也不甘示弱：腾讯安全、360安全等，纷纷发出通告文章，宣称可查杀此类病毒，推出专项反勒索工具，而腾讯更是出手迅速，毕竟QQ、微信都被人公之于众了，可谓是完全掌握用户的一手资料，再配合自家地区的警方抓捕勒索病毒作者，24小时成功破案。

由于该病毒的原理很简单，且病毒本身也没有任何加密防护的手段，相比较同为勒索支付病毒，并且全球闻名的“永恒之蓝”病毒可就差的太远了，但即便如此，在网络安全领域，谁第一个发现，第一个解决，在行业内的声望和知名度自然不言而喻，火绒安全虽然是率先发布并公告信息，但不代表其他同行能愿意让他独享光环。

图为火绒安全CEO微博评论

“瑞星安全：为什么被称为“小学生”式勒索病毒？瑞星安全专家通过对其分析发现，该勒索病毒由易语言编写，易语言是一门以中文作为程序代码的编程语言，属于初级入门级语言，从这一点就可以看出勒索病毒作者代码水平还比较初级。

瑞星安全专家语出惊人，称该病毒为“小学生”式勒索病毒，且该病毒只排2颗星，危害较小。

“瑞星安全：病毒编写――初级。该勒索病毒由易语言编写，易语言是一门以中文作为程序代码的编程语言，属于初级入门级语言，从这一点就可以看出勒索病毒作者代码水平还比较初级。

图为瑞星专家给出的病毒等级分类

瑞星安全专家更是直接点评“易语言”为：初级入门语言，用这个语言写的代码水平比较初级。

“360安全&浅黑科技：从只有中国人才用的“小霸王学习机”易语言，到中国特色的薅羊毛软件，到通过豆瓣和QQ空间进行病毒投放，到微信支付收勒索款，再到这个22岁的青年所思考的一切。

无独有偶，在360安全专家王亮和浅黑科技史中的眼里，易语言定性为只有中国人才用的“小霸王学习机”。

“W3Cschool：学生、工人、教师及更行业的人，使用易语言编写软件，来解决一些问题，不具有通用性，通常只能在小范围传播，不会再网上推广，用户也很少。而黑灰产业需要通过网络传播赚钱，传播范围广、用户多，影响大。所以大家也眼里通常会只有黑灰产业。对于“易语言”这个不入流的语言，你是怎么看的呢？

W3Cschool更是评易语言为：不入流的语言，且称哪怕让这些下岗工人、学生、老师这些行业的人学会了编程，写出的软件也没什么用。

一个编程语言，按理说不该背这锅，可为什么大家提到它就言辞轻蔑，各种歧视接踵而来，我们的关注点不应该放在非法分子，勒索病毒，受害者等身上吗？

“易语言作者：目前杀毒软件基本上都采用“特征码”查毒技术，就是从病毒体中寻找一段“特征”数据，以后凡是看到其它文件具有这个“特征”，就认为是病毒。这种技术有着其天生的弊端：就是很难保证“特征码”的准确性和唯一性，如果正常的文件里面也碰巧有这种特征码，就会产生误报。对于易语言来说，这个弊端尤为突出。由于易语言功能强大，经常有一些不负责的用户使用它来写木马或者病毒，而杀软在这些文件里面采集特征码的时候，却采集到了易语言编译器本身所产生的正常代码上，这样就导致一产生误报，所有正常的易语言软件就会被误报！

国内几大知名安全厂商，如果说在商业上，那一定是死敌，各看各不顺眼，但是唯独对待易语言的态度却是难得的十分统一，仿佛提前商量好一般：先不管是什么程序，如果是易语言写的直接报毒。

图为360专门为易语言设立的误报反馈页面

而对用户来说，一开始，从网上下载的软件虽然被杀毒软件提示有风险，软件用不了肯定很紧张，赶紧问问周边的朋友是什么情况，然后得知，“没事，易语言写的，被误报很正常嘛”。

仍心情忐忑的点了忽略风险提醒以后，使用一阵子，发现没出什么问题嘛，当下次在遇到类似情况，一次、两次，长期以往，用户就产生了见怪不怪，对待软件报毒的懈怠。

则有了如今依靠易语言编写出来的勒索病毒的滋生环境，起初用户还以为是正常误报，可没过一会电脑被锁屏，提示需要微信支付才能解锁，这一来用户就彻底慌了，求助杀毒厂商，这才有了后来的事情。

原来，某些知名安全厂商被吹上神坛的反病毒引擎、杀毒软件，连所谓的病毒原理也无法分析清楚，以至于在未知的情况下仅能依靠概率来判断，软件与病毒的区别，甚至直接大手一挥，把某个编程语言开发的软件通通纳入病毒行列，反正是不是病毒，我告诉你有风险了，你不相信我，也不能怪我。

这次可以说是用户的不小心，下载来历不明的软件，忽略了风险提醒，那下次用户再面临网上下载的软件，是不是该继续赌运气，赌它是不是病毒误报呢？

同作为一门编程语言，C语言、.NET、JAVA、php，就不能开发病毒了吗？如今互联网时代，每天都会有新的电脑病毒、手机病毒、网页病毒的诞生，但为什么这些所谓安全专家从不去点评其他编程语言？

其实道理他们都懂的，开发的软件也好，病毒也好，压根不是编程语言的错，就好像谁用水果刀行凶犯法，你能去找超市理论，凭什么卖刀给他？

“但没办法呀，病毒是别家公司先破解的，技术文章道理都被他们写完了，我们总不能在后面跟风鼓掌吧，这不是助长他人威风嘛，只好踩一踩，骂一骂这个易语言，谁让你那么简单，还全中文编程，什么阿猫阿狗都能学，这么容易被人学了就能开发软件做病毒，不是给我们添乱嘛？

易语言只是一个小公司开发的产品，没什么背景和后台，很多从事易语言的开发者一直也默认了行业内误报的“潜规则”，甚至互相劝解告慰，蚂蚁斗不过大象，还是想办法怎么样多和客户解释误报吧。

我不想看着一门国产编程语言，成为某些公司用低劣的手段来博取用户口碑的垫脚石，如果说今天的易语言换成腾讯的小程序，安全领域的某些专家还敢这么言不着调的评论吗？

编程语言就是一门工具，如果因为一门语言的学习门槛低，低到坏人可以学习他拿来做坏事，反过来苛责一门编程语言，那倒不如干脆把互联网封闭，把百度关停，因为坏人利用互联网搜索学习资料更快更便捷。

End.

一场华丽的闹剧，表演者还没来得及开始就已经宣告结束，黄牛们措手不及只好迁怒于舞台和剧场，丑态百出的事故现场，不妨碍围观群众看了一出“好戏”，而主办方则躲在角落里默默的流眼泪，全给别人做嫁衣。

本文授权产品壹佰独家原创，转载保留出处。

一开始，我关注研究的是business.google.com和其子域名，随便试试了它上面的各种功能，分析一下请求和响应内容，编辑请求参数，等等。但当我操作用户管理时，却又跳转到了myaccount.google.com。

用BurpSuite测试了一下，发现这个服务端并没有 X-Frame-Option 的头设置。X-Frame-Options响应头是用来给浏览器指示允许一个页面可否在<frame>,<iframe>或者<object>中展现的标记，网站可以使用此功能，来确保自己网站的内容没有被嵌到别人的网站中去，也从而避免了点击劫持 (clickjacking) 的攻击。X-Frame-Options有三种可配置值，分别是DENY、SAMEORIGIN和ALLOW-FROM。

看到了这里之后，我用Firefox ESR浏览器，构造了一个包含iframe的html跳转页面cj.html，iframe中写入了我的myaccount.google.com和business.google.com账号。逻辑是没错的，但是最终却被Google自身的CSP策略给挡了。

这样我就放着一边了，后来到8月15日，我又坐下来慢慢研究，我在想触发CSP的难道是出在了其跳转源的origin参数上吗？所以，我把心思放到了origin参数的business.google.com之上。

由于构造的跳转页面中，其iframe片段中包含的链接为：

https://myaccount.google.com/u/0/brandaccounts/group/101656179839819660704/managers?originProduct=AC&origin=https://business.google.com

响应情况为：

没事，我有的是时间。所以，我又往origin参数里添加了一些其它字符，比如加了一个回车符%0d，变为URL编码后的 https://%0d.business.google.com ，最终iframe中的URL为：

https://myaccount.google.com/u/0/brandaccounts/group/101656179839819660704/managers?originProduct=AC&origin=https://%0d.business.google.com

这样一试，CSP竟然没跳出来了！t!!!!?!@?#!@?3!@?3?

如果你问我是怎么想到绕过CSP的方法的，其实我也不知道，就是乱试呗，看运气。上报Google之后，我估计赏金也就3,133.7 或 5,000美金左右，但是，Google最终给我的却是$ 7,500美金！

<iframe src=” https://myaccount.google.com/u/0/brandaccounts/group/ {your-group-id}/managers?originProduct=AC&origin= https://%0d.business.google.com ” width=”1000″ height=”1000″>

漏洞攻击适用场景：

*参考来源： apapedulime ，clouds编译，转载请注明来自CodeSec.Net

科技界的鲸鱼(whales of the tech world)对私人数据的安全和管理给这些科技巨头的声明的合法性打上了一个大大的问号。最近谷歌CEO Sundar Pichai在国会举行的听证会对这项事业没有帮助。那么，什么是最安全的平台，既能保证用户隐私数据的安全，又不把权利分配给出价最高的人?

区块链一直被宣传为可信赖和分散的系统，可以解决当前互联网系统中的所有安全漏洞问题。每当我们看到互联网革命的一个或另一个副产品被捕捉到操纵用户数据的新发展时，我们往往会将目光转向区块链。

那么，区块链技术到底有多安全、不可破解呢?我们将尝试批判性地分析相对新技术的各个方面，并破除一些关于它是篡改证明和不可破解的神话。

区块链也不能幸免于网络攻击

区块链专家会告诉你，这项技术是万无一失的，没有人可以篡改它。但是，永远记住，问题不在于技术本身，而在于它周围的人。任何新老技术都有几个弱点，攻击矢量和区块链也不例外。我们将深入探究加密货币的短暂历史，看看哪些攻击媒介是最突出的，或者接近打破“不可破解”的区块链技术的神话。

女巫攻击

区块链技术被认为是优越的，因为它是分布式的分类帐或节点，其中每个节点的验证都依赖于前一个。然而，女巫攻击为那些认为分布式分类账=防篡改技术的人打破了泡沫。

在女巫攻击的情况下，大量的节点是由单个方拥有的，它们可以使用累加的节点来操纵网络。持有者可以用虚假的交易填充节点，或者通过区块操纵来破坏真实的交易。

幸好女巫攻击目前只存在于理论上，它成为现实世界问题的可能性微乎其微。然而，11月15日臭名昭著的硬叉事件后，BCH SV网络上的一个区块的自我识别几乎接近对节点的操纵。

一般来说，加密操纵符使用工作证明(Proof-Work，PoW)来避免任何女巫攻击。PoW需要挖掘获取代币甚至验证节点的能力。由于挖掘过程中的能量消耗相当大，因此消除了多节点操作的可能性。

路由攻击

区块链网络可以通过分布式节点分散，但是运行一个节点需要因特网服务。路由攻击把我们的注意力引向一个似乎没有人担心的因素，即ISPs在运行节点中的角色。的确，一个节点可以在世界任何地方运行，但没有人会告诉你13SP拥有30%的比特币网络，而3SP为比特币网络路由了60%的交易流量。

如果内部人员决定通过ISP来控制网络，那么他们成功的可能性是很大的。路由攻击是通过拦截两个自治体发出的信号来进行的。这在互联网领域是很常见的事情，而在加密网络上发生同样的事情的日子已经不远了。

直接拒绝服务攻击

直接拒绝服务(DDoS)是停止网络的最简单方法之一。操作非常简单，许多黑客或程序都会发送大量糟糕的网络请求，从而阻塞系统，阻止真正的消息到达服务器。众所周知，这些攻击会使任何网络瘫痪，或使其在一段时间内崩溃。

像比特币这样的主要加密货币网络总是受到DDoS攻击。然而，开发人员团队已经为缩小影响做了足够的安排。除非DDoS攻击成功，否则不会对用户的资金或安全造成任何威胁。

多数派攻击

区块链的安全性直接依赖于您的计算机的能源效率，而且黑客可以很容易地访问计算机。对计算机系统的控制将意味着对哈希幂的控制。这将使攻击者能够比网络的其他部分更快地挖掘阻塞，而后者可以为重复开支敞开大门，这是一种非常复杂但意义重大的攻击形式。

然而，要赢得这样一次多数派的攻击是徒劳的。由于上手的散列能力可以拉低门限硬币。试图攻击像比特币这样的网络将要巨大的代价，因为执行攻击的人可能会使用高级散列幂来挖掘比特币，而不是操纵网络。

臭名昭著的DAO攻击

上面提到的所有攻击要么是假设的，要么太过复杂而无法成功。然而，有一个黑客利用以太网络上的一个小错误来欺骗数百万人。

分布式自治组织(DAO)是通过智能契约在以太网络上建立起来的。新项目允许用户投资于一个新项目，并通过智能合约对其决定进行投票。这个过程很简单，你需要购买DAO代币，然后按照他们的意愿进行投资。如果您想退出项目，您提交DAO代币并获得返回的信息。这个过程被称为“分裂回归”。

恢复过程分两步进行，在这两步中，将适当数量的以太网代币返回给代币持有者，然后取回DAO代币并将其注册到区块链上，以维护DAO资产负债表。匿名黑客看到了这个过程中的弱点，意识到他可以欺骗系统重复第一步，而不需要完成第二部分。这次袭击共造成5 000万美元的损失。

结语

上面提到的大多数攻击都是安全漏洞而不是能力威胁。然而，与结果相比，成本或费用是很高的。这个系统是健壮和安全的;它周围的人构成了主要威胁。

人们常常把对交易所的攻击与对网络的攻击混为一谈。区块链网络目前还算完善，但交易所、钱包和第三方服务提供商构成了真正的威胁。技术是健全的，人们需要更多地了解漏洞并保持警惕。网络钓鱼骗局夺去了你所有的比特币，这不是对比特币网络的威胁，而是对你。