Calendar
QuicksearchCategories
ArchivesBlog Administration |
Barracuda Networks Confirms Exploitable Backdoors in its AppliancesSaturday, January 26. 2013
Barracuda Networks Confirms Exploitable Backdoors in its Appliances
/* Oooooooooh,Barracuda! */ Barracuda Networks has released firmware updates that remove SSH backdoors in a number of their products and resolve a vulnerability in Barracuda SSL VPN that allows attackers to bypass access restrictions to download potentially insecure files, set new admins passwords, or even shut down the device. The backdoor accounts are present on in all available versions of Barracuda Spam and Virus Firewall, Web Filter, Message Archiver, Web Application Firewall, Link Balancer, Load Balancer, and SSL VPN appliances. "Our research has confirmed that an attacker with specific internal knowledge of the Barracuda appliances may be able to remotely log into a non-priveleged account on the appliance from a small set of IP addresses. The vulnerabilities are the result of the default firewall configuration and default user accounts on the unit," Barracuda explained via a tech alert published on Wednesday. /* As usual, emphasis is my own. This appears to be entirely due to factory-default settings and lazy administrators who do not change/disable such defaults. */
Posted by TJE
in Advisories, Exploits, Factory Defaults, Firewall, Networking, Network Security, News, Remote, SSL, VPN, Vulnerabilities
at
08:12
Secret Forum Reveals Oz Firewall Backroom DealingMonday, May 17. 2010
Secret Forum Reveals Oz Firewall Backroom Dealing
Circumvention legal, but you can't tell anyone how[.] /* Emphasis is theirs. Now say what? It will be legal to circumvent (technical details at the bottom), but illegal to explain to someone else how to perform this perfectly legal configuration. I wonder how this might affect a corporate or ISP helpdesk perform VPN connectivity setup? */ Australia’s plans for a firewall to protect its population from smut on the internet are rapidly evolving from farce to total chaos. Weekly revelations on bulletin boards suggest that Stephen Conroy, the man behind the big idea, does not know what forthcoming legislation on the topic will say, when it will be introduced or how the firewall will work in practice. /* This time, emphasis is mine. I want to continue to point out how big of an asshat this particular Australian politician is. He is the "Minister for Broadband, Communications and the Digital Economy." He's the one that floated the idea of this nation-wide "firewall" (which is technically a proxy since it will be filtering at layer 7 - hence the technical problems) to "protect" citizens from illegal, immoral, or "dangerous" content. This is nearly the same thing the Chinese and Iranians are doing, just using layer 7 proxy devices instead of what's assumed to be basic layer 3 IP filtering of destination hosts. Skip to the very end of the post for the technical details behind this. To say this whole thing began as a farce is hitting the nail right on the head. */ Meanwhile, it turns out that the Minister’s own Department of Broadband, Communications and the Digital Economy (DBCDE) has been hosting a secret forum for discussions with ISPs likely to be affected by proposals. Along the way it floated the idea of making it a crime to advise surfers on how to do things that are perfectly legal to do. Confused? You will be. First up is the time scale for plans to introduce the new firewall. As already reported, the question of when legislation will be introduced has now been bouncing between the offices of Prime Minister Kevin Rudd and Communications Minister Stephen Conroy. Severe wriggling from Conroy’s office suggests that plans for an early introduction of legislation have been put on the back burner for now. /* Conroy wants to shelve the legislation until after the elections. He's technically incompetent, but he's smart enough to realize that this is going to be a screw-up of biblical proportions and it will likely cost him the election. It's "on the back burner for now," but it's by no means dead. */ Meanwhile further digging inside this forum revealed that departmental officials appear to have been discussing the possibility of making it a criminal offen[s]e to advise individuals of means that would enable them to circumvent the filter – even where the means themselves were perfectly legal. /* I would say that this equates to information being illegal. In a way, that's in the same league as banning books. */ As the EFA suggests, this answer raises more issues than it addresses, and relies on the degradation of the Australian network being gradual, rather than catastrophic. It does appear, however, that the government has no plans to deal with a possible overload of its firewall bringing the Australian internet to its knees – beyond setting up a review when such an event actually happens. /* Why should there be any degradation of bandwidth at all? I suspect that if this goes through, there's going to be a noticeable difference in download speeds and initial access to websites. */ /* Details: Circumvention: Circumvention of these filters will be trivial; you can wrap your request in SSL (such as https:// if the website supports it), by using a VPN provider outside Australia (many more found on the link for the word "using"), by using Tor (which uses a technique known as Onion Routing), or even by viewing blocked pages via the Google cache. Technical Considerations: This filtering is to take place with proxies (at the Application [7] layer) as opposed to the traditional large-scale deployments of firewalls (at the Network [3] and Transport [4]) layers). The deeper you have to inspect a packet, the more CPU and memory required to process the filters. It costs - in many ways, from actual dollars for the hardware and software, to performance impact, to configuration complexity to man-hours of maintenance - considerably more to filter at layer 7 with a proxy than layers 3/4 with a firewall. The one benefit to filtering at layer 7 is that you block only what is intended to be blocked. In today's world (where we've been running out of IPv4 space for a dacade now) a lot of websites are configured using virtual hosts. This allows web hosting providers to host a virtually unlimited number of websites on a single IP address. Let's say there are two websites, both hosted on the same virtual host IP address, where one is banned and the other is not: www.bannedwebsite.co.au (banned) www.momsrecipies.co.au (allowed) With a layer 7 proxy, when the user attempts to reach a website, the proxy intercepts the request, checks the request (including hostname and URI), and then either blocks the request, or requests the page on behalf of the end-user and returns her the requested webpage. So your mom can still access www.momsrecipes.co.au while nobody can access www.bannedwebsite.co.au. With a proxy, you can return HTML to the end-user explaining why access to this particular website is blocked and possibly a method of contact to dispute the denial of access. Pros: () Finer-grained control of what's filtered () Less "false positives" Cons: () Expensive in many aspects (mentioned above) () Complex configuration () Considerable service impact due to use of DPI at Application [7] layer () Slightly easier to circumvent; using https is the only circumvention measure mentioned that does not tend to work with the firewall approach - the rest should work against both types With a layer 3/4 firewall, access to the virtual host IP address (or even the subnet it's part of) will be blocked. When anyone tries to go to www.bannedwebsite.co.au, they are unable to, which is the intended result. They will get a different error; the browser will just report that website was unreachable. End of explanation. If anyone tries to go to www.momsrecipies.co.au, they will also be denied with the same uninformative unreachable error. Since both websites are on the same IP address, the firewall has no way of knowing which website you're looking for, so it blocks everything. Pros: () Cheaper to deploy () Simpler configuration - hundreds of hosts/subnets vs. thousands of hostnames () Can often be implemented on existing hardware - edge or core routers utilization IP ACLs () Faster, more responsive access to allowed websites; less service impact Cons: () Collateral damage - legitimate sites on the same virtual host as banned site are also blocked () Slightly more difficult to circumvent (a websites https site will likely be in the same blocked subnet) Comparison with Other Instances of State-Controlled Internet Access: I see three major differences in the Australian proposal as opposed to the other major regimes implementing state-wide filtering of websites (China and Iran). They are as follows: Another side effect of this proposal, from an economic standpoint, is that it is likely to put smaller ISPs out of business. Instead of putting the smaller burden on the backbone providers, with considerably more capital, it will place a more expensive burden on ISPs with less resources at their disposal. If these filters become legally mandatory, this will likely put smaller ISPs out of business. A smaller provider may not have access to the resources (money, manpower, and know-how) to meet these requirements and will thus have to shut down operations. Other Thoughts: There is one other somewhat commonly used filtering technique involving DNS. The ISP or corporate gateway will transparently route all DNS requests by the end-user to DNS servers under their control. The DNS servers will be configured as authoritative for the blocked domains; typically configured to return an IP address that connects you to a website telling you that your access is blocked and possibly why. This is similar to the Walled Garden approach. */
Posted by TJE
in Articles, Cryptography/Privacy, Firewall, Networking, Network Security, News, Routing, SSL, Technology, VPN
at
00:56
IPv4 Free Pool Drops Below 10%, 1.0.0.0/8 AllocatedSunday, January 24. 2010
IPv4 Free Pool Drops Below 10%, 1.0.0.0/8 Allocated
"A total of 16,777,216 IP address numbers were just allocated to the Asian Pacific Network Information Centre IP address registry for assignment to users. Some venerable IP addresses such as 1.1.1.1 and 1.2.3.4 have been officially assigned to the registry itself temporarily, for testing as part of the DEBOGON project. The major address blocks 1.0.0.0/8 and 27.0.0.0/8, are chosen accordance with a decision by ICANN to assign the least-desirable remaining IP address ranges to the largest regional registries first, reserving most more desirable blocks of addresses for the African and Latin American internet users, instead of North America, Europe, or Asia. In other words: of the 256 major networks in IPv4, only 24 network blocks remain unallocated in the global free pool, and many of the remaining networks have been tainted or made less desirable by unofficial users who attempted an end-run around the registration process, and treated 'RESERVED' IP addresses as 'freely available' for their own internal use. This allocation is right on target with projected IPv4 consumption and was predicted by the IPv4 report, which has continuously and reliably estimated global pool IP address exhaustion for late 2011 and regional registry exhaustion by late 2012. So, does your enterprise intranet use any unofficial address ranges for private networks?" /* The content of this post was shamelessly ripped from the front page of Slashdot. */ /* The IANA still shows 1.0.0.0/8 and 27.0.0.0/8 as being RESERVED and registered to them. What burns my ass like 3 foot flames is that we're giving these dwindling IP blocks to countries that shouldn't even be allowed to participate in the global internet! As I've stated before, on my own private network, for my own protection, I null-route all blocks allocated to APNIC, whether they've been sub-allocated out yet or not. I say we pull all of China's IP space. With their "Great Firewall of China," they've made it clear that they don't want their citizens participating in the global Internet, anyway. I say that we pull all of their routable IP space, give them -- let's be generous here -- a /20 to NAT behind, and let them use RFC1918-space for every machine in their god-forsaken country. If they use RFC1918-space (10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16), that gives them a total of: 16,777,216 + 1,048,576 + 65,536 = 17,891,328 IP addresses to use. Under this scenario, those of us who wish to rid ourselves of the useless packets (i.e., botnets and spam) spewing forth from this country, we can simply firewall or null-route a /20 and protect ourselves with better than 95% certainty. Sure, a few users will manage to VPN out to somewhere else in the world (*cough*Russia*cough) and wreak havoc from there, but it still keeps the vast majority off our Internet. I am sure that you could convince management to allow you to block a /20, even in the enterprise, a lot easier that wide swaths of /8s. */ /* In regards to corporations "borrowing" publicly routable IP space; I've seen it first-hand. I worked for a fairly large company in the financial sector, whose network was probably designed around the time I was born. They decided they were going to use 88.0.0.0/8 for their internal addressing scheme. Why not 10.0.0.0/8 you ask? It has the same amount of IP addresses; but the answer eluded me. With hundreds of branch locations all routing into their internal network, then through proxy servers, and finally out to the real Internet, this got to be quite a mess. We had to create a special route on the proxy pairs that linked directly to the ingress routers so that when a user needed to access a site whose IP just so happened to reside in 88.0.0.0/8, we'd have a special allow rule for that host/domain name that bypassed the traditional routing. I guess it's a good thing that they were bought out and their services either integrated or deprecated. */ Law Firm Suing China Hit By Cyber AttackSunday, January 17. 2010
Law Firm Suing China Hit By Cyber Attack
Last week, Santa Barbara, Calif.-based CYBERsitter sued the People's Republic of China, the two Chinese software makers, and seven computer manufacturers for distributing Web filtering software known as Green Dam with allegedly stolen code. This week, the law firm representing the company said that it had been targeted in a cyber attack from China. In a phone interview, Elliot B. Gipson of Gipson Hoffman & Pancione described what amounts to a spear-phishing attack -- the same technique used against Google in China. "They were e-mails targeted at individuals in our law firm that were made to appears as if they were coming from other individuals at our law firm," he said. "They attempted to get the target to click on a link or attachment." /* It looks like China is at it again. When will our government say "enough is enough?" Given that we've "outsourced" essentially all of our manufacturing jobs to China, India, and Mexico, all we have left to power our economy is our ingenuity; our intellectual property. The Chinese government has made little effort to hide the fact that they are behind these attacks. I'm really starting to favor a new "Cold War," this time against China. We toppled the Soviet Union without firing a single shot; there's no reason we couldn't do the same to China. With carefully coordinated electronic attacks, we could cripple their booming economy and leave them in ruins without risking one single American life. For those who have no reason to receive email, or other network traffic, from China and the other "problem children" in APNIC, here is a list of subnets that are managed by APNIC. You may wish to null-route all of them, or fine-tune the list to your needs. */
Posted by TJE
in Articles, Firewall, Malware, Networking, Network Security, News, Routing, Spyware, Vulnerabilities
at
07:40
Graphical Network Simulator 3Tuesday, December 8. 2009
Graphical Network Simulator 3
/* This simulator is absolutely awesome. It requires that you have the Cisco IOS images as it comes with a MIPS emulator and actually emulates a real Cisco router, switch, or PIX firewall. It's so realistic that you can design a network, configure the routers and switches, and then drop the running configurations onto real network gear. It certainly helps to have plenty of RAM available to run this. 1 GB or more is almost a necessity. */ Interesting Bit of iptables(8) HackeryThursday, May 22. 2008
/*
A while back, I set up a transparent Squid proxy at my border to limit my exposure to "drive-by downloads." It's a pretty standard setup; Squid running on the gateway/firewall, and iptables configured to route all tcp/80 traffic back into itself on port 3128. An unfortunate side effect of this is that tcptraceroute breaks. As port 80 is the default port that tcptraceroute uses (as the destination port), you end up with a traceroute that looks something like this: (root@desktop1) ~# tcptraceroute www.ebay.com Selected device eth0, address 172.25.X.XXX, port 39068 for outgoing packets Tracing the path to www.ebay.com (66.135.200.145) on TCP port 80 (www), 30 hops max 1 hp-core.ebay.com (66.135.200.145) [open] 0.558 ms 0.384 ms 0.315 ms I can assure you, I'm not 1 hop off from www.ebay.com. Since iptables is mangling the packet at the very first hop, my gateway/firewall, I'm receiving the SYN-ACK from that first hop. Keep in mind, tcptraceroute will use any destination port you specify, but the default is port 80 since it's usually allowed through most firewalls, and often open. Given that the default TTL of a Linux-based computer is 64, I can use the TTL match in iptables to selectively capture what tcp/80 traffic goes to the proxy and what does not. Consider the following rule: iptables -t nat -A PREROUTING -i $IF_INT -p tcp --dport 80 \ -j DNAT --to-destination 172.25.X.XXX:3128 This is the rule that routes all outbound traffic, originating on the internal network, to the Squid proxy. Now if we change that rule to match only packets with a TTL larger than, say, 48, we end up with the following: iptables -t nat -A PREROUTING -m ttl --ttl-gt 48 -i $IF_INT -p tcp --dport 80 \ -j DNAT --to-destination 172.25.X.XXX:3128 With this rule in place, a tcptraceroute headed for www.ebay.com on tcp/80 looks more like the following: (root@desktop1) ~# tcptraceroute -f6 www.ebay.com Selected device eth0, address 172.25.X.XXX, port 57684 for outgoing packets Tracing the path to www.ebay.com (66.135.200.145) on TCP port 80 (www), 30 hops max 6 so-1-2-0.gar2.chi1.bbnplanet.net (4.79.74.1) 76.668 ms 23.024 ms 30.840 ms 7 ae-31-55.ebr1.Chicago1.Level3.net (4.68.101.158) 57.014 ms 34.438 ms 36.097 ms 8 ae-68.ebr3.Chicago1.Level3.net (4.69.134.58) 25.716 ms 22.857 ms 32.941 ms 9 ae-3.ebr2.Denver1.Level3.net (4.69.132.61) 84.660 ms 49.091 ms 40.722 ms 10 ae-1-100.ebr1.Denver1.Level3.net (4.69.132.37) 79.996 ms 52.921 ms 52.897 ms 11 ae-3.ebr2.SanJose1.Level3.net (4.69.132.57) 71.323 ms 70.999 ms 71.651 ms 12 ae-82-82.csw3.SanJose1.Level3.net (4.69.134.218) 66.468 ms 70.863 ms 72.099 ms 13 ae-32-89.car2.SanJose1.Level3.net (4.68.18.132) 65.688 ms 62.794 ms 59.597 ms 14 EBAY-INC.car2.SanJose1.Level3.net (166.90.140.134) 60.576 ms 65.507 ms 58.566 ms 15 10.6.1.158 71.070 ms 59.413 ms 59.670 ms 16 10.6.1.146 61.397 ms 88.846 ms 68.280 ms 17 hp-core.ebay.com (66.135.200.145) [open] 84.341 ms 59.523 ms 62.286 ms Now that looks a little more reasonable. Given that I'm 1 hop off from the gateway/firewall, and Linux uses a default TTL of 64, then all of my packets generated by, say, Firefox, will come into $IF_INT with a TTL of 64. With 64 > 48, the DNAT rule matches, and the request gets routed through the Squid. As tcptraceroute works like any other traceroute tool, only using TCP SYN packets, the first packet will only have a TTL of 1. With 1 < 48, it does not match the DNAT rule, and passes through unchanged. The second packet will have a TTL of 2, with 2 < 48, and so on. As most all destinations on the internet are reachable in 30 hops or less, this guarantees that my browser generated requests are proxied, while my diagnostic requests are passed through unchanged. You can view/change your default TTL as such: (root@desktop1) ~# cat /proc/sys/net/ipv4/ip_default_ttl 64 Needless to say, the IP addresses have been changed to protect the innocent. ;) */
Posted by TJE
in Firewall, Linux, Malware, Networking, Network Security, News, Operating Systems, Routing, Site News, Spyware, Unix, Vulnerabilities
at
16:59
| Comments (0)
| Trackbacks (0)
pfSenseThursday, March 20. 2008
pfSense
/* pfSense is (yet another) all-in-one router/firewall/VPN device. It's based on the m0n0wall firewall, so it's based on FreeBSD and the entire system configuration is contained in one XML file. The entire rc process is written in PHP, making the XML parsing easy and also allowing for easy extendability. I've seen about a million of these all-in-one devices, but what sets this one apart for me is the GUI. This looks to be the simplest, yet most-powerful, all-inclusive web-based GUI I've seen on such a platform. Here's a quick rundown of the features included: SSL web interface wireless support stateful packet filtering NAT (many-to-one/one-to-one) PPPoE and PPTP support on the WAN interface DHCP client/server IPsec VPN tunnels (IKE; with support for hardware crypto cards and mobile clients) PPTP VPN (with RADIUS server support) caching DNS server DynDNS support SNMP agent traffic shaping configuration backup/restore load balancing bridging firewall ("invisible" firewall) many others */
Posted by TJE
in BSD, Firewall, Networking, Network Security, Operating Systems, Routing, Tools, Unix, VPN
at
09:15
Wikipedia Articles in Regards to Various Types of ExploitsSunday, January 13. 2008
Wikipedia Articles in Regards to Various Types of Exploits
/* First, there is the Wiki page detailing exactly what an exploit is. This is a very good read and should acquaint anyone with what an exploit is and can be capable of. Second, there are Wiki pages detailing several types of exploits and detailed information as to how they work. Below, you'll find some great examples of exploits ranging from low-risk web browser information disclosure on up to full system-level compromises.
Some of these methods were even new to me. The Sea-Surf (CSRF - Cross-Site Request Forgery) method is something I had at least considered as possible, but I had no idea that the method had a name and was actively in use in-the-wild. Some of these methods require some social engineering to trick the end-user (target) into activating the payload; whereas others require no interaction by the target, and they are often unaware that they have been or are being compromised. There are many other interesting documents covering everything from shellcode to polymorphic code to a NOP (Null OPeration) to NOP Sleds. Happy hacking! */
Posted by TJE
in Assembly, Buffer Overflow, C, Development, Exploits, Firewall, Format String, IDS/IPS, Networking, Network Security, Operating Systems, Programming, Race Conditions, SQL Injection, Systems Security, Vulnerabilities, XSS
at
00:19
Firewalling with OpenBSD's PF Packet FilterSunday, May 20. 2007
Posted by TJE
in BSD, Firewall, Networking, Network Security, Operating Systems, Unix
at
14:36
| Comments (0)
| Trackbacks (0)
Academics Break the Great Firewall of ChinaTuesday, July 4. 2006
Academics Break the Great Firewall of China
The firewall, which uses routers supplied by Cisco, works in part by inspecting Web traffic for certain keywords that the Chinese government wishes to censor, including political ideologies and groups it finds unacceptable. ... The researchers found that it was possible to circumvent the Chinese intrusion detection systems by ignoring the forged transmission control protocol resets injected by the Chinese routers, which would normally force the endpoints to abandon the connection. "The machines in China allow data packets in and out, but send a burst of resets to shut connections if they spot particular keywords," explained Richard Clayton of the University of Cambridge computer laboratory. "If you drop all the reset packets at both ends of the connection, which is relatively trivial to do, the Web page is transferred just fine." /* For once, breaking compliance works for the better. Now you have to be able to determine which RST packets came from the firewall routers and which ones came from the remote server. I wonder if examining the TTL on the packet would be a giveaway? */
Posted by TJE
in Cryptography/Privacy, Firewall, Networking, Network Security
at
17:18
| Comments (0)
| Trackbacks (0)
(Page 1 of 1, totaling 10 entries)
|
|||||||||||||||||||||||||||||||||||||||||||||||||
