Using Yahoo! Pipes, I tied in over 100 different security blogs into a single feed, sorted by newest on top, and encompasses all areas of security. When I have some more time I'll add security news sites like DarkReading, SecurityFocus, etc.
I know Mark Curphey was working on a a newer, improved SBN, but I don't know what happened to it. If anyone has any tips for optimizing the pipe and filtering irrelevant content out, let me know.
I saw this on Slashdot last week, an article regarding "Getting the best deals from Dell." One bullet point really stuck out, about financing offers:
9. DPA/Dell Preferred - This is the Dell credit card, like a Sears, Macy's or Radio Shack credit card. Typically a high rate, low limit card. The lowest APR is still around 18-20%, and that comes with a $5,000 limit. The $4,000, $3,000 and $2,000 limits have rates in the mid to high 20s. The lowest limt, $1,500, has an APR of 29.99%. NEVER USE THIS UNLESS THERE IS A KILLER NO INTEREST PROMOTION.
This is nothing new, but it always gets to me -- credit cards, car loans, banks, etc can charge you that much interest since the 1980. But you know, if you or I were to loan some money to a friend or colleague at an interest rate of more than 5-12% (dependent on state law), we would be "loan sharking" because we're not a bank and they have separate rules. What crap. How can anyone, bank or individual, get away with charging 29.99% interest!?! Even better is point a, the exploitation of freshmen college students. Bah, this should be a crime!
/end rant
I went ahead and tried to run Burp suite on my laptop running Ubuntu today. First, check the readme.txt, which says I need JRE 1.4 or later installed.
marcin@thinker:~/burpsuite_v1.01$ java --fullversion java full version "gcj-1.4.2"
Okay... 1.4.2, but it's Java built into gcc. When I first tried to run it, I got this error:
marcin@thinker:~/burpsuite_v1.01$ java -jar burpsuite_v1.01.jar Exception in thread "main" java.awt.AWTError: Cannot load AWT toolkit: gnu.java.awt.peer.gtk.GtkToolkit at java.awt.Toolkit.getDefaultToolkit(libgcj.so.70) at javax.swing.ImageIcon.<init>(libgcj.so.70) at javax.swing.ImageIcon.<init>(libgcj.so.70) at burp.interface.long.<init>(Unknown Source) at burp.StartBurp.main(Unknown Source) Caused by: java.lang.UnsatisfiedLinkError: libgtkpeer: libgtkpeer.so: cannot open shared object file: No such file or directory at java.lang.Runtime._load(libgcj.so.70) at java.lang.Runtime.loadLibrary(libgcj.so.70) at java.lang.System.loadLibrary(libgcj.so.70) at gnu.java.awt.peer.gtk.GtkToolkit.<clinit>(libgcj.so.70) at java.lang.Class.initializeClass(libgcj.so.70) at java.lang.Class.forName(libgcj.so.70) at java.awt.Toolkit.getDefaultToolkit(libgcj.so.70) ...4 more
So, I did a little searching and found I needed the libgcj7-awt package. I went ahead and installed it using apt-get. I try running it a second time and bam, another error!
Exception in thread "main" java.lang.StringIndexOutOfBoundsException at java.lang.String.substring(libgcj.so.70) at burp.while.public.else(Unknown Source) at burp.while.public.instanceof(Unknown Source) at burp.while.x.instanceof(Unknown Source) at burp.while.je.instanceof(Unknown Source) at burp.interface.long.for(Unknown Source) at burp.StartBurp.main(Unknown Source)
What the hell! I remember seeing in the readme something about troubleshooting,
If burp suite fails to start, or generates the error "Exception in thread main", check that the correct JRE version has been installed. If so, check that the "java" command is launching the most recent JRE, and not an earlier installed version. If necessary, modify the startup command to contain absolute paths to both the JRE and the JAR file, e.g. "/usr/bin/java -jar /usr/tools/burpsuite_v1.01.jar".
marcin@thinker:~/burpsuite_v1.01$ which java /usr/bin/java
Check... hmm, I'll give my buddy a ring and see what he says. He told me straight up to just get rid of gcj and install Sun's JDK. Here's the link, get "JDK 5.0 Update 12." I installed it using the self-extracting binary and wallah!, no more problems trying to run Burp suite. =D
So do yourself a favor and remove gcj -- get Sun's JDK.
I was directed through RSnake's blog to a XSS defect in Yahoo! Services and had a couple questions concerning secure design of web applications...
So here's the scenario,
A user is authenticated by a device between himself and the application he's accessing. From there, they are able to gain control over the application they are using and launch an attack against other applications/servers.
What would the likelihood of such an attack be? What if the authenticating device checks for malformed urls and limits what urls are passed to each application? To add to this, consider the security of the system itself: running a stripped SELinux kernel, custom web server, clears its cache regularly and performs encryption on data being transmitted and stored. The system was audited by several independent partners and is considered to be "extremely reliable and secure."
Unless there's some flaw in the way the server handles urls, I think finding a vulnerability in the design without performing a full pentest will be difficult. I'm a newb to web app security, so I might be wrong entirely...
Over the course of a day, I could log in to five different systems I'm currently working on. On each I'll get a Bash or Tcsh shell and it's almost guaranteed I'll need to edit a text file at some point during the day. On my home system, my choice of editor is Vim, because it's quick like Vi with some feature enhancements that makes it more pleasing to use. I don't have to do a ^H like I do on Solaris, or use the h, j, k, l keys to navigate or get funky with the delete and backspace keys in original Vi.
On my laptop, which I run Ubuntu, I normally enter vi and get Vim. So, out of curiosity I checked which vi I'm using and where's it's located.. Here's the trail of cookie crumbs I found to the source -- talk about retarded. $ which vi /usr/bin/vi $ file /usr/bin/vi /usr/bin/vi: symbolic link to `/etc/alternatives/vi' $ file /etc/alternatives/vi /etc/alternatives/vi: symbolic link to `/usr/bin/vim' $ file /usr/bin/vim /usr/bin/vim: symbolic link to `/etc/alternatives/vim' $ file /etc/alternatives/vim /etc/alternatives/vim: symbolic link to `/usr/bin/vim.basic' $ file /usr/bin/vim.basic /usr/bin/vim.basic: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.0, dynamically linked (uses shared libs), stripped
« Newer entries — 32 — Older entries »