Security Ripcord

I stopped reading Jeremiah Grossman‘s blog post Indirect Hard Losses to write this poll.  I am happy to see that people are showing their opinions to breaches through their wallets or the services they accept.  But should the customers be more forth coming?  Should companies have to mark on their web pages (all web pages that they provide to the public) that data in their possession was compromised?

This is a tricky situation.  In many states, persons who have abused children are required to disclose themselves to persons in their neighborhood.  We are also all aware of state or county run websites that display the name, offense, picture, and the last recorded address for these people.  Now, you might be thinking to yourself that this is a completely different situation and risk.  While I do admit that the situation is different I have to say that the level of risk could be considered similar.  If a victim of identity theft can go to jail because nobody will believe his story, I think the risks can be pretty high.  Also, although the risk of a sex offender is higher in cost to a community, company websites have the potential to affect a very large portion of the United States and even the international community.

Another argument against this is that the business is the victim of a crime and not the perpetrator.  I do admit that I understand and sympathize with this argument.  One way around this is to allow the business to provide information about the new protections that they have implemented to increase the security around the data they maintain (insert “mandatory information disclosure” argument here) and to provide a hot line to their support department.

So, without further ado, here is the poll.

Go forth and do good things,

Don C. Weber

While reviewing some Apache log files the other day I started to wonder if somebody had already come up with a way to detect common attack characteristics by the information they contain.  Although searching for entries containing “SELECT,” “xp_cmdshell,” and other attack terms can turn up useful information it is difficult to cover all of the attack types and the different ways they can be represented within the log entries.  Some Googling brought me to a project started by Romain Gaucher called apache-scalp which is hosted on Google Code.

Scalp! is a log analyzer for the Apache web server that aims to look for security problems. The main idea is to look through huge log files and extract the possible attacks that have been sent through HTTP/GET (By default, Apache does not log the HTTP/POST variable).

This tool uses an event filter file created by and for the PHPIDS project.  PHPIDS was created parse web traffic and alert on anomalous activity as it occurs instead of having to parse the log files.  To help in those instances that PHPIDS is not deployed, Scalp applies the same principle to the collected information.  Utilizing the PHPIDS signature file, default_filter.xml, Scalp will generate an alert file in the user’s choice of text, HTML, and XML formats.  This output, however, is alert data only and can be very cumbersome to review.  When a lot of information is involved human review is not a very effective way to determine trends and other specifics about the data.

