tag:blogger.com,1999:blog-55262902492312743162024-03-08T06:13:52.505-08:00jha-securitySomeshhttp://www.blogger.com/profile/09031833559403573319noreply@blogger.comBlogger8125tag:blogger.com,1999:blog-5526290249231274316.post-73782106914650278422018-04-25T12:21:00.000-07:002018-04-25T12:21:30.476-07:00Web Attacks<div dir="ltr" style="text-align: left;" trbidi="on">
<i>This blog post was contributed by Vaibhav Rastogi.</i><br />
<br />
The web is one of the most common interfaces between an organization and the outside world and so web attacks, or attacks on web applications, are a fairly frequent attack scenario. They have been studied for decades, projects such as <a href="https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project#tab=Main">OWASP Top Ten</a> have been there to create awareness about these attacks, and there are numerous tools, which can be used to detect and mitigate common web application vulnerabilities. Here, we outline some of the common categories of attacks on web applications.<br />
<br />
<h4 style="text-align: left;">
Injection attacks</h4>
<div>
Such attacks happen when untrusted data is incorporated into the server-side application logic without proper sanitization. These attacks can use a variety of vectors: for example, unsanitized input can make its way into a SQL query to result in a so-called SQL injection. Similar attacks can result with injection into noSQL database queries, and into server-side scripts (e.g., a PHP script that evaluates some untrusted input, which then gets executed as code).</div>
<div>
<br /></div>
<div>
These attacks can result in exposure of confidential data or a compromise of data integrity. Ways to prevent these attacks involve proper placement of sanitizers in the server-side logic so as to never let unsanitized, untrusted data reach places where it could execute as part of application logic.</div>
<div>
<br /></div>
<h4 style="text-align: left;">
Cross-Site Scripting (XSS)</h4>
<div>
Cross-site scripting is similar to injection attacks in that the some untrusted input is interpreted as the application logic, but this time the attack happens in the browser rather than the server. Specifically, the attack happens when an attacker injects into the webpage markup data, that is interpreted by the browser as a script (typically, Javascript) and executed.</div>
<div>
<br /></div>
<div>
As an example, consider an attacker inserting a script element (Javascript code enclosed in <span style="font-family: "courier new" , "courier" , monospace;"><script></script> </span><span style="font-family: inherit;">tag) in an input field that requires their name. Upon submission, the data in the field is then stored in a server-side database. An unsuspecting user viewing the names of all people in the database through a web interface then gets the attack script in lieu of the attacker's name. This attack script is then executed by the browser.</span></div>
<div>
<br /></div>
<div>
Cross-site scripting can again lead to compromise of confidentiality and integrity. The primary way of preventing cross-site scripting to insert sanitizers that modify the inputs in ways such that the browser does not interpret them as executable code. Another line of defense comes from the so called content security policies in web browsers. These policies specify where content (including executable content) can come from (e.g., from specific domains or specially marked-up elements). The browser then ignores any content that has not been white-listed in this manner. We will discuss CSP in greater detail in a future blog post.</div>
<div>
<br /></div>
<h4 style="text-align: left;">
Authorization and Authentication Flaws</h4>
<div>
This category represents several scenarios. For example, an object may be publicly accessible though a URL while it should have been accessible only to authenticated users, who have the right privileges. Another example could be bypassing highjacking an authenticated session by merely using the URL of the authenticated session. To elaborate, suppose a session is authenticated through a session ID, which is present in the URL. An attacker could entice a victim to send them an authenticated session URL and use the session ID-containing URL to get the victim's session. Failure to enforce strong passwords or the use of insecure authentication practices, e.g., authenticating a user based on secret question/answers in lieu of passwords are also authentication flaws.</div>
<div>
<br /></div>
<h4 style="text-align: left;">
Man-in-the-middle Attacks</h4>
<div>
With the client-server communication happening over an unencrypted channel, the data is open to sniffing and spoofing attacks while in transit. This can most easily be fixed with by using HTTP over TLS or HTTPS. HTTPS encrypts the communication channel and provides authentication of the server (i.e., the connected example.com is indeed example.com) and integrity and confidentiality of the data. TLS configuration errors can sometimes result in weakened security. It is therefore important to choose a strong default configuration for your web server.</div>
<div>
<br /></div>
<h4 style="text-align: left;">
Cross-Site Request Forgery (CSRF)</h4>
<div>
In this, the attacker exploits the browser to send a request to the server on victim's behalf. The victim is typically logged-in into the website and so the request is processed in an authenticated context. For example, consider a user logged into their bank website and in a separate browser tab clicking on an attack link that directs the bank website to transfer money from the victim's account to the attacker's account. The main issue here is that the server has no way to tell if the victim created this request or the attacker did it from the victim's browser.</div>
<div>
<br /></div>
<div>
Common ways of dealing with CSRF attacks include the server sending a nonce (a random, unpredictable token) to the client, which is then embedded in every legitimate request to the server. Any attacker-created request will not have the nonce and hence can be rejected by the server.</div>
<div>
<br /></div>
<div>
The above is only a very short summary of the attacks. There are many details we have skipped, including variations on these attacks, and how to prevent them effectively. We will cover some of these attacks in detail in future posts.</div>
</div>
Anonymoushttp://www.blogger.com/profile/15184210938184129219noreply@blogger.com0tag:blogger.com,1999:blog-5526290249231274316.post-11682414394222496652018-04-20T09:21:00.000-07:002018-04-20T09:21:26.550-07:00Semantic Adversarial Machine Learning (SAML)<div dir="ltr" style="text-align: left;" trbidi="on">
<span style="color: red;"><i></i></span><br />
<a name='more'></a><span style="color: red;"><i>ML is everywhere: </i></span>Fueled by massive amounts of data, models produced by machine-learning (ML)
algorithms, especially deep neural networks, are being used in diverse domains
where trustworthiness is a concern, including automotive systems, finance,
health care, natural language processing, and malware detection. Of particular
concern is the use of ML algorithms in cyberphysical systems (CPS), such as
self-driving cars and aviation, where an adversary can cause serious
consequences.<br />
<br />
<span style="color: blue;">Adversarial ML (AML)</span> deals with generating adversarial examples to ML<br />
algorithms (e.g modifying a stop sign slightly so that it is classified as a<br />
yield sign). For a general description of AML see <a href="https://blog.openai.com/adversarial-example-research/">here</a> <br />
<br />
<span style="color: red;"><i>Semantic Adversarial Machine Learning:</i></span> However, existing approaches to generating adversarial examples
and devising robust ML algorithms mostly ignore the semantics and context of
the overall system containing the ML component. For example, in an autonomous
vehicle using deep learning for perception, not every adversarial example for
the neural network might lead to a harmful consequence. Moreover, one may want
to prioritize the search for adversarial examples towards those that
significantly modify the desired semantics of the overall system. Along the
same lines, existing algorithms for constructing robust ML algorithms ignore
the specification of the overall<br />
system.<br />
<br />
In my recent paper with co-authors (Tommaso Dreossi and Sanjit Seshia from<br />
Berkeley) we argue that the
semantics and specification of the overall system has a crucial role to play in
this line of research. We present preliminary research results that support
this claim.<br />
<br />
Interested in reading? See <a class="" href="https://arxiv.org/abs/1804.07045">https://arxiv.org/abs/1804.07045</a><br />
<br />
Note: Have feedback. I would love to hear it. Please email at jha@cs.wisc.edu </div>
Someshhttp://www.blogger.com/profile/09031833559403573319noreply@blogger.com0tag:blogger.com,1999:blog-5526290249231274316.post-43464516081522731622008-06-06T07:49:00.000-07:002008-06-06T11:31:56.405-07:00Malware Trend in 2007<pre style="font-family: times new roman;" wrap=""><span style="font-size:130%;">I read the report IBM Internet Security System X-Force 2007 Trend<br />Statistics. This is a report describing trends for various threats in 2007.<br />This team has been tracking trends since 2000. I found the report<br />to be quite interesting. In the rest of this post, I highlight some<br />of the interesting points from the report and what they mean in the<br />context of malware detection.<br /><br />(I) The X-Force team reports continued growth in Web browser exploitation. This<br />clearly shows that the infection vector is changing to the Web. Earlier<br />the primary infection vectors were email and the network. Therefore,<br />for detecting malware, drive-by-downloads (DBD) and other threats targeted at hacking through the Web browser need a lot of attention.<br /><br />(II) X-Force also reports a marked increase in obfuscated exploits, i.e.,<br />exploits that use various code obfuscation techiques (such as encryption).<br />Here is a quote, "X-Force estimated that nearly 80 percent of Web exploits<br />used obfuscation and/or self decryption ... By the end of 2007, X-Force<br />believed this rate had reached 100 percent, ...". This means that going<br />forward, Web exploits will increasingly harbor indiscernible code rending signature-based techniques less effective. Advanced<br />techniques (such as behavior-based detection) are clearly needed to detect<br />such malware. To exacerbate the situation the X-Force report stated that<br />there was a 30% increase in new malware samples in 2007 over 2006. This<br />further drives home the point that signature-based detectors will have trouble<br />in keeping up with the number of malware as they cannot detect new threats.<br /><br />(III) There was another very interesting point made by the report. Modern<br />malware use features from various types of classic malware (such as viruses, worms,<br />and spyware) by pulling the successful features of each into new strains. To quote the report, "Modern malware is now the digital equivalent<br />of the Swiss Army knife, and 2007 data continues to support this." This trend<br />also indicates that the behavior of malware is becoming more sophisticated, which<br />again supports my claim that detection techniques based on analyzing behavior are<br />better suited to handle malware of the future. Another interesting tidbit from the<br />report: "Trojans make up the largest class of malware in 2007 as opposed to downloaders,<br />which were the largest category in 2006." Recall that a Trojan appears to be a<br />legitimate file with some hidden functionality (for example, that of a rootkit).<br />Trojans are historically a problematic class of malware for signature-based<br />detection.<br /><br />Overall, I found the report to be very interesting. Read it for yourself.<br />You can find the report <a href="http://www.iss.net/x-force_report_images/2008/index.html">here</a>.</span></pre>Someshhttp://www.blogger.com/profile/09031833559403573319noreply@blogger.com2tag:blogger.com,1999:blog-5526290249231274316.post-19156931526861845562008-04-23T15:09:00.000-07:002008-04-23T15:11:25.631-07:00Zero Day Threat by Acohido and SwartzI read the book <span style="font-style: italic;">Zero Day Threat (ZDT)</span> by <span style="font-weight: bold;">Byron Acohido and Jon Swartz.</span> I really liked the book! Zero Day Threat is about the underground cyber-economy. It makes some surprising points grounded in real truths. I liked that the book paints a complete picture, i.e., how malware,<br />identity theft, and "drop off" gangs collaborate to facilitate<br />a well oiled cyber-economy. Since my research area is security,<br />I was very familiar with the different types of malware brought up in Zero Day Threat. However, this book gave me a complete picture of the problem.<br /><br />I particularly appreciated two features of the book:<br /><br /><span style="font-style: italic;">Structure: </span>Each chapter is broken into three sections: exploiters,<br />enablers, and expeditors. Exploiter sections focus on crooks (such<br />as scam artists and drug addicts) and how they benefit from the<br />underground economy. The Enablers sections focus on credit card<br />companies, banks, and credit bureaus, and how their current practices<br />enable the underground cyber-economy. Expediters<br />are guys (good and bad) that allow the cybercrooks to exploit<br />vulnerabilities in an expeditious manner. I thought this structure<br />was just brilliant! It really brings out the correlation between<br />various factors and actors that enable the underground cyber-economy.<br /><br /><span style="font-style: italic;">Narrative Style:</span> I really enjoyed various anecdotes in the book.<br />There are several stories about people being scammed or getting<br />lured into the profitable cyber-underground. For example, there is a story of<br />a "drop off" gang in Edmonton which is narrated throughout the<br />book. These anecdotes make the book very interesting and provide<br />a "human side" to the cyber-underground.<br /><br />I highly recommend this book.Someshhttp://www.blogger.com/profile/09031833559403573319noreply@blogger.com0tag:blogger.com,1999:blog-5526290249231274316.post-31688206218331812352008-03-19T10:54:00.000-07:002008-03-19T11:06:14.052-07:00Botnets in USA TodayI got a call from Byron Acohido over at the USA Today last weekend, <br />and we had an interesting talk about botnets. Byron and Jon Swartz ended <br />up writing an article about botnets which appeared as the cover story<br />in the Money section of the USA Today on March 17, 2008. Here's a link to the full <br />story (<a href="http://www.usatoday.com/money/industries/technology/2008-03-16-computer-botnets_N.htm">link</a>). I found the entire article to be a fascinating read<br />on the nature of botnets. Here are some of the highlights, but<br />definitely go and read the entire article.<br /><ul><li>On a typical day, 40% of the 800 million computers connected to the Internet are bots engaged in various nefarious activities, such as spamming, stealing sensitive data, and engaging in denial-of-service attacks. Think about it. Approximately 320 million computers are engaged these illicit actiivities!</li><li>Later on in the article they describe various features of <span style="font-style: italic;">Storm</span>, the state-of-the-art for botnets. Storm introduced various innovations into the bot landscape, such as using P2P style communication to converse with the bots and encrypting the <span style="font-style: italic;">command-and-control (C&C) </span>traffic. Command-and-control is the traffic from the bot-herder to the bots instructing them to perform various nefarious activities. Note that this means that various network-based botnet solutions that simply look for centralized C&C communication will not work. Moreover, encrypted traffic is a major problem for the network-based solutions. See my earlier blog where I argue that we should move to a cooperative solution. This is looking like a very good idea. Storm also has a self-defense mechanism, i.e., anyone trying to probe the botnet is punished with a denial-of-service attack. I found this self-defense mechanism of Storm to be very interesting.</li></ul>Overall a fascinating article!<br />I plan to drop by Byron's book signing at the <a href="http://www.rsaconference.com/">RSA Conference</a> in San <br />Francisco on April 7th. Byron also has an interesting <a href="http://zerodaythreat.com/">blog</a> which is related to the<br />material in the book.Someshhttp://www.blogger.com/profile/09031833559403573319noreply@blogger.com0tag:blogger.com,1999:blog-5526290249231274316.post-90074630597316042062008-03-05T12:23:00.000-08:002008-03-05T12:35:32.783-08:00Model Checking and SecurityModel checking is a technique of verifying temporal properties of finite-state systems. One of<br />the attractive features of model checking over other techniques (such as theorem proving)<br />is that if a property is not true, a model checker provides a counter-example which<br />explains why the property is not true. Inventors of model checking, Edmund Clarke,<br />Allen Emerson, and Joseph Sifakis, won the 2008 ACM Turing award (see the announcement <a href="http://www.acm.org/press-room/news-releases/turing-award-07/">here</a>). I have a personal connection to two of the recipients. Edmund Clarke was my adviser<br />at Carnegie Mellon, and Allen Emerson and I have collaborated on few projects and he<br />has supported me through out my career.<br /><br />In this note I try to summarize various applications of model checking to security.<br /><br /><span style="font-style: italic;">Protocol verification</span>: Protocols in the realm of security (henceforth referred to<br />as security protocols) are very tricky to get correct. For<br />example, flaws in authentication protocols have been discovered several years after they have been published. Techniques based on model checking have been extensively used to verify these protocols. The tricky part in applying these techniques for verifying security protocols is<br />modeling the capabilities of the attacker. Gavin Lowe used the FDR model checker to find<br />a subtle attack on the Needham-Schroeder authentication protocol (this<br />publication can found <a href="http://web.comlab.ox.ac.uk/oucl/work/gavin.lowe/Publications.html">here</a>). Following Lowe's work there<br />was a flurry of activity on this topic. Interested readers can look at the proceedings of<br />the Computer Security Foundations Symposium (<a href="http://www.cylab.cmu.edu/CSF2008/">CSF</a>).<br /><br /><span style="font-style: italic;">Vulnerability assessment</span>: Imagine you are given an enterprise network with various components (firewalls, routers, and Intrusion Prevention Systems (IPSs)).<br />Vulnerability assessment tries to ascertain how an attacker can penetrate the specified network. Vulnerability assesment is crucial in updating policies of various security appliances (such as firewalls and IPSs) and ascertaining the risk of various decisions. Traditionally, vulnerability assessment has been performed by red teams. Red teaming is a very valuable activity but can provide no guarantees that the entire state space of vulnerabilities has been explored. I along with (Oleg Sheyner and Jeannette Wing) explored techniques based on model checking for vulnerability assessment. We formally specify the network and express the negation of the attackers goal (e.g., attacker gets root access on a critical server) as a property to be verified. If<br />the specified network is vulnerable, then the model checker will output a counter-example (which is an attack on the network). The innovation we devised was to output the set of all<br />counter-examples or attacks as an attack graph, which is succinct representation of all attacks on the network. Analysis of the attack graph can provide a basis for vulnerability assessment. This paper can be downloaded <a href="http://pages.cs.wisc.edu/%7Ejha/jha-papers/security/oakland_2001.html">here</a>.<br /><br /><span style="font-style: italic;">Other applications:</span> There are several problems in security that can be addressed using model checking. For example, I and <a href="http://pages.cs.wisc.edu/%7Ereps/">Tom Reps</a> have used model checking properties to analyze properties of security policies in trust-management systems. <a href="http://www.cs.purdue.edu/homes/ninghui/">Ninghui Li</a> and his collaborators have used techniques based on model checking to analyze several classes of security properties.<br />In the context of security, the advantage model checking has over other techniques (such as<br />testing) is that it exhaustively covers the state-space. After all, if you just have one<br />vulnerability, an attacker will exploit that vulnerability, i.e., an attacker just needs one<br />door to get through your system. Thus the completeness guarantee that a model checker provides is very valuable in the context of security.Someshhttp://www.blogger.com/profile/09031833559403573319noreply@blogger.com2tag:blogger.com,1999:blog-5526290249231274316.post-13731703706035132062008-02-13T13:23:00.000-08:002008-02-13T13:36:39.880-08:00Cooperating DetectorsA malware detector tries to determine whether a program is malicious (examples<br />of malicious programs are drive-by-downloads, botnets, and keyloggers).<br />Malware detection is primarily performed at two vantage points: host and<br />network. This post explains why cooperation between host-based and network-<br />based detectors is a good thing.<br /><br />Traditionally, detection has been performed either at the network or host level, but<br />not both. First, let me examine both approaches separately.<br /><br />A network-based detector monitors events by examining a session or<br />network flow and tries to determine whether it is malicious. The<br />advantage of a network-based detector is ease of deployment -- there<br />are not that many points of deployment for a network-based detector<br />(typically they are deployed behind border routers).<br /><br />Unfortunately, network-based detectors have a limited view of each<br />network session. In fact, if a session happens to be<br />encrypted such as is common with VPNs, Skype, and some bots, a<br />network-based detector is essentially blind. For example, a botmaster<br />can hide its communication with the bots by simply encrypting the session.<br /><br />By contrast, host-based detectors have a more comprehensive view of system activities, i.e.,<br />they have the potential to observe every event at the host, including malicious ones. However, the major drawback of a host-based detector is that it has to be widely deployed. Typically in a managed<br />network (such as in an enterprise), a host-based detector has to be deployed at<br />every host.<br /><br /><br />Cooperation between host-based and network-based detectors can potentially<br />address the shortcomings of each detector. I've come up with three possible scenarios.<br /><br />1) <span style="font-style: italic;">Host-based detector helping the network-based detector</span>.<br />A network-based detector can pull alerts from a host-based<br />detector and a host-based detector can push alerts to a network-based<br />detector. This is a simple solution and I suspect the easiest<br />scenario for cooperation.<br /><br />2) <span style="font-style: italic;">Queue up suspicious activity on a virtual machine.</span><br />If a network-based detector determines that a session is<br />"suspicious," it can divert the suspicious traffic to a virtual machine<br />with a host-based detector for more in-depth analysis. The trick here<br />is figuring out what events are indeed "suspicious" (you do not want<br />too much traffic to go through the "slow path" corresponding to a<br />host-based detector). There is already a<br />startup called <a href="http://www.fireeye.com">Fireeye</a> adapting this solution. I find this line of work quite intriguing.<br /><br />3) <span style="font-style: italic;">Pushing signatures.</span><br />This third scenario has been explored quite thoroughly in academic<br />literature. It involves the cooperation of host-based and network-based detectors to<br />push signatures for malware in real-time. For example, if a host-<br />based detector recognizes an attack, it pushes out a signature to a<br />network-based detector. The advantage of this<br />approach is that, by updating a network-based detector, an entire<br />enterprise can be protected against that particular threat. However, in my<br />view this is not a good approach in the long run. Hackers are creating malware variants at<br />an alarming rate and signatures won't be able to keep up.Someshhttp://www.blogger.com/profile/09031833559403573319noreply@blogger.com0tag:blogger.com,1999:blog-5526290249231274316.post-57824942027007268762008-01-30T13:28:00.000-08:002008-02-04T09:34:21.865-08:00Case for kernel-level detection<span style="font-style: italic;">Why kernel-level detection?</span><br />These are my thoughts on why malware detection should performed at the<br />kernel level. In general, the lower in the system hierarchy your<br />detector resides, the harder it is for an attacker to evade your detector.<br />For example, if a detector uses system-call interposition, an attacker can<br />evade this system by directly using kernel calls. For example,<br />system-call interposition can be done on Windows using the following<br /><a href="http://research.microsoft.com/sn/detours/">package</a>. In my conversations with<br />a guy from NSA (name withheld for obvious reasons:-)) he confirmed that<br />new malware they are observing in their lab are using kernel calls directly.<br />Also, look at the following <a href="http://activehome.co.uk/vnunet/news/2184047/low-level-malware-rise-say">article</a><br /><br /><br /><span style="font-style: italic;">The semantic-gap problem:</span><br />A natural question that comes to mind is: why not perform detection at even a lower layer<br />in the heirarchy? Say the VM layer or even better at hardware. As you move<br />down in the system hierarchy, you lose some high-level semantics. Let me explain.<br />Lets say you are doing detection at the VM layer. A high-level event (such as<br />opening a file) manifests itself as a sequence of events (such as writing to<br />memory page or an interrupt). In other words, there is a gap between<br />the events you observe at the VM level and the corresponding high-level event. To my knowledge<br />the "semantic gap" issue was first articulated in the following paper:<br /><br /> Peter M. Chen, Brian D. Noble, "When virtual is better than real",<br /> Proceedings of the 2001 Workshop on Hot Topics in Operating Systems (HotOS),<br /> May 2001.<br /> The paper can be downloaded at the following <a href="http://www.eecs.umich.edu/%7Epmchen/papers/">site</a>.<br /><br />As you move down in the hierarchy, the semantic gap problem becomes harder. The<br />semantic gap problem still exists at the kernel level, but it is more tractable<br />than at the other layers. Therefore, I think kernel-level detection hits<br />the "sweet spot". Implementing detectors at kernel level is harder than other<br />approaches (such as system-call interposition), but then everything good in life takes<br />effort:-) I strongly believe that detectors that use system-call interposition are very<br />easy to evade, and so what is the point in having them. The next generation of malware<br />will definitely use kernel calls directly.Someshhttp://www.blogger.com/profile/09031833559403573319noreply@blogger.com1