Latest WordPress Milw0rm exploits PIPE’d to your feed reader!

Milw0rm is a great source of security exploits, subscribing to it’s feed is a good way of getting a heads up on where the next attack might come…. there are a lot of script kiddies that do nothing more than download milw0rm exploits and fire them randomly into the internet hoping to get a hit!

The thing is there are a lot of exploits found everyday and it can start to fill-up your RSS Feed Reader, so it’s a good idea to filter out things that are useful to you, as an expample I have created a simple Yahoo! Pipe which delivers only WordPress exploits found on Milw0rm!

PIPE URL: http://pipes.yahoo.com/linickx/milw0rmwordpress
FEED: URL: http://pipes.yahoo.com/pipes/pipe.run?_id=RDnArZNk3hGthFdiUpWufg&_render=rss

The pipe / feed is currently empty – returns no results – as there hasn’t been anything new published recently, but I’m sure that’ll change soon enough :)

links for 2009-06-26

Link

[ # ]

links for 2009-06-08

Link

[ # ]

Hackers Targeting Windows XP-Based ATM Machines

We’re not going to start hiding our millions under our mattress (that’s right, all bloggers roll in obscene amounts of money and own private jets), but the next time we withdraw a wad of cash, it might be a good idea to skip the ATM and flirt with a real live teller instead.

Bluecoat reverse proxy and health checks.

Bluecoat Reverse Proxy Health Check Diagram
Bluecoat Reverse Proxy
Health Check Diagram

Consider the attached diagram, a customer wants a fairly simple reverse HTTP proxy solution; behind the bluecoat is two servers one hosting pages for server1.domain.com and the other for server2.domain.com (both of these DNS names resolve to the IP address of the bluecoat).

The requirement comes with a twist, in the event that either server goes down they want requests sent to another “we’re sorry the site is down” server, below is some pseudo-code explaining what we want the bluecoat to do when it receives a HTTP request.


If (URL = http://server1.domain.com ) then
If ( webserver1 = healthy) then
Forward webserver1
Else
Forward backupserver
Fi
Fi
If (URL = http://server2.domain.com) then
If ( webserver2 = healthy) then
Forward webserver2
Else
Forward backupserver
Fi
Fi

Now it took me some time to find out how to do this, some can be applied in the GUI, the rest has to be applied in Content Policy Language (CPL). If you want to do something similar start by defining some forwarding hosts in the GUI click: Configure -> Forwarding Hosts -> New . In this example only use IP addresses, it makes things simple later, so server1.domain.com =

  • alias = 192.168.1.1
  • host = 192.168.1.1
  • type = server
  • ports = HTTP 80

then server2.doamin.com is…

  • alias = 192.168.1.2
  • host = 192.168.1.2
  • type = server
  • ports = HTTP 80

and the backup webserver is…

  • alias = 192.168.1.3
  • host = 192.168.1.3
  • type = server
  • ports = HTTP 80

If you now click: Heath Checks -> General you’ll see that some health checks like fwd.192.168.1.3 have been created for you.

Next In the VPM (Policy -> Visual Policy Manager -> Launch) create a web access layer permitting “any” to your webserver hosts server1.domain.com & server2.domain.com

Finally you need to upload come CPL ( Policy -> Policy Files -> Under: Install Local File from -> Select: Text Editor -> Install)

<Forward>
	; Forward to server1.domain.com
	server_url.host.exact="server1.domain.com" is_healthy.fwd.192.168.1.1=yes forward(192.168.1.1)
	server_url.host.exact="server1.domain.com" is_healthy.fwd.192.168.1.1=no forward(192.168.1.3)
	; Forward to server2.domain.com
	server_url.host.exact="server2.domain.com" is_healthy.fwd.192.168.1.2=yes forward(192.168.1.2)
	server_url.host.exact="server2.domain.com" is_healthy.fwd.192.168.1.2=no forward(192.168.1.3)

Change as necessary, but now if server1.domain.com goes down the page on 192.168.1.3 is displayed (and the same happens for server2) neat!

(Correct as of SGOS 5.4.1.3 as usual YMMV!)

Access list syslog correlation

ACL syslog correlation is a Cisco IOS feature which provides the ability to identify which access list entry (ACE) was responsible for a permit or deny action appearing in syslog.

Consider the following access list applied to filter externally-sourced traffic destined for the internal network:

Router# show ip access-lists
Extended IP access list EXTERNAL->INTERNAL
    10 permit icmp any any echo-reply
    20 permit udp any eq domain any
    30 permit tcp any any established
    40 permit tcp any host 172.16.0.202 eq www
    50 deny tcp any any eq 22 log
    999 deny ip any any

Lines 10 through 40 allow miscellaneous traffic types in, and line 50 explicitly denies inbound traffic destined to TCP/22 for the purpose of logging. Line 60 defines an explicit "deny any"; this isn't required, but included here for clarity.

When an inbound packet is matched and discard by rule 50, the following syslog message is generated:

%SEC-6-IPACCESSLOGP: list EXTERNAL->INTERNAL denied tcp 10.0.0.2(57289) ->
 10.0.0.1(22), 1 packet

This log message informs the administrator of the action taken and the ACL which matched the packet, but in some cases we may want more detail readily available. This is where ACL hash correlation comes in handy. We can redefine the ACL rule to include an arbitrary keyword, up to 64 characters in length:

Router(config)# ip access-list ext EXTERNAL->INTERNAL
Router(config-ext-nacl)# 50 deny tcp any any eq 22 log Deny_SSH
Router(config-ext-nacl)# ^Z
Router# show ip access-lists
Extended IP access list EXTERNAL->INTERNAL
    10 permit icmp any any echo-reply
    20 permit udp any eq domain any
    30 permit tcp any any established
    40 permit tcp any host 172.16.0.202 eq www
    50 deny tcp any any eq 22 log (tag = Deny_SSH)
    999 deny ip any any

Now when that rule discards a packet, its log message includes our tag:

%SEC-6-IPACCESSLOGP: list EXTERNAL->INTERNAL denied tcp 10.0.0.2(54843) ->
 10.0.0.1(22), 1 packet  [Deny_SSH]

These tags can be reused by multiple ACEs. Continuing our example, say we also want to deny traffic to SSH servers running on an alternate port, TCP/2222:

Router(config)# ip access-list ext EXTERNAL->INTERNAL
Router(config-ext-nacl)# 60 deny tcp any any eq 2222 log Deny_SSH
Router(config-ext-nacl)# ^Z
Router# show ip access-lists
Extended IP access list EXTERNAL->INTERNAL
    10 permit icmp any any echo-reply
    20 permit udp any eq domain any
    30 permit tcp any any established
    40 permit tcp any host 172.16.0.202 eq www
    50 deny tcp any any eq 22 log (1 match) (tag = Deny_SSH)
    60 deny tcp any any eq 2222 log (tag = Deny_SSH)
    999 deny ip any any

ACL logging tags are great for readily identifying ACE matches, particularly when you expect certain matches to occur, but manually defining a tag for each ACE isn’t always practical. This is especially true when you want to maintain syslog correlation among hundreds or thousands of individual ACL rules. In such cases, automatically generated hashes would be the preferred option. Automatic hashing is enabled globally, and applied to any ACE with the log keyword with no argument following it.

Here we enable hash generation and add a few more ACEs to our ACL:

Router(config)# ip access-list logging hash-generation
Router(config)# ip access-list extended EXTERNAL->INTERNAL
Router(config-ext-nacl)# 70 deny tcp any any eq 1000 log
Router(config-ext-nacl)# 80 deny tcp any any eq 2000 log
Router(config-ext-nacl)# 90 deny tcp any any eq 3000 log
Router(config-ext-nacl)# ^Z
Router# show ip access-lists
Extended IP access list EXTERNAL->INTERNAL
    10 permit icmp any any echo-reply
    20 permit udp any eq domain any
    30 permit tcp any any established
    40 permit tcp any host 172.16.0.202 eq www
    50 deny tcp any any eq 22 log (1 match) (tag = Deny_SSH)
    60 deny tcp any any eq 2222 log (tag = Deny_SSH)
    70 deny tcp any any eq 1000 log (hash = 0x594F8697)
    80 deny tcp any any eq 2000 log (hash = 0xE471528C)
    90 deny tcp any any eq 3000 log (hash = 0x34CC0DD6)
    999 deny ip any any

As expected, a trigger by any of the ACEs with a hash appended works just as it does with tags:

%SEC-6-IPACCESSLOGP: list EXTERNAL->INTERNAL denied tcp 10.0.0.2(21196) ->
 10.0.0.1(1000), 1 packet  [0x594F8697]

While not immediately useful, a hash can be used to filter an ACL configuration and quickly identify the ACE responsible for an action:

Router# show ip access-lists EXTERNAL->INTERNAL | include 594F8697
    70 deny tcp any any eq 1000 log (1 match) (hash = 0x594F8697)

9 comments