<?xml version=”1.0″ encoding=”utf-8″?>
<!–
File created by Scalp! by Romain Gaucher – http://code.google.com/p/apache-scalp
Apache log attack analysis tool based on PHP-IDS filters
–>
<scalp file=”apache_log” time=”Sat-27-Dec-2008″>
<attack type=”xss” name=”Cross-Site Scripting”>
<impact value=”5″>
<item>
<reason><![CDATA[Detects JavaScript with(), ternary operators and XML predicate attacks]]></reason>
<regexp><![CDATA[(?:with\([^)]*\)\))|(?:\.\s*source\W)|(?:\?[^:]+:[^;]+;)]]></regexp>
<line><![CDATA[xxx.28.xxx.249 - - [26/Aug/2008:00:00:13 -0700] “GET /d.AuthenticateUser1?p_page=http://webx.companyX.com/publish/01/na/en.html&p_HTTP_USER_AGENT=Microsoft%20Internet%20Explorer-4.0%20(compatible;%20MSIE%206.0;%20Windows%20NT%205.1;%20SV1;%20.NET%20CLR%201.1.4322) HTTP/1.0″ 200 1547
]]></line>
</item>
<item>
<reason><![CDATA[Detects JavaScript with(), ternary operators and XML predicate attacks]]></reason>
<regexp><![CDATA[(?:with\([^)]*\)\))|(?:\.\s*source\W)|(?:\?[^:]+:[^;]+;)]]></regexp>
<line><![CDATA[xxx.16.xxx.158 - - [26/Aug/2008:00:00:19 -0700] “GET /d.AuthenticateUser1?p_page=http://webx.companyX.com/publish/01/na/en.html&p_HTTP_USER_AGENT=Microsoft%20Internet%20Explorer-4.0%20(compatible;%20MSIE%206.0;%20Windows%20NT%205.1;%20SV1;%20.NET%20CLR%201.1.4322) HTTP/1.1″ 200 1570
]]></line>
</item>
<item>
<reason><![CDATA[Detects JavaScript with(), ternary operators and XML predicate attacks]]></reason>
<regexp><![CDATA[(?:with\([^)]*\)\))|(?:\.\s*source\W)|(?:\?[^:]+:[^;]+;)]]></regexp>
<line><![CDATA[xxx.84.xxx.90 - - [26/Aug/2008:00:00:41 -0700] “GET /d.AuthenticateUser1?p_page=http://webx.companyX.com/publish/01/vie/en.html&p_HTTP_USER_AGENT=Microsoft%20Internet%20Explorer-4.0%20(compatible;%20MSIE%206.0;%20Windows%20NT%205.1;%20SV1;%20.NET%20CLR%201.1.4322) HTTP/1.1″ 200 1568
]]></line>
</item>
<item>
<reason><![CDATA[Detects JavaScript with(), ternary operators and XML predicate attacks]]></reason>
<regexp><![CDATA[(?:with\([^)]*\)\))|(?:\.\s*source\W)|(?:\?[^:]+:[^;]+;)]]></regexp>
<line><![CDATA[xxx.160.xxx.243 - - [26/Aug/2008:00:00:57 -0700] “GET /d.AuthenticateUser1?p_page=http://webx.companyX.com/publish/01/par/en.html&p_HTTP_USER_AGENT=Microsoft%20Internet%20Explorer-4.0%20(compatible;%20MSIE%206.0;%20Windows%20NT%205.1;%20SV1;%20.NET%20CLR%201.1.4322) HTTP/1.1″ 200 1573

To help identify trends and other interesting information associated with alerts generated by Scalp I have put together a external parser to generate a readable report.  The Scalp External XML Reporter (SEXR) takes the information within a Scalp XML file and produces several outputs to either standard out or a text file.

The first output is the full parse of the generated alerts.  Although this output can still contain a lot of information, it is much easier to read and understand than the original Scalp output.  (The following output, as well as the rest in this post, have been snipped for brevity and their format slightly altered getting the text into this post.)

sexr.py: Conducting full scan of 1 files
scalp: {‘file’: ‘apache_log’, ‘time’: ‘Sat-27-Dec-2008′}
attack: {‘type’: ‘xss’, ‘name’: ‘Cross-Site Scripting’}
impact: {‘value’: ’5′}
item
reason
- Detects JavaScript with(), ternary operators and XML predicate attacks
regexp
- (?:with\([^)]*\)\))|(?:\.\s*source\W)|(?:\?[^:]+:[^;]+;)
line
- xxx.28.xxx.249 – - [26/Aug/2008:00:00:13 -0700] “GET /d.AuthenticateUser1?p_page=http://webx.companyX.com                    /publish/01/na/en.html&p_HTTP_USER_AGENT=Microsoft%20Internet%20Explorer-                        4.0%20(compatible;%20MSIE%206.0;%20Windows%20NT%205.1;%20SV1;%20.NET%20CLR%201.1.4322) HTTP/1.0″ 200 1547

item
reason
- Detects JavaScript with(), ternary operators and XML predicate attacks
regexp
- (?:with\([^)]*\)\))|(?:\.\s*source\W)|(?:\?[^:]+:[^;]+;)
line
- xxx.16.xxx.158 – - [26/Aug/2008:00:00:19 -0700] “GET /d.AuthenticateUser1?p_page=http://webx.companyX.com/publish/01/na/en.html&p_HTTP_USER_AGENT=Microsoft%20Internet%20Explorer-4.0%20(compatible;%20MSIE%206.0;%20Windows%20NT%205.1;%20SV1;%20.NET%20CLR%201.1.4322) HTTP/1.1″ 200 1570

item
reason
- Detects JavaScript with(), ternary operators and XML predicate attacks
regexp
- (?:with\([^)]*\)\))|(?:\.\s*source\W)|(?:\?[^:]+:[^;]+;)
line
- xxx.84.xxx.90 – - [26/Aug/2008:00:00:41 -0700] “GET /d.AuthenticateUser1?p_page=http://webx.companyX.com/publish/01/vie/en.html&p_HTTP_USER_AGENT=Microsoft%20Internet%20Explorer-4.0%20(compatible;%20MSIE%206.0;%20Windows%20NT%205.1;%20SV1;%20.NET%20CLR%201.1.4322) HTTP/1.1″ 200 1568

Although helpful and informative it might be a little more helpful to know more specific information about the alerts.  SEXR’s count scan option is designed to remove some of the more extraneous information by providing the number of alerts detected and the names of the alerts with which they are associated.

sexr.py: Conducting count scan of 1 files
scalp: {‘file’: ‘apache_log’, ‘time’: ‘Sat-27-Dec-2008′}
attack: {‘type’: ‘xss’, ‘name’: ‘Cross-Site Scripting’}
Impact 5 Items: 299
- ‘Detects JavaScript with(), ternary operators and XML predicate attacks’: 248
- ‘Detects self-executing JavaScript functions’: 51
Impact 4 Items: 655
- ‘Detects common XSS concatenation patterns 1/2′: 655
Impact 3 Items: 80
- ‘Detects common comment types’: 80
attack: {‘type’: ‘lfi’, ‘name’: ‘Local File Inclusion’}
Impact 5 Items: 199
- ‘Detects specific directory and path traversal’: 199
attack: {‘type’: ‘rfe’, ‘name’: ‘Remote File Execution’}
Impact 5 Items: 383
-’Detects url injections and RFE attempts’: 383
sexr.py: Done

After determining the types of attacks that were detected from the Apache log files it might be interesting to know where these attacks originated.  SEXR’s source IP scan option provides the source IP address for all of the alerts detected and a count of how many times these source IP addresses were associated with the attack.

sexr.py: Conducting IP scan of 1 files
scalp: {‘file’: ‘apache_log’, ‘time’: ‘Sat-27-Dec-2008′}
attack: {‘type’: ‘xss’, ‘name’: ‘Cross-Site Scripting’}
Impact 5 Items: 299
- Total Source IP Addresses: 209
- xxx.176.xxx.42: 1
- xxx.177.xxx.68: 1
- xxx.129.xxx.3: 1
- xxx.89.xxx.250: 1
- xxx.179.xxx.235: 1
- xxx.253.xxx.222: 3

Although Scalp does all of the heavy lifting I believe that SEXR can play an important role in evaluating the results that Scalp produces.  I hope that SEXR will help make the information provided by Scalp more usable for system, network, application administrators and security professionals.  To this end Romain has allowed me to update a few portions of Scalp to make its XML output more informative while also adding SEXR and the Scalp DTD file to the source code available online with the Scalp project.

If you have any comments, recommendations, or updates for the code, please let me know.

Go forth and do good things,

Don C. Weber

Jeremiah Grossman has a simple but sweet post about what to do on your first day of work when you come on board to a company that has no “no existing web/software security program.” He simply asked, “What is the very first thing do on day 1? [sic]”

The meat of the post is in the comments. Although it started out with some typical guidance on how to technically identify server, applications, vulnerabilities, and the like, the comments quickly transition into focus on the people of the organization. Getting to know the executives, management peers, security and technical administrators, and even support personnel before diving in and trying to find problems and giving orders about how to fix them.

Security Professionals need to remember that there are other people out there. It has often been said that we need to refrain from saying “No,” “Don’t,” “Can’t,” and other negatively connotative words unless absolutely necessary. We often remind ourselves that we are a part of the business unit and that we are, typically, support personnel rather than the front line administrators (and if you are both then your security tasks should take the support model into consideration). So when it all boils down, we are saying that we have to be a helpful and viable part of the business by working with the other employees, no matter the level, rather than being the lonesome cowboy with six-guns drawn. Once we have accomplished this then we can start delving into identify critical physical assets, location of data, mission critical application, and other important technically-related security information. Hopefully, your initial dealings with fellow employees and managers will have already greased the skids to start working with this information, but it will have also provided you with a better understanding of the politics and business necessities surrounding the current state of technical deployment.

I’m not going to repeat my or anybody else’s comments here. Go check out Jeremiah’s post and then put in your two cents. But while you are there, notice some of the names of people who are commenting on getting to know the people and organization first before diving into the technical aspect of the position. You will probably notice many people that you know and respect.

Go forth and do good things,

Don C. Weber

I’m willing to bet a few people I know are going to have opinions about this.

I was Googling something today when I was directed to Wikipedia. As I was reading I noticed the following link for “Portal: Computer Security”.

When I clicked on it I was redirected to a very interesting page full of security links and information. So, I started reviewing what they have included when I got to the “Selected biography” section. Well, the title of the post speaks for itself. Now, the image is a bit large and part of it is hidden. Just click on it and you’ll see the whole thing. Oh, and please feel free to comment

Go forth and do good things,

Don C. Weber

Companies are always changing their user agreements and public statements. After reading Jeremiah Grossman’s post on PayPal disclosure statement I got a creepy feeling about actually trusting the statement. I will probably never attempt to test the security of PayPal’s site, but for those who do I would hate for the disclosure statement to change suddenly. So, I have copied the statement, pasted it into a file, and determined the SHA-256 and SHA-512 values. I’m not sure if it is even useful, hopefully nobody ever needs it, but here it is just in case.

[user@localhost Development]$ cat paypal.txt
Reporting site security issues

Our team of dedicated security professionals works vigilantly to keep customer information secure. We recognize the important role that security researchers and our user community play in keeping PayPal and our customers secure. If you discover a site or product vulnerability please notify us using the guidelines below.

To encourage responsible disclosure, we commit that – if we conclude that a disclosure respects and meets all the guidelines outlined below – we will not bring a private action or refer a matter for public inquiry.

Guidelines for responsible disclosure

* Share the security issue with us before making it public on message boards, mailing lists, and other forums.
* Allow us reasonable time to respond to the issue before disclosing it publicly.
* Provide full details of the security issue.

Do not engage in security research that involves

* Potential or actual denial of service of PayPal applications and systems.
* Use of an exploit to view data without authorization, or corruption of data.
* Requests for direct compensation for the reporting of security issues either to PayPal, or through any external marketplace for vulnerabilities, whether black-market or otherwise.

Report security vulnerabilities to sitesecurity@paypal.com.
Our PGP key for reporting can be found here.

Forward spoof and phishing emails to spoof@paypal.com.
[user@localhost Development]$ sha256sum paypal.txt
c42f72aea29f3e558d835b6c5df943498429c3c4a2c81b531e462cea01e48716 paypal.txt
[user@localhost Development]$ sha512sum paypal.txt
b545c30ac6c1531160f19b9c9de0118f80f48fe7ebd0096a6f161ed4ed136d31e528e938b79b19db8a89edb90a8d45018e0d4d8c77b9f61994eada66440f05f8 paypal.txt
[user@localhost Development]$

Go forth and do good things,
Don C. Weber

Paypal, disclosure, assessment, web, Security Ripcord, Jeremiah Grossman

Okay, so the title is a little bit of a misnomer.  I have not found any security websites using web bugs.  Where this stems from is my own pondering.  At my 8 to 5 organization I have been wondering how I should track the usage of the security based website I manage.  This makes good sense because I want to see if I am reaching my audience. 

As I am not the administrator of the resource I do not have the proper privileges to view the logs associated with the web server.  Actually, I do not want those privileges unless necessary for auditing or incident response purposes.  I also do not want to burden the system administrator any more than necessary.  So, rather than ask for the output of the log associated with my virtual host I have started thinking about methods that I can track hits using some type of PHP counter.

While I was investigating how to accomplish this I received a few emails so I took a look.  I had received a couple mundane messages and an email from a vendor.  Once I opened the vendor email I noticed the usual vendor email format which, unfortunately, is strewn with plaintext HTML links.  The very first link was a web bug.  It said so right on the image “title=”Web Bug…”.  So, I started thinking to myself,  “Hmmm, web bug.”  Would that work?  I could include it in every web page.  I could include it in all of the documents and presentations I provide on the site.  This will tell me how often stuff is getting viewed and whether they are coming from the intranet or the Internet.  Exactly the information I could get from the web log.  But for some reason the idea of including a web bug on the site and in the documents made my skin crawl.  So I decided to do a little asking around in the Security Catalyst Community.  I started a thread titled “Web Bugs on Internal Security Sites“.

My call was answered by several people including Rebecca Herold.  She provided me with some good insight but even better documentation.  First she pointed me to a paper by the National Advertising Initiative.

Also, the The National Advertising Initiative (NAI) created a set of standards that cover the use of web bugs (also called web beacons, web gifs, and several more a.k.a.’s) on Internet sites.  You may find their standards interesting and perhaps helpful to your consideration of using them within your network: http://www.networkadvertising.org/networks/Web_Beacons_rev_11-1-04.pdf

Next she posted a white paper that she wrote about web bugs back in April 2005 titled “Quit Buggin Me!”  I have read it already and I highly recommend it if you are interested in web bugs.  Although I usually link directly to a document I would rather force you to her site so you can be aware of her other papers and books.  The paper can be found at her “Articles Regarding Technology Aspects of Privacy” page.

By this time I was completely squared away by Ms. Herold.  Although not necessarily bad, web bugs are not necessarily good.  In fact, they have to be used properly or you may face issues with your users, your organization, or even your government.  In this case my government would be the State of Texas.  So, to continue my research I did a little Googling.  And, of course, I got a hit that directed me to the Texas Department of Information Resources.   It was very quickly apparent that the State of Texas has a policy on how to use persistent cookies and Web Bugs.  In fact, the guidance set by the Texas Department of Information Resources states:

In order for visitors to make informed decisions about the privacy practices of state agencies, the visitor should be able to access the home page and Privacy and Security Policy page without the site setting a cookie or using a web bug to track visitor [sic].

Delving in a little deeper I noticed that there is specific guidance for Institutions of Higher Education.  Particularly Texas Administrative Code Rule 206.73 Privacy and Security of State Web Sites.  

(a) Each institution of higher education shall publish a privacy and security policy for its Web site, and post a link to the policy from its home page, or Site Policies page. The privacy and security policy shall address the following:
  (1) Notice: This section must disclose the institution of higher education’s information practices before the site collects personal information from the public, including the use of, cookies, and/or Web bugs as well as information collected by other technologies and processes, and information collected via e-mail and Web-based forms.
  (2) Choice: This section must disclose whether and how personal information collected from the public may be used for purposes beyond those for which the information was provided.
  (3) Access: This section must address the procedure under which an individual may obtain information about himself or herself from the institution of higher education and/or have the institution of higher education correct information about the individual.
  (4) Security: This section must describe the procedures that ensure that information collected from individuals is accurate and secure from unauthorized use.

So, basically, after a little help from the Security Catalyst Community and a little research into the laws and regulations set forth by my government I have decided that it will be much better for me to glean the personal information of the visitors to my internal website from the web logs provided by the web server than to glean them from a web bug or some other type of overt tracking mechanism.

Go forth and do good things,
Cutaway

Powered by ScribeFire.

cookies, privacyguidance.com, DIR, SCC, Texas, Security Ripcord, Rebecca Herold, web bug

I got this in an email today and I thought that it was interesting enough to post and comment about.  Comments follow the article.

---

    Porn-surfing hits taxpayer IDs
     Security breach – More than 1,300 people face identity theft after a state employee let in data-stealing spyware
     Wednesday, June 14, 2006
     JOE ROJAS-BURKE
     The Oregonian
    
     Oregon Department of Revenue officials thought they were tightly secured against data theft. An elaborate firewall around their computer system fended off hackers. Virus detection software, updated every two hours, constantly screened incoming e-mail and downloads for malicious programs.
    
     But the technology did not stop an employee from using an office computer to surf porn sites and download a Trojan horse, a hidden spyware program not yet known to intrusion-detection software. The Trojan installed itself Jan. 5 and for the next four months secretly captured and relayed data to the hackers who created it.
    
     More than 1,300 taxpayers are now at risk of identity theft. The Department of Revenue, which disclosed the security breach Tuesday, said the confidential data consisted of Social Security numbers, names and addresses but included no tax records or financial or credit card information.
    
     In the struggle against online data thieves, the incident highlights the weakest link in the most advanced security systems: individuals who break security rules and intentionally or unintentionally expose computer systems to data thieves.
    
     "No matter how hard you try, no matter how many policies you have in place, no matter how many times you've trained your people, these things will happen," said Jim Hudson, president of Amcrin Corp., a security firm in West Linn.
    
     "Everybody who handles confidential data should have a plan on how to handle this risk," Hudson said.
    
     Like many institutions, the Department of Revenue appears to have been caught flat-footed. On Tuesday, officials had not finalized a plan for responding to the security breach, which they discovered May 15 while searching the computer hard drive of an employee who had been caught downloading pornography at work and fired.
    
     The department has not decided whether to pay for credit monitoring or other protective services, which banks and other private institutions often provide to customers after a data theft.
    
     "We are trying to figure out how that would be done and what the cost would be," said Don O'Meara, administrator of information processing for the Department of Revenue. He said the department intends to inform each affected taxpayer and began mailing notices Monday.
    
     The vulnerability to such an attack surprised the department's technology staff, O'Meara said. In addition to the firewall with frequently updated intrusion-detection software, the department routinely blocked employee access to thousands of porn and other Web sites known for transmitting malicious spyware.
    
     The department updated the list of blocked sites every 24 hours, but like fast-multiplying germs, the Web sites overwhelmed its defenses.
    
     "There are so many new sites, we couldn't keep up with them," said Rosemary Hardin, a department spokeswoman.
    
     "We maybe had a false sense of security," O'Meara said.
    
     The risk to the affected taxpayers is difficult to estimate. The creators of Trojan horses typically unleash them in hopes of capturing log-in names and passwords to bank and credit card accounts to steal from directly, Hudson said.
    
     The Trojan horse gathered the equivalent of 7,000 text pages of data. But O'Meara said his staff spent weeks poring over the data and found no tax files or financial information. He said it was limited to Social Security numbers, names and addresses.
    
     He said the department is taking steps to heighten security and also has banned employees from accessing Web sites for personal use.

 

---

So, all this security and all of a sudden it is breached because one person cannot control themselves.  Unfortunately these are the types of people that ruin everything for everybody (obviously). 

But here is the kicker…this article starts off by talking about the "elaborate firewall" that they have in place to protect their environment.  Well, where was the content filtering?  Did they just decide not to implement the firewall's proxy services? 

Okay, so maybe they did decide not to use them.  Maybe they didn't want to violate their users ability to surf the web during breaks and lunch times.  So, now that they have been affected by the risk they originally accepted and now they are going to mitigate that risk by implementing the security services that their deployed tools already contain?  Opps, no, they are going to "banned employees from accessing Web sites for personal use." 

Now there is a real moral booster.  And in fact, how are they going to do that?  Turn off Internet access?  Well, the employees still have to do their job and it might entail searches and Internet accessible web applications.  So with your "elaborate firewall" they can provide ACLs or content filtering so that the users can only ivsite a few "approved" sites? 

It just seems a little far fetched to me.  Whoever is responding to this incident is having a knee-jerk reaction and they are going to quickly realize that they misspoke and they are going to have to first sit down and re-evaluate their security policy (not just change it on a moments notice) and then they are going to have to determine a good way to leverage their security assets better to increase the protection they provide to their other critical assets.  They would also do better by not punishing the rest of the workers who were not involved in this incident. 

I would like to read your comments on this. 

Go forth and do good things,

Cutaway

Ed Finker’s recent article points out an interesting extension that I was not aware of until reading about it. Although online virus checkers are not new they are relatively unknown outside of the security industry. Now one of them has a Firefox plugin that allows the user to right click on a URL and Dr. Web will analyze it for viruses. Upon further research it turns out that the home site for Dr. Web Anti-virus has plugins for most browsers.

Now, I cannot vouch for how well their service works. Only time will tell. But this is still a very cool idea that seems very useful for security professionals and the general public alike.

So, from a security prospective, the concerns would be:

• Can you trust the services virus database?
• Will the service ever, convinently, overlook spyware for paying vendors?
• Timing attacks – meaning that the remote file can change between the time it has been scanned and the time it is downloaded.

So, if you decide to use this service you should definately keep Googling for customer and industry feed back. And ALWAYS scan the file again once you have a local copy of it on your system. You should only be using Dr. Web as a second form of validation for a download and not as your primary anti-virus mechanism.

Good surfing,

Cutaway